Re: dpkg development cycle
Frank Lichtenheld <djpig@debian.org> writes:
> On Thu, Jan 03, 2008 at 05:05:24PM +0100, Raphael Hertzog wrote:
>> Thus I'm wondering if we shouldn't follow the linux development model.
>> Have a cycle of say one month, merge stuff aggressively during 10 days,
>> make an upload to experimental and run the new dpkg on our own computers
>> during 20 days more and then upload to unstable (once bugs have been
>> ironed out).
>>
>> In parallel, we should have the liberty of regularly uploading bugfixes
>> to unstable (with a version like 1.14.14.{1,2,3}) ... it would only
>> contain cherry-picked bugfixes from the master branch.
>
> I would support this proposal.
>
> There are two possible options for the workings of the "stable" branch though
> I want to point out:
> 1) As you described commit everything to "master" and cherry pick the
> changes to "stable" if wanted. (backports)
> 2) Try to decide where to commit beforehand and commit small changes
> directly to "stable" and then merge that to "master". (forwardports)
>
> The latter generates more merge commits but less "duplicated" commits.
> An example project that uses this model is git itself.
Yes. And it does work much better. We 1 on parted and we're planning
to move to 2 after 1.9 gets released since it makes our merging,
releasing and changelog much clearer
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."
Reply to: