Hi all,
As an attempt to get 5.3.1 release sooner rather than later, I would
like to give a hand to Johannes (who is MIA ;), to get the patches
merged in 5.3.1 in a controllable manner (from a QA point of view) and
as soon as possible. Many of you certainly contacted Johannes in one
way or another to ask him to merge a patch. That's a good thing except
for one part, we have no trace of these requests :)
That's why I would like to get a list of these requests here:
http://wiki.php.net/todo/php531
Jani may work on something so we can use our lovely new bug tracker(s)
to track these merge requests, but that's not going to be ready
tomorrow.
That should help us to keep an eye on the todos for 5.3.1 or commit
the approved patches early. Having them early in the repo will help to
figure out issues before the release day, hopefully.
Thanks for your understanding,
Cheers,
Pierre
Hi,
As an attempt to get 5.3.1 release sooner rather than later, I would
like to give a hand to Johannes (who is MIA ;), to get the patches
good thing :-)
merged in 5.3.1 in a controllable manner (from a QA point of view) and
as soon as possible. Many of you certainly contacted Johannes in one
way or another to ask him to merge a patch. That's a good thing except
for one part, we have no trace of these requests :)That's why I would like to get a list of these requests here:
http://wiki.php.net/todo/php531
What I actually - while doing quite lazy computer-less vacation - tried
to find is a nice tool to
a) visualize commits that have been merged (most tools do this the other
way round only ("this commit is a merge coming from there") and
b) comment on commits that they should be reviewed deeper/should
be/won't be merged
The best I found is a stupid spreadsheet and random (custom) svn
properties and some scripting, but that's some pain, too.
As I think without such a tool it ends in a mess, anybody knows such a
tool which works on unix or linux systems?
some background: Initially I thought about doing this strictly
chronically but this won't work for fixes which should be merged but
aren't 100% complete, yet and similar cases.
Thanks,
johannes
hi Johannes,
2009/9/29 Johannes Schlüter johannes@schlueters.de:
What I actually - while doing quite lazy computer-less vacation - tried
to find is a nice tool to
a) visualize commits that have been merged (most tools do this the other
way round only ("this commit is a merge coming from there") and
b) comment on commits that they should be reviewed deeper/should
be/won't be mergedThe best I found is a stupid spreadsheet and random (custom) svn
properties and some scripting, but that's some pain, too.
Same here but using the wiki and the bugs tracker and without custom
svn properties :)
I would suggest to go ahead with wiki+tracker for 5.3.1 or other
releases until we have better solutions. By the way, the new bug
tracker will have a new status, to be merged to a given
release/branch. Don't ask when it will be ready :)
Cheers,
Pierre
Greetings,
A question, using an example from today for PHP 5.3.1:
RC: 5.3.1RC1 (via svn co tags/php_5_3_1RC1 or qa.php.net)
RC-dev: 5.3.1RC2-dev (via svn co branches/PHP_5_3_1)
Snap: 5.3.2-dev (via svn co branches/PHP_5_3, or snaps.php.net)
While updating qaweb to allow failed 5.3.2-dev make tests, I now
realize it's not the same as 5.3.1RC2-dev so this presents a problem.
People who report bugs about an RC are sometimes told to try a
snapshot (which we no longer have in this case) and besides, this may
lead to confusion. Please explain how this will work.
Regards,
Philip