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
Attachment:
signature.asc
Description: Digital signature