The goal of this suite of pages is to gather the collective wisdom of Debian developers on new release methodologies for Debian, with an aim toward reversing the current trend of it taking longer and longer for us to make a release.

This set of pages is being developed because while plenty of people have made various suggestions on debian-devel, this has only resulted in threads with hundreds of messages, with debate being more rational in some places than others.

Feel free to add new pages, or add new arguments pro or con to a page, but do respect the opinions of others and bear in mind that the idea is to arrive at a set of well specified proposals for how Debian can release, and not to promote your idea over all others. If your opinion does not represent the consensus of a pro or con for a release method, add it as a comment with your name on it.

Looks like it's time for action! Somebody (maybe the Debian project leader) should pick up the hot potato and compile a list of the proposals which are going to be adopted. Flame wars ensue. Then Debian emerges renewed, as a phoenix from the ashes.


Proposal to do what we used to do:

Proposals for releasing less:

Proposals for splitting up the release:

Proposals for introducing multiple release teams:

Proposals to do more of what we have been doing:

Proposals to improve maintenance of packages:

Proposals for making additional kinds of releases of the full archive:

Besides a new release process, it is also very interesting to figure out why the current process scales so badly. What are the obstacles?

This is an evolving document -- refer to RecentChanges to find newly updated pages.

And while we are at it here is a list of solutions what to do with the ideas and proposals above:

- Christain (Debian user)

-- Gene (Debian User)

-- Phil (Debian user and sysadmin)

-- BillAllombert

-- RegisBoudin (NM)