Re: dpkg development cycle
Hi,
On Thu, 2008-01-03 at 17:05:24 +0100, Raphael Hertzog wrote:
> dpkg has been in flux lately because we have quite some new development
> and it's difficult to stabilize the codebase when other developments are
> merged at the same time. And when stuff doesn't get merged, it's easy to
> loose motivation to work on dpkg... we need some visibility on when
> something is likely to be merged and when we're trying to stabilize stuff.
I'd say this is mostly a matter of roadmapping. I used to use the TODO
and mails for that.
> 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).
I'm not sure the linux development model applies here, we don't have
that much code pending to be merged. Most of that pending stuff is
waiting for review, design decisions, rewrites, etc.
I think one month might be too much, either staging too many changes,
which makes it more difficult to spot regressions, or we are back to
your current comment that stuff does not get merged fast enough (as
we'd have those 20 non-merging days). And the experimental uploads as a
general rule seem like overhead to me, given that most of us are going
to be running the code from HEAD anyway, and some stuff will be
difficult to spot w/o uploads to unstable.
The model we have been using (at least on my head) during last year or
so has been: coding, testing locally, uploading to unstable, waiting
and seeing during few days for regressions, and doing fast uploads to
fix them. After the BTS seemed to have been stabilized start next
cycle.
> 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.
The stable uploads (although that name is confusing with the suite) are
definitely good, and map to the previous model, but in a bit more
formal and optimal way.
I'm not against improving the current model, but I think we probably
should do incremental fixes to it (like the stable uploads), and see
what happens, or what might need fixing/improving.
regards,
guillem
Reply to: