Re: [development] releases, recommended/supported changing automatically on release creation...
So today I'm humming a long and create a new RC for imagefield 2.3.. I go back to the project page, and wow the RC is the recommended and supported version listed there... Totally not cool! How many people are going to that when they should be using the 2.2 release, thanks to update_status.module. I think it is really bad to automatically change these flags on maintainers. I think it should be left to the maintainer to decide when a release is recommended or supported. .darrel.
Darrel, I think you can change that. Did you try looking in the administer releases page? Omar On Sun, Mar 9, 2008 at 10:01 PM, Darrel O'Pry <darrel.opry@gmail.com> wrote:
So today I'm humming a long and create a new RC for imagefield 2.3.. I go back to the project page, and wow the RC is the recommended and supported version listed there... Totally not cool! How many people are going to that when they should be using the 2.2 release, thanks to update_status.module. I think it is really bad to automatically change these flags on maintainers. I think it should be left to the maintainer to decide when a release is recommended or supported.
.darrel.
On Sun, Mar 9, 2008 at 1:01 PM, Darrel O'Pry <darrel.opry@gmail.com> wrote:
So today I'm humming a long and create a new RC for imagefield 2.3.. I go back to the project page, and wow the RC is the recommended and supported version listed there... Totally not cool! How many people are going to that when they should be using the 2.2 release, thanks to update_status.module. I think it is really bad to automatically change these flags on maintainers. I think it should be left to the maintainer to decide when a release is recommended or supported.
dww would have the full details but I know that there were some hitches in the initial upgrade code. Sounds like your module was one of those affected.
Daryl Check here http://drupal.org/node/72560/edit/releases See if you can tweak "supported" and "recommended" to do what you want. On Sun, Mar 9, 2008 at 3:01 PM, Darrel O'Pry <darrel.opry@gmail.com> wrote:
So today I'm humming a long and create a new RC for imagefield 2.3.. I go back to the project page, and wow the RC is the recommended and supported version listed there... Totally not cool! How many people are going to that when they should be using the 2.2 release, thanks to update_status.module. I think it is really bad to automatically change these flags on maintainers. I think it should be left to the maintainer to decide when a release is recommended or supported.
.darrel.
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
well filefield 2.2 (I can only specify major version on the releases page) is recommended and supported, but it seems to be branch specific, not release specific... I find a lot of the terminology and workflow around the new release system very confusing... ala... supported I don't think is a good word... It implies more than I want it to... like my dev and rc releases aren't 'supported', but they're maintained, and I want them displayed for the brave who want to test them, but I don't want to commit myself to supporting them. It's a question of managing expectations as the user community grows. I'm also really confused about why we tie releases to branches and not the release nodes.... I want to set releases to supported or recommended... not branches of my code... branches are not synonymous to releases... my hungover thoughts this morning... .darrel. On Sun, 2008-03-09 at 15:22 -0500, Khalid Baheyeldin wrote:
Daryl
Check here http://drupal.org/node/72560/edit/releases
See if you can tweak "supported" and "recommended" to do what you want.
On Sun, Mar 9, 2008 at 3:01 PM, Darrel O'Pry <darrel.opry@gmail.com> wrote: So today I'm humming a long and create a new RC for imagefield 2.3.. I go back to the project page, and wow the RC is the recommended and supported version listed there... Totally not cool! How many people are going to that when they should be using the 2.2 release, thanks to update_status.module. I think it is really bad to automatically change these flags on maintainers. I think it should be left to the maintainer to decide when a release is recommended or supported.
.darrel.
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Mar 10, 2008, at 11:42 AM, Darrel O'Pry wrote:
I find a lot of the terminology and workflow around the new release system very confusing...
Then please pay attention and help when I ask for input, don't just complain about it months later when I've already invested the time to implement something and roll it out on d.o.
supported I don't think is a good word... It implies more than I want it to... like my dev and rc releases aren't 'supported', but they're maintained, and I want them displayed for the brave who want to test them, but I don't want to commit myself to supporting them.
Again -- this was a big deal for the D6 string freeze, since update_status has to know what terminology to use when reporting this stuff in the admin UI. At the time, "supported" vs. "unsupported" was what the core committers preferred, so that's what I went with. I think it'd be even more confusing if update_status and project* used different terminology. #include "you-missed-your-chance-to-complain.h" (I hack C/C++ for my day job).
I'm also really confused about why we tie releases to branches and not the release nodes.... I want to set releases to supported or recommended... not branches of my code... branches are not synonymous to releases...
Which branch(es) of your code you're still supporting and which one you're currently recommending that new users install is specific to a branch ("release series" if you will), not an individual release. It'd be a huge pain and many people would screw this up and forget to bump this setting if you had to remember to change this every time you make a new release. If you want it to work differently, you get to: a) write the code yourself, and b) handle every support request that ever comes in about "I made a new release but it's not showing up on my project page...". Basically, the point of the new functionality is to handle the case where you've got multiple branches for the same version of core -- which "release series" should users downloading your module for the first time grab the latest release from? Which branch(es) should show up on the project node as code you expect to work. In the common case, you've got a single branch, so it's easy: that branch is both supported and recommended, and the latest official release (without extra) should show up on the project page. If there are multiple branches, we have to know which one we should pull the latest release from, and which branch(es) you're still supporting. If you don't yet understand how branches correspond to release series, you need to listen to the talk I gave at DrupalCon, or at least read the 2 page handout I made: http://boston2008.drupalcon.org/files/maintain-release-handout.pdf Not sure what's up with the audio recordings of the sessions. I bootlegged my own talk, so I could post the .mp3 on the session page if that'd be best. -Derek (dww)
On Mon, 2008-03-10 at 16:38 -0700, Derek Wright wrote:
On Mar 10, 2008, at 11:42 AM, Darrel O'Pry wrote:
I find a lot of the terminology and workflow around the new release system very confusing...
Then please pay attention and help when I ask for input, don't just complain about it months later when I've already invested the time to implement something and roll it out on d.o.
I didn't know how end users would react, or how it would work on d.o. until it got rolled out. I thought part of the development process was learning from each release, and improving it.. maybe I'm mistaken about the 'release early, release often' philosophy.
supported I don't think is a good word... It implies more than I want it to... like my dev and rc releases aren't 'supported', but they're maintained, and I want them displayed for the brave who want to test them, but I don't want to commit myself to supporting them.
Again -- this was a big deal for the D6 string freeze, since update_status has to know what terminology to use when reporting this stuff in the admin UI. At the time, "supported" vs. "unsupported" was what the core committers preferred, so that's what I went with. I think it'd be even more confusing if update_status and project* used different terminology.
#include "you-missed-your-chance-to-complain.h" (I hack C/C++ for my day job).
Sorry, I don't exactly pay close attention to the dev list. I'm probably not the only maintainer who doesn't watch this list closely. I think it is unfair to expect me, as a maintainer, to be responsible for watching this list as general traffic increases. (regardless of what you hack for your day job.) Maybe a special mailing list for notifying maintainers of issues that impact them. My belated position is, I think support is too loaded for how it will be used and sets an expectation that module maintainers will hop to it and fix end user problems.
I'm also really confused about why we tie releases to branches and not the release nodes.... I want to set releases to supported or recommended... not branches of my code... branches are not synonymous to releases...
Which branch(es) of your code you're still supporting and which one you're currently recommending that new users install is specific to a branch ("release series" if you will), not an individual release. It'd be a huge pain and many people would screw this up and forget to bump this setting if you had to remember to change this every time you make a new release. If you want it to work differently, you get to: a) write the code yourself, and b) handle every support request that ever comes in about "I made a new release but it's not showing up on my project page...".
I don't think having a flag for supported and recommended on each release would be a usability pain. I don't think people would screw it up, and it's simple to tick a check box. I also think maintainers should have to be proactive about setting a release to be 'supported' or 'recommended'. Especially, now that core ships with update_status.module. This is a question you likely only have to answer once... and a little bit of doc on the release node and the checkboxes will go a long way. And yes if I want it to work differently I understand I have to code it myself, deal with getting community support for the changes, nurse the patch for who knows how long to get everyone to agree that it can be committed, and then hope and pray some day my sweat and labor gets into core or on d.o.
Basically, the point of the new functionality is to handle the case where you've got multiple branches for the same version of core -- which "release series" should users downloading your module for the first time grab the latest release from? Which branch(es) should show up on the project node as code you expect to work. In the common case, you've got a single branch, so it's easy: that branch is both supported and recommended, and the latest official release (without extra) should show up on the project page. If there are multiple branches, we have to know which one we should pull the latest release from, and which branch(es) you're still supporting.
then we have a bug, cuz my releases with -extra are appearing on my project page as supported and recommended. This could be the cause of some of my consternation. see: http://drupal.org/project/filefield see: http://drupal.org/project/imagefield
If you don't yet understand how branches correspond to release series, you need to listen to the talk I gave at DrupalCon, or at least read the 2 page handout I made:
No you already helped me figure that out...
On Mar 13, 2008, at 7:18 AM, Darrel O'Pry wrote:
Maybe a special mailing list for notifying maintainers of issues that impact them.
I agree. I think everyone with a CVS account on d.o should be on a mandatory (moderated) mailing list. While you can't be expected to follow every thread on devel, I can't be expected to track down everyone myself anytime I'm going to change something that impacts d.o contrib maintainers, and the front page of d.o isn't a good place for this, since these threads only impact a tiny minority of d.o users.
then we have a bug, cuz my releases with -extra are appearing on my project page as supported and recommended.
Right, as I already said: http://drupal.org/node/176776#comment-764030 -Derek p.s. While we're on the topic, there are two other known bugs related to all of this, in case anyone wants to help. Both have patches, the first needs review, the other needs work: http://drupal.org/node/232812 http://drupal.org/node/126554#comment-761473
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Wright schrieb:
On Mar 13, 2008, at 7:18 AM, Darrel O'Pry wrote:
Maybe a special mailing list for notifying maintainers of issues that impact them.
I agree. I think everyone with a CVS account on d.o should be on a mandatory (moderated) mailing list. While you can't be expected to follow every thread on devel, I can't be expected to track down everyone myself anytime I'm going to change something that impacts d.o contrib maintainers, and the front page of d.o isn't a good place for this, since these threads only impact a tiny minority of d.o users.
I agree to such a list, however, I'd like to make addition of new users easy for the cvs account approvers. Can somebody patch drupalorg.module to add a submit action to the form that will subscribe the new cvs holder to that ML? I believe we should make this a moderated list, ie each message needs to be approved before sent. Basically, only announcements, no discussion. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH2UvFfg6TFvELooQRApCdAJ4xAlnozSDv09NSm/xQYbOMLKV2CACeIds8 OXDXd/0hJjExQ9Baw0Bta+w= =EG3a -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerhard Killesreiter schrieb:
I agree to such a list, however, I'd like to make addition of new users easy for the cvs account approvers. Can somebody patch drupalorg.module to add a submit action to the form that will subscribe the new cvs holder to that ML?
I believe we should make this a moderated list, ie each message needs to be approved before sent. Basically, only announcements, no discussion.
If the latter is agreeable, we can use simplenews instead of mailman which would make a cronjob based maintenance script possible. I also intend to collect bounces and to remove associated cvs accounts. Note that I'll count "please prove that you are a human by clicking here" responses as bounces. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH2VZefg6TFvELooQRArKEAKCtX5zowA+JUI5NOlvlI2ElPPp+CQCfUVxB RaJq4ccPiZkV+nJXkaxABkM= =2dvE -----END PGP SIGNATURE-----
Gerhard Killesreiter wrote:
I believe we should make this a moderated list, ie each message needs to be approved before sent. Basically, only announcements, no discussion.
If the latter is agreeable, we can use simplenews instead of mailman which would make a cronjob based maintenance script possible.
I'm all for having an announce only mailinglist for CVS account holders. The security team could use this list to announce potentially far reaching changes to certain APIs. It being announce-only will prevent it turning into yet another PHP-for-dummies mailing list and messages getting ignored as a result. Heine
On Thu, 13 Mar 2008 21:01:55 +0100, Heine Deelstra <hdeelstra@gmail.com> wrote:
Gerhard Killesreiter wrote:
I believe we should make this a moderated list, ie each message needs to be approved before sent. Basically, only announcements, no discussion.
If the latter is agreeable, we can use simplenews instead of mailman which would make a cronjob based maintenance script possible.
I'm all for having an announce only mailinglist for CVS account holders. The security team could use this list to announce potentially far reaching changes to certain APIs.
It being announce-only will prevent it turning into yet another PHP-for-dummies mailing list and messages getting ignored as a result.
Heine
Count me as +1 as well. That's a very targeted list of users that really should get certain announcements; presumably they'd be rare enough that making it mandatory for CVS account holders is not a huge issue. Also, some mailing lists send out monthly "list rules" reminders. If we had such a CVS-account-holder list, we could easily send out a monthly "CVS rules" email with pointers to the quickstart guide, where to go with problems, etc. That way, Derek can (hopefully) get back to coding. If some people need to be reminded repeatedly about it, let's do the smart thing and have a computer beat them over the head for us. :-) --Larry Garfield
On Thu, Mar 13, 2008 at 10:24:58PM -0500, Larry Garfield wrote:
Count me as +1 as well. That's a very targeted list of users that really should get certain announcements; presumably they'd be rare enough that making it mandatory for CVS account holders is not a huge issue.
Agreed. Also, it's too easy for announcements to get lost in the craziness that is the dev list. There should be a list for discussion and a separate one for policy changes. -c. -- Colan Schwartz Telephone & text chat (Skype): colanjs Internet Consultant | Openject Consulting | http://www.openject.com/
I didn't really want to just 'me too' this idea, but it is a good idea. I especially like the idea of keeping in moderated and low volume. One possibility to handling discussion could simply be to mail out a link to an issue when a change is proposed, so that discussion could happen, and in a more centralized place. IMHO that ought to put an end to the "but you never told me" syndrome with major enhancements. -Mike On Mar 13, 2008, at 8:24 PM, Larry Garfield wrote:
Count me as +1 as well. That's a very targeted list of users that really should get certain announcements; presumably they'd be rare enough that making it mandatory for CVS account holders is not a huge issue.
Also, some mailing lists send out monthly "list rules" reminders. If we had such a CVS-account-holder list, we could easily send out a monthly "CVS rules" email with pointers to the quickstart guide, where to go with problems, etc. That way, Derek can (hopefully) get back to coding. If some people need to be reminded repeatedly about it, let's do the smart thing and have a computer beat them over the head for us. :-)
__________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net 949.200.7595 714.356.0168 cell 949.200.7670 fax
On Sunday, 9. March 2008, Darrel O'Pry wrote:
So today I'm humming a long and create a new RC for imagefield 2.3.. I go back to the project page, and wow the RC is the recommended and supported version listed there... Totally not cool! How many people are going to that when they should be using the 2.2 release, thanks to update_status.module. I think it is really bad to automatically change these flags on maintainers. I think it should be left to the maintainer to decide when a release is recommended or supported.
I think the issue here is different views on what a "release" should be. The release system regards point releases (2.2, 2.3) as harmless, bugfix-only releases, while you're using them for introducing major new features like icon set support, new extension modules, or stuff. So the release system expects all releases of a major release (2.x) to be similarly stable and recommended, which is wrong in this case (and others as well, probably - including Views, which also does betas and release candidates for point releases). Obvious quickfix: Don't display any "[\d].[\d]-anything" releases as stable, but add them to the list of development releases and keep the last "[\d].[\d]" release as stable one. Hoping not to miss some detail, Jakob
Jakob Petsovits wrote:
So the release system expects all releases of a major release (2.x) to be similarly stable and recommended, which is wrong in this case (and others as well, probably - including Views, which also does betas and release candidates for point releases).
Yes, technically this is wrong from what dww intended to set up. However, the decision not to allow modules a Z number in the release system (x.y.Z) left us in the annoying position that the major number can ramp up *very* quickly...which means *branch maintenance* can ramp up *very* quickly. I wanted Views 2 to actually be 2; had I done this by the rules, Views 2 would actually be Views 6 or something, and that fails to fit my vision.
On Mar 10, 2008, at 9:21 AM, Earl Miles wrote:
Yes, technically this is wrong from what dww intended to set up.
Indeed, the new stuff on the project nodes doesn't accurately reflect the equivalent logic update_status is using for releases with "extra": http://drupal.org/node/176776#comment-764030 :( That issue has been a huge pain, since it was officially marked "done" as far as GHOP was concerned over 6 weeks ago, but I ended up having to basically write all the code myself in the end. If a lone developer falls down in the forest and no one is around to hear it, does it make a sound?
However, the decision not to allow modules a Z number in the release system (x.y.Z) left us in the annoying position that the major number can ramp up *very* quickly...which means *branch maintenance* can ramp up *very* quickly.
Even if you had a 3rd version number to play with, that doesn't change your pain regarding branches. It just means branches should correspond to 2 different elements in the version string (think 4.7.x core -- the "4.7" identifies the branch, while the "x" identifies a specific release tag along that branch). So, while you can complain about having 2 vs. 3 digits to work with, it's not for the reason you state here. If you don't want a bunch of branches to deal with, either a) put more API changes and new features into a given release series (what I do with signup.module 5.x-2.* for example), or b) make heavy use of deselecting the "supported" checkbox for the older branches, and force your users to upgrade more often (which is more of a pain in their asses, but means you have less branches you need to backport bugfixes for).
I wanted Views 2 to actually be 2; had I done this by the rules, Views 2 would actually be Views 6 or something, and that fails to fit my vision.
That's pretty much the only thing to gain for a 3rd digit, and the cost would be increased complexity for everyone else. /me shrugs Trying to balance the entire development community's conflicting requests is completely impossible. I'm already at the verge of snapping and running away screaming. Some people think it's too complicated and confusing. Others say it's overly simplified and not powerful enough. Everyone has their own opinions about the terminology. I can probably count on 1 hand the number of people who have seriously contributed towards this system (Earl being one of them, mind you). I could probably fill an auditorium with the number of people who've complained after the fact about some aspect of it. -Derek (dww)
Derek Wright wrote:
Trying to balance the entire development community's conflicting requests is completely impossible. I'm already at the verge of snapping and running away screaming. Some people think it's too complicated and confusing. Others say it's overly simplified and not powerful enough. Everyone has their own opinions about the terminology. I can probably count on 1 hand the number of people who have seriously contributed towards this system (Earl being one of them, mind you). I could probably fill an auditorium with the number of people who've complained after the fact about some aspect of it.
Sorry, this isn't an after-the-fact complaint (tho I did object when this went in, and I was a lone voice and so let it pass) it's an explanation provided for someone who mentioned something. I do in fact do pretty much what you suggest here; and I'm very careful about API changes in the 1.X branch. In fact, in my own personal world, the API is pretty much what controls the major release #, but I realize that *most* projects don't have that as an issue.
On Mon, Mar 10, 2008 at 9:38 PM, Earl Miles <merlin@logrus.com> wrote:
In fact, in my own personal world, the API is pretty much what controls the major release #, but I realize that *most* projects don't have that as an issue.
+1 on this. I do the same, branch and up the X number when things will break. Otherwise if you are adding features or fixing bugs without breaking things, then remain on the same X number. Did this for a couple of modules of mine already. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Mar 10, 2008, at 6:38 PM, Earl Miles wrote:
this isn't an after-the-fact complaint
Indeed, that part of the message wasn't directed at you, which I tried (and failed) to make clear by including you in the list of people who seriously contributed to the release system. ;) I remember clearly that you were advocating for 3 digits, and I remember being sympathetic to your views (pun intended), but I do think it would be too much complication and confusion for 99.5% of the cases. Sorry my message came across the wrong way, I've just had an exceptionally bad week for personal reasons, and all the flack being generated after I rolled out the latest changes on d.o hasn't been so easy to take. -Derek (dww)
Quoting Earl Miles <merlin@logrus.com>:
Derek Wright wrote:
Trying to balance the entire development community's conflicting requests is completely impossible. I'm already at the verge of snapping and running away screaming. Some people think it's too complicated and confusing. Others say it's overly simplified and not powerful enough. Everyone has their own opinions about the terminology. I can probably count on 1 hand the number of people who have seriously contributed towards this system (Earl being one of them, mind you). I could probably fill an auditorium with the number of people who've complained after the fact about some aspect of it.
Sorry, this isn't an after-the-fact complaint (tho I did object when this went in, and I was a lone voice and so let it pass) it's an explanation provided for someone who mentioned something. I do in fact do pretty much what you suggest here; and I'm very careful about API changes in the 1.X branch. In fact, in my own personal world, the API is pretty much what controls the major release #, but I realize that *most* projects don't have that as an issue.
For a new module I'm developing I'm thinking of adapting something like even/odd major declarations where even (beginning with zero) is development and odd is the released module. This is easily explained and allows for development apart from releases. Once 0.x is released as 1.0 I also create a 2.x branch for enhancements and use the 0.x branch for bug fixes and security patches to the 1.0 which are released incrementally as 1.1, etc. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (13)
-
andrew morton -
Colan Schwartz -
Darrel O'Pry -
Derek Wright -
Earl Miles -
Earnie Boyd -
Gerhard Killesreiter -
Heine Deelstra -
Jakob Petsovits -
Khalid Baheyeldin -
Larry Garfield -
Michael Prasuhn -
Omar Abdel-Wahab