On Thu, Apr 28, 2011 at 05:34:50PM +0200, Mehdi Dogguy wrote: > > See > > http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/ > > for a more detailed answer and related suggestions to limit this problem. > > I'm still reading and thinking… so, don't have an answer yet. But, it > you'd like me to read your ideas, you're going to put some efforts and > post them here, instead of pointing me to your blog. really.
AOL. I do appreciate that Raphael is putting efforts in advertising this discussion using his blog, but that should not come with drawbacks such as forcing people to follow it or getting in the way of those who might be offline while reading mailing list threads. You can find below a text dump of Raphael's blog post mentioned above, for reference/quoting/whatever. Cheers. -- snip ---------------------------------------------------------------- [ from http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/ ] No freeze of Debian’s development, what does it entail? April 28, 2011 By Raphaël Hertzog 15 Comments The main feature of rolling is that it would never freeze. This is not without consequences. Possible consequences It can divert developers from working on the release No freeze means developers are free to continue their work as usual in unstable. Will it be more difficult to release because some people will spend their time working on a new upstream version instead of fixing RC bugs in the version that is frozen? Would we lose the work of the people who do lots of NMU to help with the release? It makes it more difficult to cherry-pick updates from unstable No freeze also means that unstable is going to diverge sooner from testing and it will be more difficult to cherry-pick updates from unstable into testing. And the release team likes to cherry-pick updates that have been tested in unstable because updates that comes through testing-proposed-updates have often not been tested and need thus a more careful review. Frozen earth My responses to the objections Those are the two major objections that we’ll have to respond to. Let’s try to analyze them a bit more. It’s not testing vs rolling On the first objection I would like to respond that we must not put “testing” and “rolling/unstable” in opposition. The fact that a contributor can’t do its work as usual in unstable does not mean that he will instead choose to work on fixing RC bugs in testing. Probably that some do, but in my experience we simply spend our time differently, either working more on non-Debian stuff or doing mostly hidden work that is then released in big batches at the start of the next cycle (which tends to create problems of its own). I would also like to argue that by giving more exposure to rolling and encouraging developers to properly support their packages in rolling, it probably means that the overall state of rolling should become gradually better compared to what we’re currently used to with testing. The objection that rolling would divert resources from getting testing in a releasable shape is difficult to prove and/or disprove. The best way to have some objective data would be to setup a questionnaire and to ask all maintainers. Any volunteer for that? Unstable as a test-bed for RC bugfixes? It’s true that unstable will quickly diverge from testing and that it will be more difficult to cherry-pick updates from unstable into testing. This cannot be refuted, it’s a downside given the current workflow of the release team. But I wonder if the importance of this workflow is not overdone. The reason why they like to cherry-pick from unstable is because it gives them some confidence that the update has not caused other regressions and ensures that testing is improving. But if they’re considering to cherry-pick an update, it’s because the current package in testing is plagued by an RC bug. Supposing that the updated package has introduced a regression, is it really better to keep the current RC bug compared to trading it for a new regression? It sure depends on the precise bugs involved so that’s why they prefer to know up-front about the regression instead of making a blind bet. Given this, I think we should use testing-proposed-updates (tpu) as a test-bed for RC bug fixes. We should ask beta-testers to activate this repository and to file RC bugs for any regression. And instead of requiring a full review by a release manager for all uploads to testing-proposed-updates, uploads should be auto-accepted provided that they do not change the upstream version and that they do not add/remove binary packages. Other uploads would still need manual approval by the release managers. On top of this, we can also add an infrastructure to encourage peer-reviews of t-p-u uploads so that reviews become more opportunistic instead of systematic. Positive reviews would help reduce the aging required in t-p-u before being accepted into testing. This changes the balance by giving a bit more freedom to maintainers but still keeps the safety net that release managers need to have. It should also reduce the overall amount of work that the release team has to do. Comments welcome Do you see other important objections beside the two that I mentioned? Do you have other ideas to overcome those objections? What do you think of my responses? Does your experience infirm or confirm my point of view? -- snap ---------------------------------------------------------------- -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
signature.asc
Description: Digital signature
