On May 22, 2008, at 10:13 AM, Darrel O'Pry wrote:

I think I'm more offended by update status in core, than people creating releases. :)

Them's fightin' words! ;)

All I ever wanted from the release system was a way to branch and version my code.

That's a good start, and one of my first itches I was scratching.

I'd be really happy to see update_status disabled in core by default

You're obviously not a member of the security team.

or be made less noisy ie) only make noise on sec update...

Already a knob for this.

Frankly contrib dev is noisy, and I don't see that changing.

I'm not (yet) ready to give up my multi-year quest to bring enlightenment about release management to the Drupal project as a whole. Help in this crusade is appreciated. Nay sayers will be ... ;) Cheers, -Derek (dww)

On May 22, 2008, at 4:33 PM, Darrel O'Pry wrote:

Already a knob for this.

Where? Can I control it as a module maintainer?

If you go to view your updates (at admin/logs/updates) there is a tab for settings (admin/logs/updates/settings) In here there are all kinds of knobs.

I think he was asking if there's a way a module maintainer can, on drupal.org, flip a switch so that only security updates get sent out. I'm not sure that's the best approach, as I wouldn't want to be denied feature updates as a site owner if I so desired. Perhaps a better tack would be to make it a default setting on new Drupal installs to enable only security updates. That way, your average Drupal site maintainer would only have to contend with the trickle of security updates, rather than the onslaught of minor version increases. -marco On Thu, May 22, 2008 at 3:37 PM, Matthew Farina <matt@mattfarina.com> wrote:

On May 22, 2008, at 4:33 PM, Darrel O'Pry wrote:

...

Already a knob for this.

Where? Can I control it as a module maintainer?

If you go to view your updates (at admin/logs/updates) there is a tab for settings (admin/logs/updates/settings)

In here there are all kinds of knobs.

On May 22, 2008, at 1:33 PM, Darrel O'Pry wrote:

it's a statement that code and process is easier to change than people and my conviction that processes should adhere to people not the other way around

Then I should give up and we should go back to the jungle where contrib is a vast wasteland of unversioned goo. That's what project* and the drupal.org contrib repository should return to if the code/ process should adhere to people instead of the other way around. No thanks. ;) If anything, the last ~1.5 years have shown that the process is still too flexible, and there should be more ways that it forces the people to adhere to sane, consistent behavior, not less. For example: #252473: Prevent people from putting "-dev" in CVS tag names [1] and perhaps even: #90968: enforce sequential release tags in xcvs-taginfo [2] Not to mention disasters like: #198278: Prevent bogus branches by checking at commit time, too [3] that resulted in messes that still aren't completely resolved: #152832: cleanup faulty branches [4] Of course, if everyone were careful, and already comfortable with sane release management, it'd be a different story. Sadly, the d.o infrastructure mostly has to cater to the lowest common denominator in terms of ability and experience. I've been trying to balance the needs of experienced, clueful people like you and me, with the reality of 100s of brand new contributors and their propensity to break things, not to mention everyone's aversion to reading documentation. ;) I won't claim I've always made all the right decisions and choices, but I believe I've done a pretty good job of it. If you have disagreements, concrete help and constructive criticism would be much more appreciated than adding to the chorus of empty complaints ("it's offensive that update_status went into core"), even if you're already a valuable contributor in other ways. Thanks, -Derek [1] http://drupal.org/node/252473 [2] http://drupal.org/node/90968 [3] http://drupal.org/node/198278 [4] http://drupal.org/node/152832 p.s. "Them's fightin' words ;)" was meant as a joke and a pop-culture reference, nothing more.

On 30 May 2008, at 4:35 PM, Darrel O'Pry wrote:

<constructive criticism>The -dev extra is still a little limiting. a timestamp would almost be better. I personally feel users who want to follow head will be using CVS, and those who don't knwo how to use CVS but want to test are using -dev.tar.gz. A timestamp would be a solid indicator as to which -dev release they're using since it is a moving target.</contructive criticism>

i'm sitting in the same situation right now. I would like to create weekly releases from HEAD on a project i am working on right now. -dev has too many semantics related to it for my purposes.

so go ahead and make a release every week. i don't see what the issue is. you want a release to be automatically created for you on your preferred schedule? thats quite an exotic need. On Fri, May 30, 2008 at 10:42 AM, Adrian Rossouw <adrian@bryght.com> wrote:

