Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46324
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.44 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=S5NAvY7pIbwQhwqWodknIekPr57wy/lOFr9FTIJpSPXp6fjh+jzl56IjgJVjmrXWJO
         J7r425OK3LYBwBtL6Hs3Dd1nP12fE6PNtkBK+FpX6/EMEHR2MzeEKnirZbSFHiFDARkf
         f71U8RDBGqx2wytRV/zaHvwzbnJHcCXDMY3dc=
MIME-Version: 1.0
In-Reply-To: <840804B4-91AF-47AE-895B-29030EF4DC5F@prohost.org>
References: <1260193069.1383.33.camel@guybrush>
	 <306DF528-C204-4B9E-8285-27D9FFDE11E5@prohost.org>
	 <fe05d1540912070619m23245bdcq832b7202a88c46db@mail.gmail.com>
	 <4478B8CF-9446-472E-BC40-C0B18EBFA1B8@prohost.org>
	 <fe05d1540912070627l23ba5849kb4dbbeebd4a33806@mail.gmail.com>
	 <CC15A75A-1F77-44BA-93B7-F597CA512F0F@prohost.org>
	 <fe05d1540912070642r6ff2cdd9j9e1e21732ebe5e7@mail.gmail.com>
	 <FDBA12BD-2E89-410C-A345-B2F607B0DDB9@prohost.org>
	 <fe05d1540912070655kac6c9f4jc97bb6f9cca7a92@mail.gmail.com>
	 <840804B4-91AF-47AE-895B-29030EF4DC5F@prohost.org>
Date: Mon, 7 Dec 2009 16:08:10 +0100
Message-ID: <fe05d1540912070708i22035ba5k3a8bbf4a9890aedb@mail.gmail.com>
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Towards 5.3.2
From: pierre.php@gmail.com (Pierre Joye)

2009/12/7 Ilia Alshanetsky <ilia@prohost.org>:
> Pierre,
>
> It has everything to do with the separate branch. Our current approach, (=
as flawed as it maybe) ensures patches are not missed, since there is no se=
parate branch, so patches go into the release tree. With the new approach i=
f something is not merged it is not part of the release. This also makes it=
 confusing for the users, since the dev fixing the bug indicates on the bug=
 tracker the issue was resolved, and will be part of the next release. And =
then the next release comes out and the bug/issue is still there...

Ok, so we are running in circle.

We agreed on that:
- we need to add a field to explain why a patch was not merged
- a real bug tracker
  - with roadmap
  - allow to set a bug as part of a given release roadmap, like when a
patch is commited to the dev branches, it can be set to "5.3.2" so the
RM can appove merge it
  - be sure that the merge commits are shown in the bug reports as well

However, given that:
- we did NOT miss any patches in 5.3.1
- the process was open, mails have been sent to the list, etc.
- the deadlines were respected, 1st time in 5.3 releases history

I do not understand why you keep saying that it was a major mistake to
do it this way.

I can understand that the chaotic way fits more to your ideas about
how things should work however it totally fails to actually get 3rd
parties involved more deeply in our developments (be QA or to
integrate latest releases to their products, like most unix distros).

What I suggest is to do it again the same way for 5.3.2, I will
improve the tools to make it more transparent and full fills your
requests (except the bug trackes, which is another major issue that we
will have to address very soon as well). Then we can have this
discussion again. The reason is that both Johannes and I were happy
(not 100% but more than 50% :) with it and it allows us to sleep
better during the release phases.

Cheers,
--=20
Pierre

http://blog.thepimp.net | http://www.libgd.org