Please be careful marking release nodes "Security update"
Dear Drupal developers who manage contributions on drupal.org... As you've probably noticed, when you create a release node for your contribution(s), there's a "Release type" vocabulary where you can select from a few terms: Security update Bug fixes New features You're supposed to use this to indicate what kind of release your node represents, to give users of your contribution a sense of if they want to install it or not. For example, if you're adding new features, you should say so, since some users might not want to upgrade something that's potentially unstable and might break their sites, etc. However, if you mark a release node a "Security update", that has a bunch of other side effects and implications, so please only do so if your release is actually fixing a security problem: 1) The release node will not be published once the packaging script creates the tarball. This is so that the security team can verify the release does in fact address a security problem, that the draft of the security announcement (SA) is ready to be published, etc. See this issue for more info: http://drupal.org/node/153973 2) Once a "Security update" release node is published, the Update status module (now in D6 core) will freak out on every site running your module, with big nasty red warnings and emails (if so configured) about the fact that the site is insecure and needs to be updated immediately. 3) Everyone subscribed to the "Security updates" RSS feed will get pinged that there's another security release. ... Therefore, a "Security update" release is a *BIG DEAL*. You need to coordinate with the security team to make sure an SA goes out with your release, all of your users are going to get nasty warnings and scare tactics to try to get them to update ASAP, etc. So, if you don't mean it, please do *NOT* use this taxonomy term. If you do, you use up the precious resources of the security team (and/or d.o infrastructure team) to investigate your release node, clear the bogus term, manually publish it for you, etc, etc. Thanks, -Derek (dww)
On Thu, 25 Oct 2007 00:16:05 -0700 Derek Wright <drupal@dwwright.net> wrote:
Dear Drupal developers who manage contributions on drupal.org...
As you've probably noticed, when you create a release node for your contribution(s), there's a "Release type" vocabulary where you can select from a few terms:
Security update Bug fixes New features
Could we add a flag that say "change the use of the DB"? If it doesn't, testing/upgrading is just a matter of moving a directory and copy the new version in the right place. If there is some change at the DB level (schema or code that use the DB) a backup would be a more conservative choice. thx -- Ivan Sergio Borgonovo http://www.webthatworks.it
Could we add a flag that say "change the use of the DB"? If it doesn't, testing/upgrading is just a matter of moving a directory and copy the new version in the right place.
If there is some change at the DB level (schema or code that use the DB) a backup would be a more conservative choice.
DB and API changes must happen in a new branch. Any given branch should not contain anything else but bugfixes just like Drupal core.
2007/10/25, Karoly Negyesi <karoly@negyesi.net>:
Could we add a flag that say "change the use of the DB"? If it doesn't, testing/upgrading is just a matter of moving a directory and copy the new version in the right place.
If there is some change at the DB level (schema or code that use the DB) a backup would be a more conservative choice.
DB and API changes must happen in a new branch. Any given branch should not contain anything else but bugfixes just like Drupal core.
Several Drupal modules have their own database tables – I think this was meant as for changes to those. (Since this thread is about developers working in contrib to begin with.) And I doubt all contrib authors know about that branching rule – and even if they do, they might make branches that don't change the DB, and as such would still be a simple file replacing. -- Frederik 'Freso' S. Olesen <http://freso.dk/>
Frederik 'Freso' S. Olesen wrote:
Several Drupal modules have their own database tables – I think this was meant as for changes to those. (Since this thread is about developers working in contrib to begin with.) And I doubt all contrib authors know about that branching rule – and even if they do, they might make branches that don't change the DB, and as such would still be a simple file replacing.
I regularly make point releases that require update.php to be run.
[I agree with Moshe -- let's not hijack my other message (which wasn't even meant to be a "thread", just an FYI) with all this talk about managing changes, releases, branches, etc...] On Oct 25, 2007, at 1:52 AM, Karoly Negyesi wrote:
DB and API changes must happen in a new branch. Any given branch should not contain anything else but bugfixes just like Drupal core.
I believe chx has in mind a certain release of CCK that fundamentally altered the schema and API (of a module that dozens of others depend on), which just showed up as another official release in the 5.x-1.* "stable" series (i forget the exact version number). The CCK developers have been sufficiently harassed about this in the past, so I don't want to re-open that discussion (or those wounds). ;) Some things to keep in mind: A) In general, chx is right: a stable branch of your contribution should remain stable, and only have bug fixes applied. If you're adding features and/or changing the database schema, that should be happening in a separate branch, clearly marked as such, and people using releases from that branch should know what they're getting into. B) Point (A) is *especially* important for API modules that others depend on. C) Sometimes the only way to fix a bug is to change the schema or the API, so you actually have to use some judgement in each case. D) I'm not sure about adding a "Schema change" term in the "Release type" vocabulary. Let's continue this particular part of the discussion in the issue queue: http://drupal.org/node/186623 E) This is all fairly subjective -- there are different approaches depending on the module, the maintainer, the user-base, etc: For example, merlinofchaos seems to treat each official release of views on his "stable" branches almost like a whole new release series on its own. He goes through the whole beta/rc process each time, gets lots of testing, etc. So, he still adds new features, and sometimes even alters the schema (as per his message to the other thread). views is probably the single most important contrib module, with literally 1000s of sites depending on it. Because Earl is so careful, and because everyone has an interesting in helping him test/ debug new views releases, this system works pretty well, and allows him to not go completely insane supporting way too many different versions of the views codebase. That said, if he's adding new features to 5.x-1.x-dev on the way to the 5.x-1.7 release, and there's a security bug in 5.x-1.6 he has to fix, he's in something of a bind, since there's no good way to quickly get a 5.x-1.7 out to just fix the security problem without also introducing potentially instable code from the new features he already added. :( So, I can't recommend this as a Best Practice(tm), and it really only works for Earl since he's super-human. ;) Also, he's careful not to commit new features that are "too big" on his stable series, and certainly not fundamental re-factoring of the API, schema, etc. Other modules do what I'm suggesting as the default: they keep the 5.x-1.* series for bug fixes, and work on new features and schema changes in the 5.x-2.* series. New official releases on the 5.x-2.* series don't each require a bunch of beta/rcs, since everyone understands this is unstable code, and they shouldn't be building production sites out of it just yet. Eventually, when the feature set settles down and the maintainer is happy, they can declare 5.x-2.* stable, make that the official version, and start work on the 5.x-3.* series to keep adding new features (or not, and say they're only going to start adding new functionality in the 6.x-2.* series once the current feature set is ported to 6.x and the 6.x-1.* stable series is out). Sadly, I think many (most?) module developers aren't careful about this at all. They just commit whatever they want to all of their branches (or don't really use branches at all). This is unfortunate. Most developers in this boat either plead ignorance ("But CVS is Too Hard(tm), so this is my only choice") or laziness ("I don't have time to maintain a bunch of different branches"). I can completely sympathize with both how intimidating CVS can be (especially if you're not used to revision control or release management), and how much work it can be to maintain something responsibly. To address the ignorance, there is a lot of good (Drupal-specific) documentation about CVS in our handbooks and that learning this is time well-spent. The hardest part is understanding the fundamental ideas of release management and branches, which is true across any version control system you'll ever use for the rest of your life. http://drupal.org/handbook/cvs In terms of the effort it takes to maintain different branches, there are ways to make this less time consuming. Also, keep in mind that some extra care to maintain a stable branch that most of your users depend on will probably save you time in the long run -- instead of running around trying to deal with the increased support load generated by having people building sites with your unstable code. There's lots more to say about all of this, but if I keep writing it here, chances are lower and lower people will read it. ;) So, if anyone is going to be in the Bay Area for BADCamp, they should come to my workshop about exactly these topics: http://badcamp07.org/07/sessions/how-develop-and-maintain-your-drupal- contribution Even if you're not there, I plan to write up some concise documentation about all this, both as a handout for my talk, and then eventually as handbook pages on d.o. Anyone who's willing to help with this task, please let me know (off-list), and we can coordinate. Thanks, -Derek (dww)
Derek Wright wrote:
For example, merlinofchaos seems to treat each official release of views on his "stable" branches almost like a whole new release series on its own. He goes through the whole beta/rc process each time, gets lots of testing, etc. So, he still adds new features, and sometimes even alters the schema (as per his message to the other thread). views is probably the single most important contrib module, with literally 1000s of sites depending on it. Because Earl is so careful, and because everyone has an interesting in helping him test/debug new views releases, this system works pretty well, and allows him to not go completely insane supporting way too many different versions of the views codebase. That said, if he's adding new features to 5.x-1.x-dev on the way to the 5.x-1.7 release, and there's a security bug in 5.x-1.6 he has to fix, he's in something of a bind, since there's no good way to quickly get a 5.x-1.7 out to just fix the security problem without also introducing potentially instable code from the new features he already added. :( So, I can't recommend this as a Best Practice(tm), and it really only works for Earl since he's super-human. ;) Also, he's careful not to commit new features that are "too big" on his stable series, and certainly not fundamental re-factoring of the API, schema, etc.
True; I am very, very strict about actual API changes that will impact existing modules. I'm much less strict about new features, especially when many of them are simply missing features that are of minimal impact to existing installations. There's a lot of stuff that turns out to be really useful, and I'm not operating on the same scale that Drupal itself is, in terms of features. Though actually, the way it's been lately, I will likely have an almost 1 year gap before Views sees new features =)
On Thu, Oct 25, 2007 at 12:30:55PM -0700, Derek Wright wrote:
To address the ignorance, there is a lot of good (Drupal-specific) documentation about CVS in our handbooks and that learning this is time well-spent. The hardest part is understanding the fundamental ideas of release management and branches, which is true across any version control system you'll ever use for the rest of your life. http://drupal.org/handbook/cvs
The real problem here, at last for me (and I'm sure I'm not the only one in this position), is that I spend all day working with Subversion. When I occasionally get a chance to work on my modules on d.o., I have to go back to the documentation and re-learn how to use CVS. Having said that, I believe that my modules have proper releases; it's just that it takes me longer to get them out the door. Not that I necessarily want to open that whole CVS/Subversion debate (or maybe I do), but it's just that if a lot of developers are using Subversion, they'd be much more comfortable getting d.o. modules released quicker if the site used it as well. I realize that CVS is imtimately tied to the site, but I do feel that not having Subversion there hampers progress for a lot of folks. -c. -- Colan Schwartz Internet Consultant | Openject Consulting | http://www.openject.com/
Quoting Colan Schwartz <colan@openject.com>:
The real problem here, at last for me (and I'm sure I'm not the only one in this position), is that I spend all day working with Subversion. When I occasionally get a chance to work on my modules on d.o., I have to go back to the documentation and re-learn how to use CVS.
CVS and SVN aren't that different in command structure. Really, I use SVN and CVS interchangeably without issue. CVS is still used by many. GIT is being considered by many FSF projects. There are other VCS so perhaps a command wrapper so that you don't have to remember which commands to use for which VCS.
Having said that, I believe that my modules have proper releases; it's just that it takes me longer to get them out the door. Not that I necessarily want to open that whole CVS/Subversion debate (or maybe I do), but it's just that if a lot of developers are using Subversion, they'd be much more comfortable getting d.o. modules released quicker if the site used it as well.
I don't know that and I guess you're making assumptions that you don't have facts to as well. It might make it easier to access for those whose proxy servers get in the way given a setup on port 80.
I realize that CVS is imtimately tied to the site, but I do feel that not having Subversion there hampers progress for a lot of folks.
See http://groups.drupal.org/node/4272 for correcting that. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Oct 29, 2007, at 9:22 AM, Earnie Boyd wrote:
CVS and SVN aren't that different in command structure.
Correct.
I realize that CVS is imtimately tied to the site, but I do feel that not having Subversion there hampers progress for a lot of folks.
This debate comes up every few months. To quote Linus (via chx): "Those who can, do. Those who can't, complain."
See http://groups.drupal.org/node/4272 for correcting that.
Actually, no. The most current iteration is now going on in the infrastructure issue queue: http://drupal.org/node/187019 See that issue (in particular, comment #19) for updated reasons why this isn't going to happen anytime in the next N months without a major influx of help from people who can (and links for those people who want to do something). Complaining about it will only slow it down. If this new thread here on the devel list were a d.o forum post, I'd disable comments at this point, since if it continues, it's only going to generate a lot of heat and noise but no light or progress. Reply-To: /dev/null Thanks, -Derek (dww) p.s. As I tried to make clear in my original message, one of the important points of my "How to develop and maintain your contributions..." thread was that *NONE* of the things I'm trying to encourage Drupal developers to do depends on which particular VCS we use. Every VCS has the notion of branches and tags, and they're all conceptually the same (even if the implementation details are different). The main things people don't seem to understand yet are the basic concepts of branching and tagging, and when/how to make official releases. I'd like to see us as a community "master" those concepts before we worry about switching tools. One step at a time. p.p.s. @Earnie: thanks for having the good sense to fork the thread instead of continuing with the hijack of the important thread I had started. @Colan: tsk, tsk for hijacking in the first place. ;)
Let's not hijack an important security thread with a feature request.
Could we add a flag that say "change the use of the DB"? If it doesn't, testing/upgrading is just a matter of moving a directory and copy the new version in the right place.
On Oct 25, 2007, at 12:41 AM, Ivan Sergio Borgonovo wrote:
If it doesn't, testing/upgrading is just a matter of moving a directory and copy the new version in the right place.
If there is some change at the DB level (schema or code that use the DB) a backup would be a more conservative choice.
You should *always* backup your DB before upgrading *any* code. Period. Even a "stable" release that only contains bug fixes might itself be broken in such a way that it starts to corrupt your data. This does happen. If backing up your DB is too much trouble before you upgrade your site, your DB backup system isn't streamlined enough, and you need to fix that. Cheers, -Derek (dww)
participants (8)
-
Colan Schwartz -
Derek Wright -
Earl Miles -
Earnie Boyd -
Frederik 'Freso' S. Olesen -
Ivan Sergio Borgonovo -
Karoly Negyesi -
Moshe Weitzman