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

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 

> 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 

> 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 

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 

> 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 

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 

Reply to: