Moving into core: always required or optional?

Separate module that is enabled by default. This just gives more flexibility for sites -- esp. large multisite installs -- that use alternate methods of code maintenance and updates.

This solves a lot of problems and makes Drupal more attractive for Random Ass Shared Hosting (RASH)...but in that case, anything that is core and enabled by default, tends to stay turned on, thus solving the problem you are aiming for.

Well, I've partially answered already. First, I do have multi-sites. Secondly, if it doesn't email me that there is an update, I am very likely to not know, as I don't go look at those things unless there is a reason to suspect a problem.

I asked for the "master site" feature a long time ago. I check my test sites (where I do have a master site of sorts) much more often than the production sites. BTW, another part of that request was not really done: tagging a module with the sites that use it; but I've gotten around that, more or less. And, no, after seeing US in action, I don't expect that part to ever be implemented.

I certainly favor making it disable-able. You asked about the bandwidth issue. Let's say it transfers 10K a day, so that's 300K a month. A few of my sites are actually limited to 10MB per month because they are low transfer sites (largely "brochureware" that are used principally as Yellow Pages replacements) and that's all they need to pay for. So "wasting" 3% of the bandwidth is significant. It's highly unlikely that these sites will have a security problem. And these sites are on a fixed-price per year contract, so I make no extra money by checking them.

Plus, I'm not going to throw any new module into production before I test it, regardless of why it was created.

Another part of my concern about making it permanently enabled is that if the Drupal site is slow, US can cause Cron to stall. I've already seen this and I've seen other posts in the forums from people whose Crons also stalled. For many people, the fix for this is quite unpleasant (remember, not everyone is a phpMyAdmin expert).

It's interesting that Earl is leaning towards optional, because he called me names for suggesting that it should be. I like Update Status and think it's a great service for Drupal. On the other hand, I'd like to see the level of changes drop before it goes into core. IMO, D7 would be a better target.

"One less thing to clutter the admin/build/modules page with." This is such a silly argument! For one thing how often do you go there? Secondly, what about sites with e-commerce or Ubercart; they've got so many things there, one more won't even be noticed. I've got one site where the CCK modules outnumber the "Other" category!

Would recommmend on by default but disable-able. It may come as a surprise, but I am using drupal as a RAD environment in some fairly secure settings. We've been planning on putting egress filters on some of these boxes so that they can't reach out to the internet. I don't want my cron processing or my drupal application to come to a halt for 2 minutes at a time while drupal tries to phone home.

Generally apps that MUST phone home are considered disconcerting to those who are extremely security conscious. Please leave a way out so that I don't have to hack core in order to make my site work in a high security setting.

Thanks,

Dave

I agree that this should be disableable. Whether or not this goes into system.module is a separate question from whether it can be disabled. We have ways to disable parts of modules.

System.module is already a mishmash of crap from everywhere. I can't think of any good reason to expand it by including this functionality there. It makes sense to me to add this as update_status.module, which is enabled by default.

I'd also say non-required, enabled by default module. If it's not getting enough use in the wild for some reason, we can revisit this decision in 7.

I'm going to also chime in on the "optional but default on" side. At one point I would have said required, but consider that it involves your site phoning home to drupal.org on a regular basis. drupal.org has not exactly been a paragon of speedy responses lately. Having US on would then make your cron only as fast as drupal.org is responding today, which varies widely. Imagine the support requests we'd get for search indexing never working right because cron dies because drupal.org has a slow tracker query. :-)

I would also much rather hide this information from clients, and only find out myself (on some master site where I have a crapload of modules installed, just to see what's updated). That way I can decide if it's worth upgrading the module rather than getting calls from a panicky client, "OMG there's this red text here what do I do I broke it help me OMG!" :-)

system.module is going to be getting a lot smaller when we start splitting off page handlers post-freeze, but I think it still makes sense to keep this as a separate module. I never liked using system.module as a dumping ground anyway. I'd vote for "update.module", which is enabled in the default profile.

I vote either not part of core or something that can be disabled. While automatic updates can be useful they generally assume they know what is best which is not always the case. For one thing people do make private mods to modules and would experience problems if the module was suddenly updated.

In general one of Drupal's strong points is it's flexibility and I prefer to see it kept that way.

I agree with an optional, enabled by default module... system.module is too big already.

I'm also on the optional module side for the reasons stated above. Drupal is very much about flexibility, so it simple makes sense to have it optional. The usage of system.module as a random dump should be discontinued IMHO.

I think the most difficult issue here is what we want to call the module ;)

update.module - sounds like it's actually performing updates
updates.module - fairly better
releases.module - could work
um (update monitor) rc (release checker) and other evil abbreviations shouldn't belong to core

After sleeping on this and reading the arguments above, I'm leaning back the other way.

Including update_status in core is a great step in making people more security conscious, and I expect most people will leave it on as default anyway. However, some kind of 'Are you sure?' style page may help people to think twice before disabling it, while still giving them the option.

A core release should also provide good feedback of use case. Until this is actually being used in the wild, we don't know what issues people will think of for not wanting to use it. By opting to _not_ force it down people's throats we can take this feedback and work out how to make it tastier... so people actually _want_ to use it.

I believe, as is usually the case, taking away the freedom of choice will stifle innovation and piss some people off.

Optional, in it's own module, on by default - that's my preference.

I've been using it on some 5.1 sites, and have had to disable it so customers don't get worried when it claims that a release version is an update to cvs head =D
Or that a new release with new features that would require major updates to the theme or such doesn't worry customers.

Basically I can think of lots of reasons to keep this optional. The one reason to have it mandatory is security, and I can see the benefit of that. Perhaps the security update warning functionality could be split off and made mandatory?

I don't think I'd make any part of US mandatory. Remember that phoning home to the mother ship takes time. If every Drupal site has this enabled, the we're effectively DDoSing drupal.org by using Drupal. That's not a good thing. :-) I want the ability to not have to slow down my cron or even notify my clients in the first place. I want to see security warnings on my test site, but they never see it on live until I fix it for them.

I could see an option in the module "notify me of [] sec updates [] feature updates [] devel updates" or something like that, but it should still be possible to shut it down completely and never phone home at all.

+1 for required as part of system.module.

It's possible to disable notifications for individual modules. Does this mean it doesn't check for them at all? In which case you could untick them all one by one and switch off the calling home altogether? If that's the case, I'd say leave it required.

If it's going to be optional, I reckon it should be really, really hard to switch off. Possibly stick it at the level of settings.php or something if that's possible.

Non-required, enabled by default module.

Several people have given good reasons why a site may want to turn this off. There are likely to be other good reasons not yet stated.

OK I now side with the 'default on, optional crowd'.

@dww - ok cool I read that. The distinction between "warn" and version info makes sense, haven't seen the 2.x ui yet so dunno how nasty an extra checkbox would be.

Since it'll neither reduce load on d.o, nor allow for disabling the module in-a-really-annoying-way-that-many-people-wouldn't-bother-with, I guess I'm in the "optional on by default" camp as well then.