[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of CUT discussions

Raphael Hertzog, 2010-09-27 10:16:50 +0200 :


>> > Again it's unrelated to the existence of rolling, the problem is
>> > inactive maintainer not taking care of their packages and those are
>> > not the same that would actively push their packages to rolling.
>> What do you base this on? It does not at all seem clear to me that
>> rolling would not introduce maintainers who only care about rolling.
> Nobody can predict the future... but my take is that the people who
> only care about rolling would be the people who do not care of testing
> right now already. Those who care about testing would continue to do
> it.

Without any hint as to how you came to that conclusion, this assertion
can't be considered more than a gut feeling.


> A big part of CUT is also changing our communication, both internal and
> external:
> - internal to say to all contributors that testing/rolling is meant to be
>   always usable so you must be careful in everything you upload to sid, no
>   matter whether we're far from release or not and RC bugs are always
>   important to fix, and you must care about migration to testing/rolling
>   because many users will want the latest version in that distribution

  This is not a change in communication, it's a change in policy, and a
huge one too.  Right after a release has always been a time for
experimenting and introducing intrusive changes to unstable.  Telling
maintainers they now need to refrain from these changes is not something
that can be decided lightly.  Especially since imposing extra
restrictions on the work one does on Debian is going to be one more
reason for people not to care about Debian.  We're supposed to make
working on Debian *easier*, not add extra barriers.

> - external to say to users that testing/rolling can be safely used and
>   is supported by the Debian project at large

  Based on the previous remark, that would be a lie.  I for one wouldn't
like to be seen to support a move that prevents me from introducing
large changes from time to time.

> I don't know when rolling would be introduced, and I don't know when
> squeeze will be released. If we start rolling during this freeze, we
> will probably only do testing + hand-picked updates to make it more
> usable (i.e. no automatic britney run from unstable to rolling).

  Who's this “we”?  That's an honest question: so far I haven't seen
much support from the release managers, so I wonder who's going to do
the work of creating the new suite, defining its package migration
policy and implementing that into the appropriate code, or doing the
actual migration by hand in the initial phase.  That's important because
from it will come the necessary buy-in from developers — or not.  If
you, Raphaël, start providing new Release/Packages/Sources that you
compute from the ones in sid or testing, that's all fine and dandy, and
we get a rolling thing.  But it's not official, and it's not supported,
and it's not “safely used”.  If the release team does it (possibly with
you as part of it), with sufficient buy-in from the developers, then we
have something worth something.

Roland Mas

When you have a hammer in your hand, most things look like a nail.

Reply to: