dpkg development cycle
Hi,
On Tue, 01 Jan 2008, Raphael Hertzog wrote:
> My plan is to merge this branch this week-end/early next week so that
> we'll run this code long enough to catch potential problems before the
> next upload. I'm running this version already here but a few more
> users/testers would be good.
>
> BTW, while we're doing important changes that need testing, it might
> also be a good idea to merge the work of Ian Jackson on triggers. And then
> maybe we can have an intermediary experimental upload.
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.
Now I have #458860 that I'd like to get fixed in unstable pretty soon
and at the same time I have this branch with changes that have the
potential to break stuff. :)
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.
What do you think ?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: