Drupal 4.7.0 beta2 / rc?
Hello world, I wanted to open up a discussion as how to proceed with the Drupal 4.7.0 release schedule. There are two aspects I'd like us to brainstorm about: 1. When do we release a second beta (or a release candidate)? Given the number of critical/annoying bugs we fixed since beta 1 has been released, I think a second beta might be in order. The sooner, the better? 2. The number of bugs that need fixing grows steadily: http:// drupal.org/project/issues? projects=3060&versions=9728&states=1,8,13,14,2. How do we encourage more people to help fix bugs? How do we help people fix bugs? I think there is a need for people dedicated to helping Drupal.org users turn forum topics into bug reports, as well as for people dedicated to reviewing, categorizing and harvesting bug reports. Is the problem description clear? Is the problem easy to reproduce? Is it really critical? If not, help them improve their bug report. Replying with one-liners like 'File a bug report!' or 'RTFM' is not considered helping in this context. The goal is to assist, to be helpful, to pull them on board and hopefully to make them "stick". Similarly, I think there is room for people that review patches like teachers would. In short, we need friendly hosts that help people make their first steps in their Drupal career. Suggestions and concrete action points are welcome, -- Dries Buytaert :: http://www.buytaert.net/
On Wed, 14 Dec 2005 11:36:58 +0100, Dries Buytaert <dries.buytaert@gmail.com> wrote:
Hello world,
I wanted to open up a discussion as how to proceed with the Drupal 4.7.0 release schedule. There are two aspects I'd like us to brainstorm about:
1. When do we release a second beta (or a release candidate)? Given the number of critical/annoying bugs we fixed since beta 1 has been released, I think a second beta might be in order. The sooner, the better?
I say it's RC when the update is fixed. A beta2 could be in order now, yes.
At 11:36 AM +0100 14/12/05, Dries Buytaert wrote:
Hello world,
I wanted to open up a discussion as how to proceed with the Drupal 4.7.0 release schedule. There are two aspects I'd like us to brainstorm about:
1. When do we release a second beta (or a release candidate)?
IMHO you can't push a release candidate until all critical bugs are fixed and all non-critical bugs are deemed OK for inclusion in the release. In the open source world a release with known critical bugs is an alpha release or a snapshot. In the commercial world of course, this can be a final release and you can then charge for updates. I would think the next beta should be pushed when the only bugs left on the critical list are ones that should really have normal priority. It's worth noting that there are still a heap of issues against CVS and 4.6.x that are release-critical for 4.7. ...R.
I would think the next beta should be pushed when the only bugs left on the critical list are ones that should really have normal priority.
It's worth noting that there are still a heap of issues against CVS and 4.6.x that are release-critical for 4.7.
Hence my second question -- which people seem to ignore ;) -- how can we get more people to fix bugs or people to fix more bugs? :) -- Dries Buytaert :: http://www.buytaert.net/
I would think the next beta should be pushed when the only bugs left on the critical list are ones that should really have normal priority.
May I suggest that everyone bookmarks the following URL: http://drupal.org/project/issues? projects=3060&categories=bug,task&priorities=1&states=1,8,13,14,2 It is a list of all critical bugs in core that need attention. There are approximately 190 critical bugs at the time of this writing. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
I would think the next beta should be pushed when the only bugs left on the critical list are ones that should really have normal priority.
May I suggest that everyone bookmarks the following URL:
http://drupal.org/project/issues? projects=3060&categories=bug,task&priorities=1&states=1,8,13,14,2
It is a list of all critical bugs in core that need attention. There are approximately 190 critical bugs at the time of this writing.
Hi, I have a patch pending here for one month: http://drupal.org/node/37829 Any good reasons why it is not applied ? Treating patches this way helps keeping the number of bugs high IMO. -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - my blog
Op woensdag 14 december 2005 14:54, schreef Dries Buytaert:
http://drupal.org/project/issues? projects=3060&categories=bug,task&priorities=1&states=1,8,13,14,2
RSS is a great tool (far better then mail imho) for tracking. use this: http://drupal.org/project/issues/rss?categories=bug,task&priorities=1&states... -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 12/14/05, Bèr Kessels <ber@webschuur.com> wrote:
Op woensdag 14 december 2005 14:54, schreef Dries Buytaert:
http://drupal.org/project/issues? projects=3060&categories=bug,task&priorities=1&states=1,8,13,14,2
RSS is a great tool (far better then mail imho) for tracking. use this:
http://drupal.org/project/issues/rss?categories=bug,task&priorities=1&states...
Except it doesn't include follow-ups, only new issue nodes. -- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann
Bèr Kessels wrote:
Op woensdag 14 december 2005 14:54, schreef Dries Buytaert:
http://drupal.org/project/issues? projects=3060&categories=bug,task&priorities=1&states=1,8,13,14,2
RSS is a great tool (far better then mail imho) for tracking. use this: http://drupal.org/project/issues/rss?categories=bug,task&priorities=1&states...
Great idea, Bèr! Thanks -- I've added it to my RSS reader. :-) ..chrisxj
On Wed, 2005-12-14 at 14:54 +0100, Dries Buytaert wrote:
I would think the next beta should be pushed when the only bugs left on the critical list are ones that should really have normal priority.
May I suggest that everyone bookmarks the following URL:
http://drupal.org/project/issues? projects=3060&categories=bug,task&priorities=1&states=1,8,13,14,2
It is a list of all critical bugs in core that need attention. There are approximately 190 critical bugs at the time of this writing.
-- Dries Buytaert :: http://www.buytaert.net/
Bookmarked... archive.module patch up for review: http://drupal.org/node/41009
On Wednesday 14 December 2005 05:36, Dries Buytaert wrote:
How do we encourage more people to help fix bugs? How do we help people fix bugs?
Some comments from a module developer who doesn't do much with core: * I'd love to fix core bugs, but I'm fully engaged with updating my own modules to the new API. I assume other module developers and themers are in the same position. That's not a complaint, just an observation that might help explain why there's a lack of available person-power. A solution for the future might be to stabilize and freeze the core API specification earlier in the release cycle, so that module developers can get their modules mostly done before the big core debugging crunch. * Along those lines, we should have an easy way to notify the maintainer of each project that "Drupal core has just frozen the new API spec for version X.Y. Now is the time to update your modules A, B, and C." I have found, with volunteer-driven projects (outside the software arena) that sometimes all it takes to bring back a "lost sheep" is a simple reminder that they are missed. You don't get everyone back who has attrited away, but you get some, and since the effort is so small, it's a good reward-to-effort ratio. * From the outside, the core development process is somewhat mysterious to me. I read the technical process for patch submission in the contributor handbook. But is there some other notification or coordination process in place to keep multiple people from working on the same problem redundantly, and to ensure that the patch is noticed by the person who can review and commit it? Or should one post to the issue and say "I'm working on this one" before beginning? * There may (or may not, but it's worth asking) be a perception among new members of the developer community that your calls for patches are aimed only at the core team. I know that's not true, but I've been on this list for over a year. I'm not sure I would have realized this when I first subscribed. I don't mean any of the above as criticism or complaints. In fact, there is a good chance that some of my points are completely off-base, and with that in mind, I present the above as a "case study in the misconceptions found in those who are not informed about the core development process." :-) Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
2. The number of bugs that need fixing grows steadily: http://drupal.org/project/issues?projects=3060&versions=9728&states=1,8,13,1.... How do we encourage more people to help fix bugs? How do we help people fix bugs?
One way to get these bugs fixed is to assign them to people. Ideally, project.module would have a few modes and on drupal.org we would configure it so that project.module maintainers could assign bugs to users. We might even emulate other systems where bugs get assgined and then accepted. That would make it more clear that the assignee is actually working on his assigned stuff. Alas, this requires development. A non development way to increase bug fixing is to do a bug sprint like we did in Amsterdam. One person would be coordinator in #drupal, handing out the bugs. everyone else fixes and verifies and prunes the bug list. -moshe
A non development way to increase bug fixing is to do a bug sprint like we did in Amsterdam. One person would be coordinator in #drupal, handing out the bugs. everyone else fixes and verifies and prunes the bug list.
I'll volunteer to host the sprint if others like the idea and would attend. I would do it this weekend, during hours when Americas and Europe are likely to be awake.
Dries Buytaert wrote:
Similarly, I think there is room for people that review patches like teachers would.
I know the number of patches I looked at went way down the second they were dropped from the mailing list. Now I'm mainly only looking at patches when I am checking to see if someone has already scratched an itch that I have - (before I start scratching myself). just $0.02 for what its worth andre ___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/
On 12/14/05 9:24 AM, andre wrote:
Dries Buytaert wrote:
Similarly, I think there is room for people that review patches like teachers would.
I know the number of patches I looked at went way down the second they were dropped from the mailing list.
Now I'm mainly only looking at patches when I am checking to see if someone has already scratched an itch that I have - (before I start scratching myself).
nooooooo. no more every bug goes to development. it stifles any actual development discussion. That said, I hate web apps... Dries - perhaps a bugs@ mailing list? I *know* you wanna set up just one more mailing list ;) that way people can more easily opt-in to one or the other (and since we're throwing around procmail rules, we all know how to keep them segmented). -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 12/14/05, James Walker <walkah@walkah.net> wrote:
On 12/14/05 9:24 AM, andre wrote:
Dries Buytaert wrote:
Similarly, I think there is room for people that review patches like teachers would.
I know the number of patches I looked at went way down the second they were dropped from the mailing list.
Now I'm mainly only looking at patches when I am checking to see if someone has already scratched an itch that I have - (before I start scratching myself).
nooooooo. no more every bug goes to development. it stifles any actual development discussion.
That said, I hate web apps... Dries - perhaps a bugs@ mailing list? I *know* you wanna set up just one more mailing list ;) that way people can more easily opt-in to one or the other (and since we're throwing around procmail rules, we all know how to keep them segmented).
Project module should support CC'ing interested individuals like bugzilla does. Robin --
James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
On 12/14/05 9:38 AM, Robin Monks wrote:
On 12/14/05, *James Walker* <walkah@walkah.net <mailto:walkah@walkah.net>> wrote:
On 12/14/05 9:24 AM, andre wrote: > Dries Buytaert wrote: >> Similarly, I think there is room for people that review patches like >> teachers would. > > I know the number of patches I looked at went way down the second they > were dropped from the mailing list. > > Now I'm mainly only looking at patches when I am checking to see if > someone has already scratched an itch that I have - (before I start > scratching myself).
nooooooo. no more every bug goes to development. it stifles any actual development discussion.
That said, I hate web apps... Dries - perhaps a bugs@ mailing list? I *know* you wanna set up just one more mailing list ;) that way people can more easily opt-in to one or the other (and since we're throwing around procmail rules, we all know how to keep them segmented).
Project module should support CC'ing interested individuals like bugzilla does.
Actually, moshe's suggestion of assigning & accepting patches I would rank as slightly higher priority (but this would follow nicely)... so patch it ;) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 12/14/05, James Walker <walkah@walkah.net> wrote:
On 12/14/05 9:38 AM, Robin Monks wrote:
On 12/14/05, *James Walker* <walkah@walkah.net <mailto:walkah@walkah.net>> wrote:
On 12/14/05 9:24 AM, andre wrote: > Dries Buytaert wrote: >> Similarly, I think there is room for people that review patches like >> teachers would. > > I know the number of patches I looked at went way down the second they > were dropped from the mailing list. > > Now I'm mainly only looking at patches when I am checking to see
if
> someone has already scratched an itch that I have - (before I
start
> scratching myself).
nooooooo. no more every bug goes to development. it stifles any
actual
development discussion.
That said, I hate web apps... Dries - perhaps a bugs@ mailing list?
I
*know* you wanna set up just one more mailing list ;) that way
people
can more easily opt-in to one or the other (and since we're throwing around procmail rules, we all know how to keep them segmented).
Project module should support CC'ing interested individuals like bugzilla does.
Actually, moshe's suggestion of assigning & accepting patches I would rank as slightly higher priority (but this would follow nicely)...
so patch it ;)
Oh me of little time ;) Robin --
James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
Project module should support CC'ing interested individuals like bugzilla does.
Drupal.org does support this functionality. If you comment on a bug, and are interested in the updates, you can set so in the subscriptions setup. Yes, it is not the most obvious process and UI. I use this feature, and it works for me. Goba
Go here: http://drupal.org/project/issues/subscribe Robin On 12/14/05, Robert Douglass <rob@robshouse.net> wrote:
James Walker wrote:
That said, I hate web apps... Dries - perhaps a bugs@ mailing list?
I would subscribe to this. I still haven't figured out how to subscribe to all issues automatically.
-R
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
James Walker wrote:
On 12/14/05 9:24 AM, andre wrote:
I know the number of patches I looked at went way down the second they were dropped from the mailing list.
Now I'm mainly only looking at patches when I am checking to see if someone has already scratched an itch that I have - (before I start scratching myself).
nooooooo. no more every bug goes to development. it stifles any actual development discussion.
That said, I hate web apps... Dries - perhaps a bugs@ mailing list? I *know* you wanna set up just one more mailing list ;) that way people can more easily opt-in to one or the other (and since we're throwing around procmail rules, we all know how to keep them segmented).
You can always use the 'subscribe' link at the top of the bug list. http://drupal.org/project/issues/subscribe lets you pick and choose which projects you are interested in hearing the bug reports for. Or as Ber said, you can use RSS. Just saying there isn't really a need for yet another mailing list. :) --Vernon
On Wed, 14 Dec 2005 15:24:19 +0100, andre <mcsparkerton@yahoo.co.uk> wrote:
Dries Buytaert wrote:
Similarly, I think there is room for people that review patches like teachers would.
I know the number of patches I looked at went way down the second they were dropped from the mailing list.
You can still subscribe to http://drupal.org/project/issues/subscribe any issue you want. Where you can find this link ? I do not know, I read project module source :) Regards NK
Right side bar under project/issues pages under the "subscribe" link. Robin On 12/14/05, Karoly Negyesi <karoly@negyesi.net> wrote:
On Wed, 14 Dec 2005 15:24:19 +0100, andre <mcsparkerton@yahoo.co.uk> wrote:
Dries Buytaert wrote:
Similarly, I think there is room for people that review patches like teachers would.
I know the number of patches I looked at went way down the second they were dropped from the mailing list.
You can still subscribe to http://drupal.org/project/issues/subscribe any issue you want. Where you can find this link ? I do not know, I read project module source :)
Regards
NK
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
Karoly Negyesi wrote:
You can still subscribe to http://drupal.org/project/issues/subscribe any issue you want. Where you can find this link ? I do not know, I read project module source :)
Yeah - I actually stumbled upon this quite by accident - when, after being inspired by the call for help this morning, I decided to actually look at the issues page (the link is displayed at the top of http://drupal.org/project/issues - BTW) After the release of 4.7 I will have a feature request to have 'Drupal' appear at the top of the subscribe list BEFORE any of the contrib modules. andre ___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/
On Wed, Dec 14, 2005 at 11:36:58AM +0100, Dries Buytaert wrote:
1. When do we release a second beta (or a release candidate)? Given the number of critical/annoying bugs we fixed since beta 1 has been released, I think a second beta might be in order. The sooner, the better?
Yes. Even now.
2. The number of bugs that need fixing grows steadily: http:// drupal.org/project/issues? projects=3060&versions=9728&states=1,8,13,14,2. How do we encourage more people to help fix bugs? How do we help people fix bugs?
chx should pay not for finding bugs, but for providing patches that are accepted, imo. The ideal solution would be, imo: - if you reported a bug and core developer provided a fix - you get a point - if you reported a bug, but someone else provided a patch - you get nothing (or 0.5 point, or something). points go to the person who provided the fix. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
Piotr Krukowiecki wrote:
On Wed, Dec 14, 2005 at 11:36:58AM +0100, Dries Buytaert wrote:
1. When do we release a second beta (or a release candidate)? Given the number of critical/annoying bugs we fixed since beta 1 has been released, I think a second beta might be in order. The sooner, the better?
Yes. Even now.
2. The number of bugs that need fixing grows steadily: http:// drupal.org/project/issues? projects=3060&versions=9728&states=1,8,13,14,2. How do we encourage more people to help fix bugs? How do we help people fix bugs?
chx should pay not for finding bugs, but for providing patches that are accepted, imo. The ideal solution would be, imo: - if you reported a bug and core developer provided a fix - you get a point - if you reported a bug, but someone else provided a patch - you get nothing (or 0.5 point, or something). points go to the person who provided the fix.
I think it is important for both finders and fixers to get rewarded. Not everyone can code. But it is very important to have a wide user base to test the code and the reward for finding bugs encourages a wider base. --Vernon
On Wed, Dec 14, 2005 at 08:18:55AM -0800, Vernon Mauery wrote:
I think it is important for both finders and fixers to get rewarded. Not everyone can code. But it is very important to have a wide user base to test the code and the reward for finding bugs encourages a wider base.
That's why if a core developer provides a patch the 'money points' still go to submitter. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
Dries Buytaert wrote:
2. The number of bugs that need fixing grows steadily: http:// drupal.org/project/issues? projects=3060&versions=9728&states=1,8,13,14,2. How do we encourage more people to help fix bugs? How do we help people fix bugs?
I think there is a need for people dedicated to helping Drupal.org users turn forum topics into bug reports, as well as for people dedicated to reviewing, categorizing and harvesting bug reports. Is the problem description clear? Is the problem easy to reproduce? Is it really critical? If not, help them improve their bug report. Replying with one-liners like 'File a bug report!' or 'RTFM' is not considered helping in this context. The goal is to assist, to be helpful, to pull them on board and hopefully to make them "stick". Similarly, I think there is room for people that review patches like teachers would. In short, we need friendly hosts that help people make their first steps in their Drupal career.
Suggestions and concrete action points are welcome,
How about posting various links (like the one above) both in the mailing lists and in an article on drupal.org front page that direct people of various talents to where they can find a list of things they can do? Some examples: * A link to a list of bug reports that need to be verified. People who can install Drupal can do so and test the problem and report back that it exists or does not exist, saving the programmers who will would have to fix it much time. * A link to a list of bug reports which need to be edited for clear bug descriptions can be used by people who do not feel skilled enough to find the problem, fix it and create a patch, but yet who have enough programming and English-language skills that they can help clarify the problem for the programmers who can find and fix it, thus saving the latter group time and effort. Might be hard to do this, since there isn't an Issue status that corresponds directly to it. In general, give the things that need doing more visibility, and group them by the kinds of skills or actions needed to do them. ..chrisxj
participants (17)
-
andre -
Bertrand Mansion -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
Dries Buytaert -
Gabor Hojtsy -
James Walker -
Karoly Negyesi -
Moshe Weitzman -
piotr＠mallorn.ii.uj.edu.pl -
Richard Archer -
Robert Douglass -
Robin Monks -
Syscrusher -
Vernon Mauery