On 30 May 2008, at 4:35 PM, Darrel O'Pry wrote:

...

<constructive criticism>The -dev extra is still a little limiting. a timestamp would almost be better. I personally feel users who want to follow head will be using CVS, and those who don't knwo how to use CVS but want to test are using -dev.tar.gz. A timestamp would be a solid indicator as to which -dev release they're using since it is a moving target.</contructive criticism>

i'm sitting in the same situation right now.

I would like to create weekly releases from HEAD on a project i am working on right now. -dev has too many semantics related to it for my purposes.

On Fri, May 30, 2008 at 10:23 AM, Larry Garfield <larry@garfieldtech.com> wrote:

One of the issues with -dev is that some module maintainers use it for "mostly stable but I've not fully debugged it yet, please test", while others use it for "dude, it doesn't even compile, it's got syntax errors all over the place, wtf are you using it for?" And there's no way to tell which is which, and it can even change over time in the same module.

What if we allowed non-pattern-compliant branches, but did not permit the creation of release nodes? That would allow those with more CVS-fu to do all kinds of wacky "me only" experimental branches but people who still get all their code from drupal.org/projects/* won't even have a way to get to it until it goes into the "main, kinda stable, needs testing" -dev branch (which module maintainers don't even have to make release nodes for if they don't want to, as now).

I can't speak for the more experienced maintainers, but this sounds complicated and over my head. :) My devs tend to fall somewhere in the middle of those two extremes and I simply document that on the project page. Maybe we should just encourage people to put a note on their pages saying how _they_ feel about the state of their dev snapshots so potential users can decide which they'd rather use? Michelle

On Fri, May 30, 2008 at 12:27 PM, Derek Wright <drupal@dwwright.net> wrote:

Good suggestion. ;) Both of the full DrupalCon talks I've given on this topic [1] [2], and the handout I wrote [3], all repeat the idea that one of the key ways to be a responsible maintainer is to clearly communicate the status of your code and your plans/intentions for the future. There are already a variety of channels for this communication. I don't know what else to do to encourage people, other than to keep repeating myself.

It's possible this isn't mentioned in enough of the handbooks to be visible, so if an aspiring documentation team member wanted to help this particular problem, they could pepper the appropriate handbook pages with suggestions about clearly communicating status + intentions.

Sorry, Derek, I should have figured such a thing was already in the docs somewhere. I don't know if it's that it's not mentioned enough or that there's just simply too much information out there and stuff gets missed. It's been a long time since I got my cvs account... Is this linked to in the email that gets sent out? If not, it should be. Michelle

On May 30, 2008, at 8:23 AM, Larry Garfield wrote:

Crazy idea that may already be possible, I've not tried:

...

What if we allowed non-pattern-compliant branches, but did not permit the creation of release nodes?

Not possible, precisely because enforcing a standard convention for branch and tag names has been one of the key parts of trying to keep (some of) the insanity in check. It seems the regular practice for new contributors is: A) This stuff is new and complicated, I don't get it. B) Lemme try making a bunch of branches and tags, and see what happens. C) Lemme try making release nodes. D) At first sign of trouble, email dww or file support issues. (Notice: "Read the docs" isn't on the list). So, at step (B), if there's any flexibility at all, they'll do all kinds of crazy things (which are hard to clean up after the fact). Then, at step (C), they'll get even more agitated: [critical bug] "I made my tags but I can't make releases". Really, how much more flexibility do you need? You're at 5.x-2.*, which is stable. You're starting new features and trying stuff out. Make a DRUPAL-5--3 branch, but don't make a release node for it. There you have it -- a branch you can play with, try out crazy things, but then people won't be trying to use it, -dev or otherwise. One thing I'd _consider_ (but not necessarily implement) is some kind of "use advanced CVS" permission care of the drupalorg.module, and have our validation scripts (and perhaps form_alter() on the release- related forms) honor this perm to give more flexibility. But, then, it's a headache to maintain a new role that has this permission, it's work to write this code, it's two sets of reality to document and maintain, etc, etc. And, just because you claim you know what you're doing and you need additional flexibility doesn't make it so. ;) Cheers, -Derek (dww)

Daniel F. Kudwien wrote:

Heck! So let's install Quiz module to have each CVS applicant *prove* that he/she has read and understood the docs. If all questions have been answered correctly, CVS access will be granted. :)

Oooooh that sounds delicious. ;) -mf

Derek Wright wrote:

It seems the regular practice for new contributors is:

A) This stuff is new and complicated, I don't get it. B) Lemme try making a bunch of branches and tags, and see what happens. C) Lemme try making release nodes. D) At first sign of trouble, email dww or file support issues.

(Notice: "Read the docs" isn't on the list).

This is overly cynical, it's possible to read the docs and still feel overwhelmed by having to learn a new system. This isn't a problem with the docs, they're great, but it is still a steep learning curve. Also, you're on the receiving end of those who gets stuck, how many people have never needed to raise a ticket? Having said that, those constraints have saved me from breaking stuff in CVS on multiple occasions. I've read the docs, and understand CVS reasonably well these days, but that doesn't stop the odd stupid mistake. I expect most Drupal devs want a _simple_ system to manage their releases. The current release system is nearly perfect for that, and anyone who doesn't like it is welcome to run their own version control system and sync with the drupal.org repos as they see fit. Lets keep drupal.org CVS simple, well constrained, and easy to use. Remember the 80/20 rule: Derek's time (in my opinion) is better served getting features that 80% of the community use perfect, than pandering to the needs of the 20% who want something different. Particularly when that 20% could set something up themselves, without having to lean on the limited resources of Derek and Co. (see Ubercart and eCommerce modules for examples of this). Kind Regards, Liam McDermott.

Quoting Nancy Wichmann <nan_wich@bellsouth.net>:

dww wrote: "I've noticed quite a few projects that seem to think the best time to make a new official release is after every CVS commit. While I'm happy to see people actually making official releases, please don't do this."

Shouldn't this be tempered with the frequency of changes?

Well, I am one of the ones who likes to roll up several changes at once, so I use -dev releases in between.

This is also tempered with the frequency of changes, correct?

However, one thing that I've had several users tell me is that the big red "X" scares them and they think a -dev release is poison. I figured it would happen like this - and it has.

Bug fixes are one thing while feature enhancements are another. More documentation on the project page will help your users feel comfortable with the -dev package. State exactly the differences and how you feel it works.

Perhaps a red background and a big red "X" are too scary and should be toned down.

Again more documentation on the project page is a must. Say exactly what is known to work and what is known not to work. That will help tone down the "big red "X"". Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

Quoting Nancy Wichmann <nan_wich@bellsouth.net>:

Earnie Boyd wrote:

...

This is also tempered with the frequency of changes, correct? Of course. Also the types of changes.

...

Bug fixes are one thing while feature enhancements are another. More documentation on the project page will help your users feel comfortable with the -dev package. State exactly the differences and how you feel it works. It doesn't seem to matter all that much. I've had occasion to ask a specific user to test out the -dev version and they've been scared to to do that.

Testing -dev in development is one thing. Testing -dev in production is something else. Scared here has the impression that the user doesn't want to screw with production and perhaps doesn't have a development staging environment. Some users just need more hand holding.

...

...

Perhaps a red background and a big red "X" are too scary and should be toned down. Again more documentation on the project page is a must. Say exactly what is known to work and what is known not to work. That will help tone down the "big red "X"". I don't put it out if I haven't tested it and had it work for me. So everything works. I have had very few occasions where I do state that something will be changed in release xxx.

Well the -dev is meant to be a holding place for potentially underdeveloped code. It is the reason for the "big red "X"" and if you're using it otherwise then you tend to be on the losing side; an experience I've known well with an SF project I help manage. With Drupal projects I will at times upload changes to CVS regardless of the functioning so that I can work from more than one computer. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

Perhaps the root of the problem here is that -dev versions can be used in *two* different ways, even within the same project, and that both ways are acceptable depending on the circumstance? For example, in Drupal core, 6.x-dev is currently stable and there is nothing particularly wrong with using it on a production site, but 7.x-dev is definitely not stable. Is there any way that dev versions could be given two different labels to help indicate this, something like "-dev" and "-stable"? If you have already released version 6.x-1.0 of your module, for example, then a development snapshot labeled 6.x-1.x-stable would be an indication that only tested bugfixes are being committed to this branch. True "-dev" versions could still be themed with the foreboding red X, but "-stable" versions could be themed differently (yellow background?) so that module maintainers feel more comfortable holding off on the next official release. I haven't looked at all into the implementation, but if this turned out to be feasible, I think it might go a long way towards solving the problem mentioned here. --David Rothstein

On Tue, May 27, 2008 1:24 am, Heine Deelstra wrote:

...

[snip] For example, in Drupal core, 6.x-dev is currently stable and there is nothing particularly wrong with using it on a production site, but 7.x-dev is definitely not stable.

This is not correct.

Drupal 6.x-dev cannot be supported and may break your site. Example issue (5.x-dev): http://drupal.org/node/127936

Transient security issues in Drupal y.x-dev will also not get security announcements.

Interesting, thank you for clarifying this. Note, however, that running a dev version of core is recommended by some (usually-)reliable sources and is done (or at least appears to be done) by several prominent websites... check the CHANGELOG.txt of some of your favorite Drupal sites ;) Obviously, it can never be "officially" recommended or supported, but site admins who know their way around Drupal seem to be doing it - so if it's really a problem even in these cases, then perhaps more education on this point would be beneficial. --David Rothstein

On Wed, 28 May 2008 00:37:41 -0400 (EDT), "David Rothstein" <dmr37@cornell.edu> wrote:

On Tue, May 27, 2008 1:24 am, Heine Deelstra wrote:

...

...

[snip] For example, in Drupal core, 6.x-dev is currently stable and there is nothing particularly wrong with using it on a production site, but 7.x-dev is definitely not stable.

This is not correct.

Drupal 6.x-dev cannot be supported and may break your site. Example issue (5.x-dev): http://drupal.org/node/127936

Transient security issues in Drupal y.x-dev will also not get security announcements.

Interesting, thank you for clarifying this. Note, however, that running a dev version of core is recommended by some (usually-)reliable sources and is done (or at least appears to be done) by several prominent websites... check the CHANGELOG.txt of some of your favorite Drupal sites ;) Obviously, it can never be "officially" recommended or supported, but site admins who know their way around Drupal seem to be doing it - so if it's really a problem even in these cases, then perhaps more education on this point would be beneficial.

--David Rothstein

Another catch with 6.x core specifically is that the dev versions run E_ALL|E_NOTICE, while the stable versions disable notices. Since most modules are developed against a stable release, that means most modules will not be E_NOTICE-safe. So running 6.x-dev is likely to get you notices thrown all over the place. (I opposed disabling E_NOTICE warnings for D6 stable for exactly that reason, but was overruled.) --Larry Garfield

On Thu, 29 May 2008 00:13:56 +0200 (CEST), "Karoly Negyesi" <karoly@negyesi.net> wrote:

...

(I opposed disabling E_NOTICE warnings for D6 stable for exactly that reason, but was overruled.)

This decision stands steadfast.

Regards

NK

As does my objection to it. :-) </off-topic> --Larry Garfield

On May 27, 2008, at 5:01 AM, Earnie Boyd wrote:

I think the best thing is to remove the confusion of what -dev means. A -dev release is only to be used to allow developers an easy method to know what the package will look like from an installation process. A -dev release isn't meant to be a "for general use" release. The "big red "X"" is there because of this and ppl just need to stop using -dev for anything else.

The project module and/or update status module might be able to solve this dilemma by allowing a site to notify its admins that a newer release is either a bugfix/feature release, or a security release with some greater degree of distinction. As it stands right now, we do notify people when a module has a security update, but we don't really have a clear distinction between whether or not it'd be nice to get that new upgrade, or whether I really *really* need it in order to survive the botPharms. Do we have a good enough distinction between whether a new release is cool, or mandatory? I've ever really noticed a difference. -- Joel Farris "Any society that would give up a little liberty to gain a little security will deserve neither and lose both." **Ben Franklin

On Tue, May 27, 2008 8:01 am, Earnie Boyd wrote:

I think the best thing is to remove the confusion of what -dev means. A -dev release is only to be used to allow developers an easy method to know what the package will look like from an installation process. A -dev release isn't meant to be a "for general use" release. The "big red "X"" is there because of this and ppl just need to stop using -dev for anything else.

If you have a stable bug fix release then release it. If you are planning more changes then wait and release it later. The point of Derek's original mail was to say, don't let every CVS change be a new release if there are planned changes in the near future. Planning is what should happen before a release is released.

Agreed, but I don't think it's obvious that this is due to lack of education. It could be, but it could also be that people are doing it deliberately in order to get around existing limitations, as others have suggested. I guess the only way to find out is to ask. I just looked through the project list, found a few that seem to be creating official releases way too frequently, and posted a support request in each to ask why. We'll see if they respond with any interesting explanations. --David Rothstein