4.7 status: Call for patch reviews
Hi there! While it is important that we get Drupal 5 out soon, let's not forget that we have a current stable release 4.7. This release has about three pages of patches that either need review or work: http://drupal.org/project/issues?projects=3060&versions=94735%2C94733%2C9473... I'd appreciate help getting this queue reduced. I intent to do a Drupal 4.7.5 maintenance release before the end of the year. There are also nine pages of bug reports that should be sifted through: http://drupal.org/project/issues?projects=3060&versions=94735%2C94733%2C9473... Cheers, Gerhard 4.7 maintainer
Gerhard Killesreiter wrote:
Hi there!
While it is important that we get Drupal 5 out soon, let's not forget that we have a current stable release 4.7. This release has about three pages of patches that either need review or work:
http://drupal.org/project/issues?projects=3060&versions=94735%2C94733%2C9473...
I'd appreciate help getting this queue reduced. I intent to do a Drupal 4.7.5 maintenance release before the end of the year.
Let me explain how I'd like the reviews to be done. 0) try to figure out if the report makes sense at all. If not: close or "wont't fix". 1) try to find out if the issue also applies to HEAD 1a) if it does, move it there (I am not sure whether it needs to by x.y.z, 5-dev, or 6-dev..., IMO there are two choices too many). 1b) if it doesn't say so on the issue. 4) indicate whether the patch solves the issue, re-roll if it doesn't apply anymore.
There are also nine pages of bug reports that should be sifted through:
For bugs: 4) roll patch that fixes issue. :p Cheers, Gerhard
On Nov 14, 2006, at 3:17 AM, Gerhard Killesreiter wrote:
1a) if it does, move it there (I am not sure whether it needs to by x.y.z, 5-dev, or 6-dev..., IMO there are two choices too many).
mea culpa. to clarify: - never classify anything to the x.y.z version. only move things out of x.y.z (so named to drive how how silly and useless this classification system was). see my other email re "Confusion by too many issue queues" for more on this. - anything that is relevant for 5.x (e.g. current HEAD) goes in 5.x- dev (should be self-evident) - anything that is a feature request or too big of a change for 5.0 should be bumped to the 6.x-dev queue (should also be self-evident). thanks, -derek
0) try to figure out if the report makes sense at all. If not: close or "wont't fix". 1) try to find out if the issue also applies to HEAD 1a) if it does, move it there (I am not sure whether it needs to by x.y.z, 5-dev, or 6-dev..., IMO there are two choices too many). 1b) if it doesn't say so on the issue. 4) indicate whether the patch solves the issue, re-roll if it doesn't apply anymore.
There are also nine pages of bug reports that should be sifted through:
For bugs:
4) roll patch that fixes issue. :p
I would like to see a "port" category added to the project module.. alongside bug, task, feature etc. I believe this will make it easier to ensure that fixes are backported/checked promptly and correctly.
On Nov 14, 2006, at 6:18 AM, Karthik wrote:
I would like to see a "port" category added to the project module.. alongside bug, task, feature etc.
good idea. please file an issue (and it's project_issue.module to be precise). ;) thanks, -derek p.s. this should all be made site-specific with an admin UI, instead of having these choices hard-coded into the code, but that's a separate issue.
On 14/11/06, Derek Wright <drupal@dwwright.net> wrote:
On Nov 14, 2006, at 6:18 AM, Karthik wrote:
I would like to see a "port" category added to the project module.. alongside bug, task, feature etc.
good idea. please file an issue (and it's project_issue.module to be precise). ;)
Done: http://drupal.org/node/97571 Thanks. -K
participants (3)
-
Derek Wright -
Gerhard Killesreiter -
Karthik