Re: On cadence and collaboration
Hi, Mark, I'm glad you took towards this list the effort of this message:
On Wednesday 05 August 2009 11:21:38 Mark Shuttleworth wrote:
> Hi folks
>
> I've stayed quiet in this discussion, though several folks have invoked
> my name and ascribed motivations to me that were a little upsetting. I'm
> not responding to that here, instead I'd like to focus on what we can
> achieve together, and how we can lead a very significant improvement in
> the health of the whole free software ecosystem.
>
> Apologies in advance if this mail is lengthy and not particularly witty!
The issue at hand it quite witty too, so I wouldn't take you for guilty (Wow!
now I re-read my own message, it seems a perfect example on what NOT to do on
the executive/project sponsor level -I hope, while I can't expect, you'll
show the patient to read this to the end).
> Imagine you are the leader of a key upstream component. You care about
> your users, you want them to appreciate and love the software you write.
> But you also know that most users won't get the code from you
From my experience that's not usually the case. As already stated, it's
more "you are not using last week's version, go figure for yourself". I
already told my opinion (on a more "hatred" and witty way) here
http://slashdot.org/comments.pl?sid=1318967&cid=28922369 so I won't repeat
myself.
> I hear this story all the time from upstreams. "We'd like to help
> distributions, but WHICH distribution should we pick?" That's a very
> difficult proposition for upstreams. They want to help, but they can't.
> And they shouldn't have to pick favorites.
The main point of my above URL is that basically most upstream projects do not
plan in advance for long term maintenance (neither regarding their own
code -that's basically why Debian is forced to backport instead of using the
bugfixing branches from upstreamers) nor regarding their environment (while I
can understand why they do it, it's still no good practice, maintenance-wise,
using the bleeding-edge code from toolkits, libraries, etc. they depend
upon).
> Adopting a broad pattern of cadence and collaboration between many
> distributions won't be a silver bullet for ALL of those problems, but it
> will go a very long way to simplifying the life of both upstreams and
> distribution maintainers. If upstream knows, for example, that MANY
> distributions will be shipping a particular version of their code and
> supporting it for several years (in fact, if they can sit down with
> those distributions and make suggestions as to which version would be
> best!) then they are more likely to be able to justify doing point
> releases with security fixes for that version.
I think your point is quite a sensible one and shows why you have been a
successful entrepeneur (it shows "soft" abilities towards making things
happening) but still I don't think that's something distributions need to be
strongly looking after.
If distributions A, B, C take version X, Y, Z from the upstream project "Foo"
is mainly because such project doesn't provide clear notions on why X should
have to be preferred over Y or Z. On the upstream projects that already do
so, distributions do already take the published version that better fits
their mood and intentions.
For instance, disregarding end user misinterpretations, KDE is quite good and
consistent -while not perfect, about their versioning policy and as a result
of this, Debian decided not to rush for KDE 4 on lenny but still stay on the
rock-solid KDE 3.5 while other, more edge-adicted distributions (like, say,
Fedora) would start distributing KDE 4 and since the upstreamer properly does
its homework it's all well and good.
So, resuming: it's good for distributions that share some kind of "spirit" to
somehow mildly try to converge on versions as a way to combine efforts
and "show the path" to upstreamers while certainly it's still upstreamer's
right and responsibility to do things properly -or not.
> We're already seeing a growing trend towards cadence in free software,
I don't think it's a free software property but that it's the proper way to go
for these kinds of project (aided with proper dependency cascading and
branching).
The "problem" here is that the proper cadence for each project and even for a
single project on different times it's their own so either the upstreamer
does its homework the proper way or you won't be able to find the minimum
common multiple you need to get stable and maintained versions for the
thousands of packages that make up a distribution in a hundred year period (I
speculated once on a "best practices for a project from distributions point
of view" and the ability to declare some software projects as "blessed" and
so preferred for a given task and managed on different, more efficient
ways... but I'm disgressing) so, again, go with your "soft" abilities but
don't worry about it too much (it's not on your hand, anyway).
> OK, so that's the theory. How do we get there? How do we get many
> distributions to sit down and explore the opportunities to agree on
> common base versions for major releases?
Easy: one at a time (and you already opened the "can of worms": probably a
good thing).
> Well, the first thing is to agree on the idea of a predictable cadence.
Well, I can't be against this since that has been my opinion on what Debian
should do for ages (provided some related problems regarding dependency
cascading and branching are properly assesed).
> Although the big threads on this list are a little heartbreaking for me
> to watch, I'm glad that there hasn't been a lot of upset at the idea of
> a cadence in Debian so much as *which* cadence. We can solve the latter,
> we couldn't solve the former. So I'm happy at least at that :-)
Well, I think the two years cycle has shown as a doable and acceptable
consensus and it's probably perfect if it allows for some exceptions (like
hardware compatibility and some volatile and/or end of dependency lines
software, more or less what is currently managed by means of volatile and
backports). The difficult point is not that but deciding if squeeze should
be the first one or it would be better for the Debian's health to wait for
squeeze+1 (note that while Debian Stable has a reputation for being rock
solid, it's dismayingly too easy to break this confidence on just one
shot -openssl anyone?).
>
> So, practically, we would be in a good position to collaborate.
>
> Psychologically, I don't know so much.
> Have you ever noticed how family disputes can be the most bitter?
While problably you are on spot with your analogy I don't think it really adds
to the question at hand but a bit of poetry (not a bad thing, still).
Disregarding all bitterness and harsh positions, Ubuntu is still more or less
in the same position regarding Debian as it is Debian with regards upstream
projects: Ubuntu can help to show the path, it can even put hands on it but
it's still Debian's right and responsibility to do things its way; if others
(like Ubuntu, but let's not forget other, even company-backed, efforts like
Xandros or Mepis) find it useful for the own purpouses, good to know; if it
fits so good that they commit efforts (money, hardware, developers...) even
better, but Debian is Debian and Ubuntu|Xandros|Mepis... are different
projects and on their own. I don't mean with this some kind of "superiority"
on Debian that allows it to put its nose over the others, but that that's
certain for these class of relationships and it's the healthy long-run way to
go.
> How do I think it could work in practice?
Now: here is where the real meat starts
[here some quite good selling speech that IMHO doesn't add so much but warming
the audience for the next part]
And now...
> As I've said elsewhere, Ubuntu would be happy to reach a compromise if
> needed to work with Debian and others. I think there's agreement on a
> two year cadence, and if needed we can change one of our cycles to help
> bring multiple distributions into line. Alternatively, with Debian
> specifically, we can contribute resources to help Debian meet a stretch
> (or squeeze ;-)) goal.
Hear, hear!!! Since I thought from the beginning -and I think many with me,
and that's probably the basis of the harsh opinion about Ubuntu of some
individuals, that the "proper" way for Ubuntu should have been commiting the
majority of hours directly on Debian instead of on Ubuntu (and I think that
in the long run it's the best option for Canonical anyway), I can't think bad
on this except, maybe, on the way you expect to put this in practice (which I
foresee you plan on doing it through NMU patches instead of looking for ways
to directly help those maintainers with problems/higher workloads).
Not that I think you are "guilty" or something... again, I know you feel in a
hurry (you run a company after all, and that costs money) and that when
Ubuntu started (and even now) Debian has the "terrible defect" for a company
that there's almost no way to build up on its brand recognition but you had
to invent your own from zero.
> From my perspective, committing Canonical
> employees to help Debian freeze in December, or stretching our one cycle
> to get us both onto a two year cadence, are roughly the same. It would
> be unreasonable to expect us to do BOTH of those, but I'm happy to work
> one either basis. Compromise requires some give from both parties, though.
Good seller speech. But don't forget that compromise require for both parties
wanting to reach such a compromise which probably is still not a settled
issue (certainly -IMHO at least, the merits of Debian going for time-based
releases holds by itself; matching those releases with anybody else's I see
how it can benefit Ubuntu but still it's not clear how/if benefits
Debian -real benefits, not theoretical or in a century might-bes) so... again
in my opinion, it will have to be Canonical the one that puts more wood in
the fire at least this time (and it will help to regain confidence for those
Ubuntu haters or, at least, letting them without credible arguments).
But... there's a third path I didn't see expressly stated: if (as it seems) a
freeze in dec 2009 is too in a hurry for the Debian folks, maybe it can be
done in two steps: freeze in feb/march 2010, publish about summer 2010 and
then freeze squeeze+1 on december 2011 (that shouldn't have to be a problem
if known so in advance) in order to go for the two year cycle from then on.
I don't know if that means for Ubuntu to replan its calendar but I know that
Canonical will still have to commit some resources (or at least counting for
some form of resource buffering 'just-in-case') if it wants to insure those
goals.
Of course, for all I know from you (which, I must admit, is not that much) I
bet you'll prefer the december-2009 sprint as your first choice, if only for
the better "time to market" and the confidence it builds up seeing real
things happening ASAP.
> But most importantly, this whole thing will have it's best and biggest
> impact if it goes beyond Ubuntu and Debian.
Certainly yes. But at this given moment, it's still the "milkmaid's tale" (I
think in English you use the expresion “to count your chickens before they
have hatched”), so I'll won't go there now.
> Third, I think we need to call on the people who are not fundamentally
> prejudiced to speak out.
Probably I not only talked but already talked a bit too much, so I'll stop
here.
Reply to: