Re: Summary of CUT discussions
Raphael Hertzog, 2010-09-27 14:21:12 +0200 :
> Hi,
>
> On Mon, 27 Sep 2010, Roland Mas wrote:
>> >> 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.
>
> I agree, but the same holds for Luk's assertion that the introduction of
> rolling will hurt the process of creating a stable release.
Yep. However, he's not the one asking us to change our ways, so I'd say
the burden of proof (or at least of providing a reasoned position) is on
your side.
>> > - 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.
>
> On a package-per-package basis, I don't think that anything changes. You
> can do intrusive changes and have the package migrate only once you're
> happy with your changes.
>
> On a large scale, there's no change either, all migrations have to be
> coordinated already and breaking sid at your will has not been an option
> for quite some time.
So there's no change on any scale. What's the point again?
> Really, I think the shift is in the communication, not on the practice.
> It's just that we tell us officially that we have users of testing/rolling
> and we wish to give them a pleasant experience.
If we don't change the practice, then we can't suddenly tell users of
testing that we officially support them. Because we currently don't.
At least for some packages, it's hard enough ensuring a more-or-less
pleasant experience in a stable release; trying to provide it on a
moving target is *much* more work, especially if one must support
upgrades from any version younger than X months (as has been
suggested). This is not something that I can currently support, and
it shouldn't be something that “we” can claim to support because that
would be a lie. And if, as a maintainer, I'm told by whatever
powers-that-be that I need to care for this use case from now on, I'm
not likely to take that with a smile.
>> 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.
>
> Right now as far as rolling goes, there's me and Lucas
> Nussbaum. Others have expressed interest in it too, including Stefano
> Zacchiroli and Asheesh Laroia. For the snapshot side, so far Anthony
> Towns and Joey Hess have been the most active in drafting the
> implementation plan.
Thanks.
[...]
> As far as buy-in from developers goes, yes it's needed in general. But
> we do already have testing that is supposed to be in relatively good
> state at any time and nobody has complained about this principle as
> far as I know. So I'm not convinced we need anything else to be able
> to advertise rolling as a testing-like distribution for end-users.
Testing is in a relatively good shape because there's a set of people
coordinating migrations and a known set of guidelines that people can
agree with, mostly with the rationale that we're all working on
preparing the next stable release and testing is the current tool for
that goal.
> What are your suggestions to ensure we have enough buy-in?
The first one that comes to my mind: don't impose unreasonable amounts
of extra work on the maintainers. It's a bit like having backports
officially supported: it's fine if it's optional and I can continue to
care only about stable and unstable *as a staging area for the next
stable release*. If I also need to care about keeping backports current
and upgradable, or the same with CUT, then I simply don't have the
manpower. So either the requirements are dropped (which seems
incompatible with what I've understood of CUT so far), or CUT will only
have a subset of the packages (those whose maintainers agree to the
extra workload), or there's no point in calling CUT supported since it's
clearly not.
Roland.
--
Roland Mas
Why did the tachyon cross the road?
Because it was on the other side.
Reply to: