We have, at this moment, 223 "patches to review" issues, 1698 "patch queue" issues, and 357 "critical issues" for D7, according to the Contributor Links block on drupal.org. It's hard to figure out what to focus on, given so many choices. So I'm thinking about priorities for the upcoming code freeze (Sept 1, right?). My understanding is that all new features for Drupal would need to be patched, reviewed, and committed before the code freeze, or they would be pushed back to Drupal 8. Those are easy to find, using the Category field of the issue queue. But my understanding is that also any API changes would need to be patched, reviewed, and committed before the code freeze, and there wasn't any obvious way I knew of to find them. So, I've introduced a new issue tag, "API change", which will help identify those issues, if people start marking their issues accordingly. Thoughts? So am I way off base, or shouldn't we be focusing our patching and review efforts on these areas between now and Sept 1, and leaving the bug fixes (even "critical" bug fixes) for after the freeze? Is there anything else that also cannot wait until after the code freeze? --Jennifer -- Jennifer Hodgdon * Poplar ProductivityWare www.poplarware.com Drupal, WordPress, and custom Web programming
I think your understanding is bang on. Post Sept. 1, bugfixes are all we do until the release, with some noteable exceptions which are listed elsewhere. I think this would be a good time to knuckle down and try to get as many patches reviewed and committed in the next 11 days. What are people's high-priority patches for D7? Which stuff do you really want to see included? It would be helpful if we had a list of 'important' patches to focus on. Jennifer Hodgdon wrote:
We have, at this moment, 223 "patches to review" issues, 1698 "patch queue" issues, and 357 "critical issues" for D7, according to the Contributor Links block on drupal.org. It's hard to figure out what to focus on, given so many choices. So I'm thinking about priorities for the upcoming code freeze (Sept 1, right?).
My understanding is that all new features for Drupal would need to be patched, reviewed, and committed before the code freeze, or they would be pushed back to Drupal 8. Those are easy to find, using the Category field of the issue queue.
But my understanding is that also any API changes would need to be patched, reviewed, and committed before the code freeze, and there wasn't any obvious way I knew of to find them. So, I've introduced a new issue tag, "API change", which will help identify those issues, if people start marking their issues accordingly. Thoughts?
So am I way off base, or shouldn't we be focusing our patching and review efforts on these areas between now and Sept 1, and leaving the bug fixes (even "critical" bug fixes) for after the freeze? Is there anything else that also cannot wait until after the code freeze?
--Jennifer
And everyone keep in mind - Dries and Webchick are doing a code sprint on Saturday during European business hours (N. Americans wake up early Saturday!) Hang out in IRC and help crank out the patches and reviews. The whole process will be brokered from the FrOSCon conference in Germany. -----Original Message----- From: Brian Vuyk <brian@brianvuyk.com> Reply-to: development@drupal.org To: development@drupal.org Subject: Re: [development] Prioritizing for code freeze Date: Thu, 20 Aug 2009 12:29:19 -0400 I think your understanding is bang on. Post Sept. 1, bugfixes are all we do until the release, with some noteable exceptions which are listed elsewhere. I think this would be a good time to knuckle down and try to get as many patches reviewed and committed in the next 11 days. What are people's high-priority patches for D7? Which stuff do you really want to see included? It would be helpful if we had a list of 'important' patches to focus on. Jennifer Hodgdon wrote:
We have, at this moment, 223 "patches to review" issues, 1698 "patch queue" issues, and 357 "critical issues" for D7, according to the Contributor Links block on drupal.org. It's hard to figure out what to focus on, given so many choices. So I'm thinking about priorities for the upcoming code freeze (Sept 1, right?).
My understanding is that all new features for Drupal would need to be patched, reviewed, and committed before the code freeze, or they would be pushed back to Drupal 8. Those are easy to find, using the Category field of the issue queue.
But my understanding is that also any API changes would need to be patched, reviewed, and committed before the code freeze, and there wasn't any obvious way I knew of to find them. So, I've introduced a new issue tag, "API change", which will help identify those issues, if people start marking their issues accordingly. Thoughts?
So am I way off base, or shouldn't we be focusing our patching and review efforts on these areas between now and Sept 1, and leaving the bug fixes (even "critical" bug fixes) for after the freeze? Is there anything else that also cannot wait until after the code freeze?
--Jennifer
On Aug 20, 2009, at 9:29 AM, Brian Vuyk wrote:
It would be helpful if we had a list of 'important' patches to focus on.
http://drupal.org/community-initiatives/drupal-core Lists of important issues broken down by area of core. For example, initiatives for making Update status better: http://drupal.org/node/479086 Enjoy, -Derek (dww)
On Thu, Aug 20, 2009 at 10:29 AM, Brian Vuyk<brian@brianvuyk.com> wrote:
Post Sept. 1, bugfixes are all we do until the release, with some noteable exceptions which are listed elsewhere.
Listed elsewhere? Where is this list - inquiring minds want to know. My knowledge of history is that patches to improve performance, usability and a few items hand-picked by Dries+maintainer are also allowed in post-code-freeze. If there's an API or regression that is horribly broken (usually discovered when contribs start upgrading) then that can also result in a patch that changes the API or adds new features. I'm not sure if all of those will be the same this time as well. I'm kind of assuming that it is. Regards, Greg -- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Cracking Drupal - Learn to protect your Drupal site from hackers Now available from Wiley http://crackingdrupal.com
Webchick posted in an issue somewhere a few patches that they were interested in getting in, even after the code freeze if necessary. I don't recall the link, though. Greg Knaddison wrote:
On Thu, Aug 20, 2009 at 10:29 AM, Brian Vuyk<brian@brianvuyk.com> wrote:
Post Sept. 1, bugfixes are all we do until the release, with some noteable exceptions which are listed elsewhere.
Listed elsewhere? Where is this list - inquiring minds want to know.
My knowledge of history is that patches to improve performance, usability and a few items hand-picked by Dries+maintainer are also allowed in post-code-freeze. If there's an API or regression that is horribly broken (usually discovered when contribs start upgrading) then that can also result in a patch that changes the API or adds new features. I'm not sure if all of those will be the same this time as well. I'm kind of assuming that it is.
Regards, Greg
On 20-Aug-09, at 3:49 PM, Brian Vuyk wrote:
Webchick posted in an issue somewhere a few patches that they were interested in getting in, even after the code freeze if necessary. I don't recall the link, though.
I definitely did no such thing. Code freeze is 9/1. There are lots of patches I want in, but only the ones ready before then are accepted. It's true that there are usually a small handful of patches that, if far enough along, are exempt. But this shouldn't be the operating assumption. -Angie
Angela Byron wrote:
I definitely did no such thing. Code freeze is 9/1. There are lots of patches I want in, but only the ones ready before then are accepted.
It's true that there are usually a small handful of patches that, if far enough along, are exempt. But this shouldn't be the operating assumption.
-Angie Strange. I could have sworn you had done so. It must of been one of the other community 'notables'.
Anyways, definitely not the operating assumption.
On 20-Aug-09, at 11:11 AM, Jennifer Hodgdon wrote:
We have, at this moment, 223 "patches to review" issues, 1698 "patch queue" issues, and 357 "critical issues" for D7, according to the Contributor Links block on drupal.org. It's hard to figure out what to focus on, given so many choices. So I'm thinking about priorities for the upcoming code freeze (Sept 1, right?).
My understanding is that all new features for Drupal would need to be patched, reviewed, and committed before the code freeze, or they would be pushed back to Drupal 8. Those are easy to find, using the Category field of the issue queue.
But my understanding is that also any API changes would need to be patched, reviewed, and committed before the code freeze, and there wasn't any obvious way I knew of to find them. So, I've introduced a new issue tag, "API change", which will help identify those issues, if people start marking their issues accordingly. Thoughts?
So am I way off base, or shouldn't we be focusing our patching and review efforts on these areas between now and Sept 1, and leaving the bug fixes (even "critical" bug fixes) for after the freeze? Is there anything else that also cannot wait until after the code freeze?
The one other thing I'd add here is markup changes (as in theme functions and .tpl.php files). Themers can't start porting their themes until Drupal's XHTML output is locked down. Most of those are in the 'theme system' component, although there are probably other ones here and there attached to their respective "parent" components like node system or whatever. Everything else sounds bang-on. Thanks for making that tag! -Angie
Angela Byron wrote:
The one other thing I'd add here is markup changes (as in theme functions and .tpl.php files). Themers can't start porting their themes until Drupal's XHTML output is locked down. Most of those are in the 'theme system' component, although there are probably other ones here and there attached to their respective "parent" components like node system or whatever.
So we have Tag: API change to look for now. And we also want to make sure any feature changes get done before freeze. Find those via: Category: feature request I would propose adding Tag: Markup change as well, to indicate markup changes as priorities for before the code freeze, if there is not already another tag for that. This would be used for changes in HTML tags and attributes (classes and IDs), not for text changes. Text changes are already being marked with one of these: Tag: ui-text Tag: Help text which will be relevant for the String Freeze, whenever that comes (string freeze is important for translators). --Jennifer -- Jennifer Hodgdon * Poplar ProductivityWare www.poplarware.com Drupal, WordPress, and custom Web programming
On 21-Aug-09, at 10:29 AM, Jennifer Hodgdon wrote:
I would propose adding Tag: Markup change as well, to indicate markup changes as priorities for before the code freeze, if there is not already another tag for that. This would be used for changes in HTML tags and attributes (classes and IDs), not for text changes.
Sounds good. AFAIK nothing like that exists. There's 'd4d' and similar but some of those affect the theme system and some of them affect markup. They're also totally obtuse to new contributors. ;)
Text changes are already being marked with one of these: Tag: ui-text Tag: Help text which will be relevant for the String Freeze, whenever that comes (string freeze is important for translators).
Actually, we have a "user interface text" component for this purpose, but it might indeed make more sense to turn this into a tag. There could be a bug fix against node.module that also changes strings. "Help text" though seems like it's just the "documentation" component, no? -Angie
[jhodgdon] Text changes are already being marked with one of these: Tag: ui-text Tag: Help text
[webchick] Actually, we have a "user interface text" component for this purpose, but it might indeed make more sense to turn this into a tag. There could be a bug fix against node.module that also changes strings.
Exactly. Any issue that is not against the UI component, but changes UI text, can be tagged with "ui-text". This is fairly common with issues against other core modules.
[webchick] "Help text" though seems like it's just the "documentation" component, no?
Again, this would be most useful for issues/patches that incidentally change some help text, but are primarily for other purposes. Just to note: these are both tags that are currently in use. They are useful so that people who want to review doc and help with doc in core, but aren't coders particularly, can find issues to review/patch. We're searching for them during "Doc in Core" sprints... --Jennifer -- Jennifer Hodgdon * Poplar ProductivityWare www.poplarware.com Drupal, WordPress, and custom Web programming
participants (6)
-
Angela Byron -
Brian Vuyk -
Derek Wright -
Greg Knaddison -
Jennifer Hodgdon -
Robert Douglass