Re: On cadence and collaboration

[Pierre Habouzit]

On Wed, Aug 05, 2009 at 10:51:08PM -0500, Peter Samuelson wrote:
> 
> [Pierre Habouzit]
> > It yields a really costly entry point to target "Linux" as a
> > platform, and it's exactly why most Software Vendors target "RHEL"
> > and not "Linux". And that's part of the reason[1] why most of our
> > customers are using RHELs: software vendors only certify their stuff
> > for RHEL, because it's the established reference in the field, and
> > that it costs too much to certify you stuff for yet-another-distro.
> 
> Ahhh, so you're trying to reinvent the LSB.  You could have said so
> earlier, it would've saved some time.

Actually not, I'm just explaining why I don't think that the Linux
distributions diversity is "an asset".
-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Julien BLACHE]

"Jesús M. Navarro"  wrote:

Hi,

>> That's exactly my point. We suck at freezing.
>
> The problem is not "we suck at freezing".  Quite on the contrary I think 

I should have written "we suck at operating during the freeze" or
something alike, that was a bit of a bad shorthand :)

> Debian developers, the release team, the debian-installer team... all of them 
> have done a really *amazing* work in the past, and I can say this without 
> being suspected being just "a mere user" myself.

All things considered (size and nature of the project, nature of the
contributions, governance model, ...) I think we're doing amazingly
well. It could be a lot worse, especially given nobody has ever done
that before. We're bigger than any other project, nobody has been
there before us.

> In the early days of Debian, the lesser number of packages and archs made 
> (barely) possible the monolithic freeze.  When people where overhauled (I 
> think I remember it by the slink->potato or maybe potato->woody days) new 
> tools pushed forward the frontier (and due to this package and arch numbers 
> skyrocketeed), then the woody->sarge days again exposed the problem.

Back in the days, frozen was just that and unstable was carrying on
with its life (with a bit less activity, but only a bit). Today,
unstable is just as frozen as testing is during the freeze.

In the end, testing kind of works to prepare a consistent set of
packages that we can freeze at some point, so it's a good development
tool, but it's not a good release tool.

WRT unstable, testing is a step backward.

>> A lot of things need to line up for a release. Debian is very large
>> and the windows of opportunity are few and small.
>
> True.  But that adds more value to the cartesian "divide and conquer" idea 
> for 
> problem approaching.  This, of course, wouldn't be without its own share of 

If you're talking of freezing/releasing different sets of packages
more or less independently etc, this has been discussed to death
already.

> You forget that on a branched dependency path it would be quite difficult for 
> something really nasty reaching testing (for a conceptually similar approach 

It's not that difficult. It does happen, simply because since the
testing introduction (and Ubuntu) we have less users using unstable
and reporting bugs. The direct consequence is that bugs do make it to
testing more than we'd like.

>> Seriously, everybody gets bored and fed up 
>> during a freeze.
>
> Not because of the freeze itself but because it takes so long.  Again, i.e. 

Both, actually.

>> I am of the opinion that no matter how hard you try, you can't *make*
>> a Debian release happen.
>
> I never thought about it that way but I think you marked the bull-eye.  I 
> think to remember something Schopenhauer said once about intuitions.  And 
> then, following Schopenhauer on this, although you cannot "make it happen" 
> you still can make it easier for it to happen.

My point exactly. You can *only* help the process. I understand just
how frustrating that can be for release managers, but it's something
that you need to accept to do this job.

>> There's some point at which the release 
>> starts to happen, a point where a critical mass of DDs is reached, the
>> point where everybody uses the word "release" more than any other
>> word.
>
> All of which have some very real technical grounds and a heavy psycological 

Absolutely.

> nature too.  Just the fact of being seriously comitted to a time-based 
> release instead of current "we aim towards this or that date" that nobody 
> takes really seriously but as a wishful grosstimate would heavily help for 
> the critical DD mass and the "going for the release" attitude to happen.

I think there's been a real push over the last years and a lot more
DDs are focused on getting releases out the door now. We talk about
releasing more than ever, so this cannot escape anyone nowadays.

As for the cadence, the 18/24 months is something that looks like it
can work repeatedly and is generally a good pace for us etc.

So, in a nutshell, it's all there already, though not as formal as
some would like it to be, it seems.

>> > developed (hey, Mr. Canonical, there you have a very interesting case
>> > where your hands and moneys would certainly be more than welcome).
>>
>> Remember dunc-tank?
>
> Yes, but I don't think it as a demonstration that "money can't really help" 
> (or can just really help that much) but as a misguided and mistimed attempt 
> doomed to fail.

Fair enough.

>> What we'd need is some sort of "upstream academy" where we could teach
>> upstream:
[...]
> Yes... It might be worth it some kind of "best practices" manual coupled with 
> some kind of peer-review process for such practices (the equivalent to the 

I think something more interactive and hands on would be best. "RTFM"
never worked that well in this case.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on 

Re: On cadence and collaboration

[Julien BLACHE]

Steve McIntyre  wrote:

Hi,

>>A time-based freeze could mean for some teams that they'll have to
>>stop work basically for months to a year.
>
> Exaggeration, -1.

Excuse me, what? This is exactly what happened for this past freeze,
so you can take that back, kthxbye.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

"Leo \"costela\" Antunes"  wrote:

Hi,

> Using two different versions of software is IMO no boon to security for
> a series of reasons:

Discussing the validity of security policies is not the point of this
thread, so let's leave it at that, please.

> But even if I'm wrong - which I could easily concede - this doesn't
> serve as argument, since you could just as easily use two different
> versions of the same distribution, specially in scenarios where you can
> deploy LTS and STS versions concurrently.

You might need features that are not available in the older distro.

There are a lot of reasons, good and bad, that can be used to either
justify or criticize this kind of setup, but that's really not the
subject here. This was only an example, there are others, nitpicking
on this one (or any other, for that matter) is pointless.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

Peter Samuelson  wrote:

Hi,

> I still don't understand what is supposed to be "new" about the
> time-based freezes.  The Release Team was giving us projected freeze
> dates all through the lenny release.  For example,

Same here. Either things are evolving and the proposal is being
down-moded, or it was badly worded or reported initially.

And I concur with your LSB comment, too.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

Pierre Habouzit  wrote:

Hi,

Quoting out of context and generalizing from there, way to go.

>> In the free software world, the diversity we have today, which is
>> partly due to unaligned releases from the major vendors, is an asset.
>
> Security-wise ? Let's admit that, I don't want to fight on that point,
> even if I think it's not as simple.

It does help, but sure it's not that simple either.

> But speaking from my experience as an employee of a software editor, I
> can tell that the distribution diversity is a huge problem when it comes
> to distributing our work. If your client use a Ubuntu LTS, a RHEL, a
> SuSE or worst for some, some kind of home-brewed monster taken half from
> a RHEL and custom packages (*sigh*) then you have as many builds to do,
> regress-test and so on.  When you target Windows or Solaris or MacosX,

Guess what: this will still be the case even with aligned releases or
whatever. You won't get rid of that unless all the distros collapse
into a single one overnight.

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Peter Samuelson]

[Pierre Habouzit]
> It yields a really costly entry point to target "Linux" as a
> platform, and it's exactly why most Software Vendors target "RHEL"
> and not "Linux". And that's part of the reason[1] why most of our
> customers are using RHELs: software vendors only certify their stuff
> for RHEL, because it's the established reference in the field, and
> that it costs too much to certify you stuff for yet-another-distro.

Ahhh, so you're trying to reinvent the LSB.  You could have said so
earlier, it would've saved some time.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Jesús M. Navarro]

Hi, Julien:

On Wednesday 05 August 2009 22:09:04 Julien BLACHE wrote:
> "Jesús M. Navarro"  wrote:
>

[...]

> >
> > Why?  I really don't see your point unless you mean for the packager
> > under current conditions where no real branches are allowed on Debian
> > (but the
>
> That's exactly my point. We suck at freezing.

The problem is not "we suck at freezing".  Quite on the contrary I think 
Debian developers, the release team, the debian-installer team... all of them 
have done a really *amazing* work in the past, and I can say this without 
being suspected being just "a mere user" myself.

The problem is that there's no non-sucking way to freeze the vast amount of 
packages and archs managed by Debian as a monolithic single entity.

In the early days of Debian, the lesser number of packages and archs made 
(barely) possible the monolithic freeze.  When people where overhauled (I 
think I remember it by the slink->potato or maybe potato->woody days) new 
tools pushed forward the frontier (and due to this package and arch numbers 
skyrocketeed), then the woody->sarge days again exposed the problem.

The "monolithic freeze" is the simplest way both technically and from 
perception but maybe it's time to look for less straigthforward but more 
powerful ways to deal with the engineering challenges a project like Debian 
rises.

> It all boils down to the current testing system being inadapted to our
> needs. But that's something we couldn't really know for sure until we
> had tried it for a couple of releases, and I think we still won't know
> for a release or two because of the new tools that have been put in
> place to handle transitions (and others).

They might help but only on a "diminishing returns" way:  it is the management 
itself (the monolithic freeze concept) the one that is being stretched past 
its natural bounds (where complexity tends to grow exponentially as the 
number of packages/archs -and DDs! grow just linearly).

> A lot of things need to line up for a release. Debian is very large
> and the windows of opportunity are few and small.

True.  But that adds more value to the cartesian "divide and conquer" idea for 
problem approaching.  This, of course, wouldn't be without its own share of 
problems, but they would probably be less weigthening (instead of a release 
being done three years from the last one as is to-date the worse case 
scenario with current methods, you would have a "less than glamorous" but 
decently actualized release on time due to the shiny changes not being in 
time to be on board -but they'll have a new chance on next release).

> Deciding on versions 
> of core packages between distributions could help, but a fixed-date
> freeze probably won't. It could even make things worse, as it could
> make it harder to iron out the issues (like having to convince the
> release team to let a new upstream in to fix something because there's
> really no better way).

You forget that on a branched dependency path it would be quite difficult for 
something really nasty reaching testing (for a conceptually similar approach 
see FreeBSD backports from CURRENT to STABLE; No: CURRENT->STABLE->RELEASE is 
not the same as Unstable->Testing->Stable although it might seem at first 
glance) and, of course, everything (but death) can have its (rare) 
exceptions.

> Seriously, everybody gets bored and fed up 
> during a freeze.

Not because of the freeze itself but because it takes so long.  Again, i.e. 
FreeBSD devels don't feel that pain and they still manage to produce quite 
robust releases.

> I am of the opinion that no matter how hard you try, you can't *make*
> a Debian release happen.

I never thought about it that way but I think you marked the bull-eye.  I 
think to remember something Schopenhauer said once about intuitions.  And 
then, following Schopenhauer on this, although you cannot "make it happen" 
you still can make it easier for it to happen.

> There's some point at which the release 
> starts to happen, a point where a critical mass of DDs is reached, the
> point where everybody uses the word "release" more than any other
> word.

All of which have some very real technical grounds and a heavy psycological 
nature too.  Just the fact of being seriously comitted to a time-based 
release instead of current "we aim towards this or that date" that nobody 
takes really seriously but as a wishful grosstimate would heavily help for 
the critical DD mass and the "going for the release" attitude to happen.

>
> > to push it to a latter date in order to have time for the tools to be
> > developed (hey, Mr. Canonical, there you have a very interesting case
> > where your hands and moneys would certainly be more than welcome).
>
> Remember dunc-tank?

Yes, but I don't think it as a demonstration that "money can't really help" 
(or can just really help that much) but as a misguided and mistimed attempt 
doomed to fail.

> What we'd need is some sort of "upstream academy" where we 

Re: Debian decides to adopt time-based release freezes

[Richard Hecker]

Mark Shuttleworth wrote:

..


Instead of saying "there's a bug that was badly handled, so we should 
never collaborate better on anything", let's look for opportunities to 
make things better. We have a good opportunity to make a profound 
change in the way upstreams and distributions engage. A change that 
will really help the whole free software ecosystem, and many 
distributions beyond Ubuntu and Debian. Isn't it worth exploring that 
idea for its full value?


Mark


Since you used quotation marks, this suggests you are referencing the 
verbatim words of an individual.  I am
curious about this quote.  Was it a Debian Developer who said this?  I 
find it hard to believe a fellow DD would
propose such a shallow view.  Your points in this paragraph should enjoy 
consensus within both the Debian
and Ubuntu spheres of influence.  A healthy ecosystem will benefit both 
of us.


Richard


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Jesús M. Navarro]

Hi, Mark:

On Wednesday 05 August 2009 23:28:19 Mark Shuttleworth wrote:
[...]
> I think most are waiting to see if Debian and Ubuntu can do this. If we
> can, I am very confident we will get a group of other distributions
> participating in the version harmonisation discussions in the first
> round. To win Novell we would have to actually demonstrate the process
> works, I think. And to win Red Hat we would need to demonstrate it works
> with everyone else first. At least, that's my impression from
> conversations to date.

I don't think too many conversations are needed to reach such a conclusion but 
plain common sense:  Red Hat is the big guy in this yard and it's a 
for-profit company (just like Canonical) so, at least in the short run, it 
benefits from their bussiness enemies (like SUSE or Canonical) to stay 
divided and flakey.  Only in the case that their competitors make a deal that 
can put in danger their lidership they'll contemplate going into the fest if 
only to leverage the field.  On the other hand Canonical it's obviously the 
company that benefits the most with such maneouvre (not saying this is a good 
or bad thing 'per se': bussiness are there for the profit and in this 
specific case I'm inclined to think that, properly managed, Canonical's 
benefit is quite aligned with Debian's and even the Linux user comunity as a 
whole one).

On the other hand and being quite cynical, if it would happen the "freeze at a 
time" among Red Hat, SUSE and Canonical, being all of them for profit, this 
would be a very unstable equilibrium since they all would be very pushed into 
cheating to their own advantage (hey! you released one week earlier... yes, 
but you launched your press release two weeks in advance! etc.)


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Cyril Brulebois]

Raphael Geissert  (05/08/2009):
> Like some people said during Debconf: "freezing in December" doesn't
> necessarily mean freezing the first day or even the first week of
> December; the 31 is still December, which means there are 30 days to
> decide many things, if necessary.

Without having to resort to nitpicking on days, was the “freeze” term
define anywhere? My main question would be: will it be possible to e.g.
switch the default compiler right before the freeze and trigger possible
hundreds of serious FTBFS bugs? Or is some incremental freeze still
supposed to happen? (Putting -release in Cc to catch their attention.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Faidon Liambotis]

Steve McIntyre wrote:
> To be fair, I've not been doing a good enough job of talking with the
> project as a whole lately. I *have* been talking to a lot of people
> inside and outside Debian about things in that time, but a combination
> of a very busy day job and a new girlfriend have been keeping me much
> quieter than I was planning for.
If you want to be fair, you should mention that you have a 2IC for
exactly the "too busy in real life" reason.

Regards,
Faidon


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Jesús M. Navarro]

Hi, Jan:

On Wednesday 05 August 2009 21:53:20 Jan Hauke Rahm wrote:
[...]

>
> I'm interested in the reactions of other distributions. Are they likely
> to change their release cycle to fit yours? Or would you be willing to
> change Ubuntu's release dates if SuSE proposed LTS releases to come out
> in odd years or similar?

Remember this is basically a meritocracy and that open sourced software tends 
to grow like a snowball down a hill: the first to do something seen as useful 
on a less than stinky way will "attract" attention and activity around him.  
Even know it's working just that way: why is it Shuttleworth now gossiping 
about time-based releases but because he believes on its value, probably 
based on ideas developed out of the fact of Ubuntu working -and working well, 
at least on his eyes, that way?

That's why I said something in the lines of "don't worry about Red Hat, SUSE, 
whatever..." if you go and do it, you'll show it's possible and if it's 
useful others will "jump" onto your backseat in due time... and if it ends up 
not being so useful/good idea, well... hours and hours wasted on comitees to 
reach consensus won't make it any better anyway.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Jesús M. Navarro]

Hi, Marc:

On Wednesday 05 August 2009 22:24:56 Marc Haber wrote:
> Hi,
>
> On Wed, Aug 05, 2009 at 09:32:36PM +0200, Jesús M. Navarro wrote:
> > In other words: freeze on december the first doesn't mean that if, say,
> > Gnome will publish it's new shiny 1.2 version by december the 15, the
> > last beta should have to be included, but that the december version will
> > ship version 1.1 (or whatever is the previous known to work stable). 
> > It's up to the upstreamer to decide if next time they will publish by
> > november the 15th instead of december the 15th so their latest greatest
> > gets to be shipped.
>
> So we basically force a time-based release schedule upon our upstreams
> when we do time-based freezes? I am not sure whether upstreams are
> going to like this.

Force? No!!!  How in hell could a user (a user of a royalty-free, freely 
distributable software no less) force anything on the provider? It's the 
other way around if any!

*BUT* you give them information, you know information is power, and they can 
do with it whatever they see fit.  They don't need to change their schedule, 
they don't need to care about a distribution at all, but you give them an 
(hopefully) easy to understand and remember schedule *in case* they want to 
take it into account.

On a different message Julien Blache states that "The freeze date for the past 
few releases has always been known in advance and refined as we went" but 
that's only true for Debian users and developers and even then not for any 
Debian user but only those really interested on the march of the 
distribution.

On the other hand, I know Ubuntu produces new versions each six months about 
april/october or OpenBSD more or less the same and I don't even use them.  I 
never went to the Olympic Games and still I know they are every four years 
starting from 00, but I'm Catholic and I don't know the dates of next year's 
Holy Passion but that it will be about mid spring (I put this examples 
because they both are time-tied but while Olympics follow an easy rule, Holy 
Passion follows a convoluted one), see the trend?


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Raphael Geissert]

Anthony Towns wrote:
> On Wed, Aug 05, 2009 at 08:44:29PM +0100, Mark Shuttleworth wrote:
>> The proposal as I understood it was that in December, the key component
>> maintainers / release managers from all interested distributions would
>> discuss, on a public mailing list, their plans for the base versions of
>> those components in their 2010 releases.
> 
> That seems very different to what's usually meant in Debian by "freeze"
> (and "freeze" was the term used in both the debian-announce and
> debian-devel-announce mails). AFAICS, a December agreement of that sort
> would mean a Debian freeze somewhere between January and March.
> 

Like some people said during Debconf: "freezing in December" doesn't
necessarily mean freezing the first day or even the first week of December;
the 31 is still December, which means there are 30 days to decide many
things, if necessary.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Steve McIntyre]

On Wed, Aug 05, 2009 at 08:42:03PM +0200, Julien BLACHE wrote:
>
>I think we'll lose part of the "we release when it's ready" philosophy
>(that our RMs seem to despise so much). Because part of this is to
>freeze when it's ready.

If you don't have an idea of what to target for your release (or when
to target your release), then the release doesn't actually
happen. We've seen that happen in the past. The Etch and Lenny release
cycles worked OK for us and were specifically aimed at 18-24
schedules. Or would you claim that they weren't ready?

Freezing to a schedule will still give us all the control we need in
terms of actually stabilising for release.

>A time-based freeze could mean for some teams that they'll have to
>stop work basically for months to a year.

Exaggeration, -1.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Steve McIntyre]

On Wed, Aug 05, 2009 at 02:07:22PM -0700, Russ Allbery wrote:
>Julien BLACHE  writes:
>> Marc Haber  wrote:
>
>>> [1] and I am actually quite disturbed that Mark gets to talk to the
>>> DPL more often than Debian does
>
>> Bah, journalists get to talk to him even more often, especially the
>> hacks at The Register. I learned quite a few things by reading papers
>> on The Register. Disturbing, indeed.
>
>I suspect, in both cases, that has something to do with who is actively
>seeking him out.

To be fair, I've not been doing a good enough job of talking with the
project as a whole lately. I *have* been talking to a lot of people
inside and outside Debian about things in that time, but a combination
of a very busy day job and a new girlfriend have been keeping me much
quieter than I was planning for.

I've also deliberately been ignoring a lot of the crap on our mailing
lists rather than diving in to feed flames in the arguments. Maybe
some people think that's a bad thing.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Opera in your repos

[Steffen Moeller]

Dear Ilya,

Ilya Shpan'kov wrote:

> Last 7 years I use GNU/Linux and know that, for example, in Russia the
> Opera browser is very popular in GNU/Linux Community. Unfortunately, not
> always I can see this browser in the non-free repos. Well, there is a
> question: whether Opera is included to your distro and if not - how we can
> fix this problem? We are ready for any discussions, technical help or
> agreement, if necessary.

have many thanks for your initiative. As an informal start, you might want 
improve
http://wiki.debian.org/Opera to some degree.

"We" had previous exchanges of thoughts in the past
2001 http://www.mail-archive.com/debian-...@lists.debian.org/msg08128.html
2007 http://www.mail-archive.com/debian-de...@lists.debian.org/msg251312.html

the thread on -devel was rather excellent.

Summarising from what I understood, the major advantage over a deeper 
integration of your
binaries with Debian would be in a leaner product, i.e. an Opera binary that 
dynamically
links to as many Debian packages already in the system (and possibly already in 
memory) as
possible. Debian would then profit from an increased number of libraries that 
your product
is likely to use and an increased scrutiny of its existing packages. And so 
would the
upstream authors of those packages.

For that approach to be successful, you would need to perceive Debian as a 
regular part of
your production environment. A change of the soname of some library would 
require a
renewed compilation of your binaries. This might work, but only with a very 
close coupling
of the binary's uploader with your source code. Consequently, the uploader, a 
Debian
developer, should be part of your team. Since you are apparently based in Oslo, 
I suggest
you to talk back to Petter (https://nm.debian.org/gpg_offer.php) to help with 
some initial
steps towards Debian packaging and guide you and your team towards DD status - 
and/or you
might want to hire him (or another DD somewhere in the world).

A plan B might be to contact Canonical and have that integration process 
outsourced, so
you would end up in Ubuntu directly. As a good netizen I hope you to approach 
the first
route, via Debian to Ubuntu, although it is slightly more painful as a start as 
it seems.
But once that it becomes clear to the other DDs that Opera really cares about 
our
distribution, they (or the vast majority of them) will also tolerate the Opera 
binaries in
non-free.

All the best, hoping for lots of contributions from the other side of the 
Baltic Sea

Steffen





signature.asc
Description: OpenPGP digital signature

Re: Opera in your repos

[Matthew Johnson]

On Wed Aug 05 19:13, Santiago Vila wrote:
> > Last 7 years I use GNU/Linux and know that, for example, in Russia the
> > Opera browser is very popular in GNU/Linux Community. Unfortunately, not
> > always I can see this browser in the non-free repos. Well, there is a
> > question: whether Opera is included to your distro and if not - how we can
> > fix this problem? We are ready for any discussions, technical help or
> > agreement, if necessary.
> 
> As explained by Ana, Debian is about making a free operating system,
> so we usually try to remove software from non-free when we have free
> alternatives, not add more.

That said, I am (I know, disown me now) a big Opera user, I think it's
by far the best browser and it's a shame it's not Free software. I would
be prepared to maintain it in non-free, however Santiago's caveats all
apply. We would need a licence which allowed it to be redistributed by
Debian and used by all of our users. The reference for this is Debian
Policy 2.2.3 and 2.3:

http://www.debian.org/doc/debian-policy/ch-archive.html#s-non-free

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Opera in your repos

[Bernd Zeimetz]

Ilya Shpan'kov wrote:
> Thanks, Santiago!
> 
> I will inform our lawers about your opinion. Really, it have a very big
> sense.
> 
> I can say, that here in Opera we had discussions about being Free
> Software every year. Unfortunately, we have a lot of agreements with
> other companies which use Opera at their devices - by this case we still
> can't to be a real free Software.

It would be *really* amazing if Opera would become free software. The browser is
really awesome, but as it is not open-source software, I rarely use it.

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On syncing freeze dates with other distributions

[Bernd Zeimetz]

Mark Shuttleworth wrote:

> I reached out to RHEL last year to see if they are interested in
> adopting a predictable cycle of releases, and collaborating around them.
> They did not respond to the email. I've heard it said informally that
> they will "never" do that. In fact, I think RHEL could be persuaded to
> join such a movement, but only if we have won over almost everyone else
> first! That's why I've tried to include Novell in the discussion (they
> are more interested, but still not takers to the idea).

Did you give fedora a try? I could imagine they're much more open to such
suggestions.

> Agreeing an approach between Debian and Ubuntu would be a very
> significant first step. I believe we could then bring in many of the
> smaller distributions, followed by Novell, and ultimately Red Hat too.

As long as it is ensured that Ubuntu *AND* Debian profit from it, it would be
good to have. Unfortunately various Ubuntu-related things had imho a pretty bad
influence on Debian (I'm saving the time to repeat them here, there are enough
mails from various people from the last days stating the problems), so it is not
easy to convince me.

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Opera in your repos

[Ilya Shpan'kov]

Thanks, Santiago!

I will inform our lawers about your opinion. Really, it have a very big  
sense.


I can say, that here in Opera we had discussions about being Free Software  
every year. Unfortunately, we have a lot of agreements with other  
companies which use Opera at their devices - by this case we still can't  
to be a real free Software.


But future is constantly changing and who know - maybe we will be Free too  
;)


В письме от Wed, 05 Aug 2009 19:13:55 +0200, Santiago Vila  
 сообщал:



On Wed, 5 Aug 2009, Ilya Shpan'kov wrote:


Hi,

I work in Opera Software - yes, we make a proprietary browser ;)

Last 7 years I use GNU/Linux and know that, for example, in Russia the
Opera browser is very popular in GNU/Linux Community. Unfortunately, not
always I can see this browser in the non-free repos. Well, there is a
question: whether Opera is included to your distro and if not - how we  
can

fix this problem? We are ready for any discussions, technical help or
agreement, if necessary.


As explained by Ana, Debian is about making a free operating system,
so we usually try to remove software from non-free when we have free
alternatives, not add more.

Anyway, I'll give you a more technical answer.

I see at least two problems in putting Opera in non-free:

First one, the End User License Agreement does not say anything about
redistribution. It is allowed at all? Under which conditions? Do those
conditions last forever, or may Opera Software terminate them at their
wish? Bear in mind that there are sites like snapshot.debian.net that
would copy each and every upload of opera from non-free to be archived
forever. If we can't do that it would probably not worth the effort.

The second problem I see is the discrimination against some
users. From the LICENSE text:

 You are entitled to use the Software on all personal computers
 (laptops/desktops). "Use" means loaded in temporary memory or
 permanent storage on the computer.

 You may not use the Software on non-PC products, devices, or embedded
 in any other product, including, but not limited to, mobile devices,
 internet appliances, set top boxes (STB), handhelds, PDAs, phones, web
 pads, tablets, game consoles, TVs, gaming machines, home automation
 systems, or any other consumer electronics devices or
 mobile/cable/satellite/television or closed system based service.

Well, the fact is that Debian aims to run on all those devices too.

Putting opera.deb in non-free would be deceptive to those users, as
most people assume that if something is in non-free, then the software
might be proprietary but at least use is not restricted, which would
not be the case here.

As Debian is about creating a free operating system, we don't have any
system or procedure to force people to accept licenses before dowloading
packages. With current tools, whoever bothers to package Opera for
non-free would probably add a debconf question in the line of "Are you
using an ordinary PC (laptop/desktop) or you are using something else?".

If I had to answer questions like that after installing something, I
am not sure I would be glad of doing so from a Debian server.

Thanks.




--
Best regards,

Ilya Shpan'kov
Community Outreach Manager for Russia
Opera Software ASA

Mobile: +47 46351421
Web-site: http://my.opera.com/IlyaShpankov/
Skype: shpankov


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Aurelien Jarno]

On Wed, Aug 05, 2009 at 07:46:51AM +0100, Mark Shuttleworth wrote:
> When you have two large, complex, passionate organisations there will
> always be plenty of opportunities to find fault with one another. Do you
> not believe that it would be possible to find a long list of cases where
> Debian developers have acted in a way that made collaboration difficult
> or impossible, or could be interpreted as bad faith? Of course it would.
> 

The bug report in question actually reflects the cooperation between
Ubuntu and Debian on (E)GLIBC in general (see [1] for more details). 


> Instead of saying "there's a bug that was badly handled, so we should
> never collaborate better on anything", let's look for opportunities to
> make things better. We have a good opportunity to make a profound change
> in the way upstreams and distributions engage. A change that will really
> help the whole free software ecosystem, and many distributions beyond
> Ubuntu and Debian. Isn't it worth exploring that idea for its full value?

Even if it is not directly visible to the end-user, the libc is 
essential to a GNU/Linux distribution.

Does this mean that Ubuntu will finally put some manpower on helping the
(E)GLIBC development, both on the packaging side and on fixing/reporting
upstream bugs? Currently Debian is doing most of the work.

Aurelien

[1] http://lists.debian.org/debian-project/2009/08/msg00101.html

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Peter Samuelson]

[Julien BLACHE]
> I think we'll lose part of the "we release when it's ready"
> philosophy (that our RMs seem to despise so much). Because part of
> this is to freeze when it's ready.

I still don't understand what is supposed to be "new" about the
time-based freezes.  The Release Team was giving us projected freeze
dates all through the lenny release.  For example,

http://lists.debian.org/debian-devel-announce/2008/02/msg2.html

Of course we weren't able to hit every freeze date ... but so far I
haven't seen any reason to believe that aspect of Debian will change.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Leo "costela" Antunes]

Julien BLACHE wrote:
> That'd break common enterprise setups like having 2 firewalls running
> different distributions. Not sure how you get around that once all the
> distros commonly used/accepted in the enterprise world agree on
> shipping the same version of server software.

Using two different versions of software is IMO no boon to security for
a series of reasons:
- Having a single compromised firewall is enough.
- There's no guarantee the different versions won't be affected by the
same security issues.
- There's more management work to follow the possible vulnerabilities,
which could be seen as making attack surface bigger.
- Not to mention the lack of support, which has already been used as an
argument: since it's unlikely upstream would provide security updates
for two versions the burden would fall on the distro and the timeframe
for exploits gets a bit bigger.

But even if I'm wrong - which I could easily concede - this doesn't
serve as argument, since you could just as easily use two different
versions of the same distribution, specially in scenarios where you can
deploy LTS and STS versions concurrently.
This would ease the management overhead and still keep the theoretical
security gains.


Cheers
-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: On cadence and collaboration

[Pierre Habouzit]

On Wed, Aug 05, 2009 at 09:30:33PM +0200, Julien BLACHE wrote:
> In the free software world, the diversity we have today, which is
> partly due to unaligned releases from the major vendors, is an asset.

Security-wise ? Let's admit that, I don't want to fight on that point,
even if I think it's not as simple.

But speaking from my experience as an employee of a software editor, I
can tell that the distribution diversity is a huge problem when it comes
to distributing our work. If your client use a Ubuntu LTS, a RHEL, a
SuSE or worst for some, some kind of home-brewed monster taken half from
a RHEL and custom packages (*sigh*) then you have as many builds to do,
regress-test and so on.  When you target Windows or Solaris or MacosX,
you usually officially support the last two releases, and that's it (and
please, it's the same for "Linux" distributions, for RH you "have" to
support RH4.x and RH5.x if you want to be relevant).


It yields a really costly entry point to target "Linux" as a platform,
and it's exactly why most Software Vendors target "RHEL" and not
"Linux". And that's part of the reason[1] why most of our customers are
using RHELs: software vendors only certify their stuff for RHEL, because
it's the established reference in the field, and that it costs too much
to certify you stuff for yet-another-distro.


OTOH, the diversity is also good for us, and there isn't two developers
with the same distribution: many Debian sid's, but also lennies, even a
gentoo IIRC, and it has proven a good thing to find awkward bugs in our
software. But if this diversity is good for the development phase (and
can easily achieved using "unstable"-like distributions), it sucks a lot
when it comes to distribution.


Bottom line, I think your vision of the problem is too black&white.


Of course, arguably we shouldn't care about proprietary software. But
let's face it, in the end, people will want to make their Oracle cluster
work, make their funky Telco hardware work with a proprietary stack and
so on.


[1] quality of the support is clearly the other biggest part

-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Mark Shuttleworth]

Jan Hauke Rahm wrote:
> I understand you've been talking to other distributions as well about
> syncing releases (or freezes) in order to ship same versions of major
> system components. Now, much of the discussion here is about the actual
> dates, i.e. the possible freeze in a few month as well as freezing in
> the end of odd years to release in spring of even years. This idea seems
> to fit best to your (ubuntu's) current release cycle and I feel many
> Debian contributors see there your (inacceptable?) influence on Debian.
>
> I'm interested in the reactions of other distributions. Are they likely
> to change their release cycle to fit yours? Or would you be willing to
> change Ubuntu's release dates if SuSE proposed LTS releases to come out
> in odd years or similar?
>   

I think most are waiting to see if Debian and Ubuntu can do this. If we
can, I am very confident we will get a group of other distributions
participating in the version harmonisation discussions in the first
round. To win Novell we would have to actually demonstrate the process
works, I think. And to win Red Hat we would need to demonstrate it works
with everyone else first. At least, that's my impression from
conversations to date.

Mark

Re: On cadence and collaboration

[Mark Shuttleworth]

Noah Meyerhans wrote:
>> I think it's reasonable to believe it would be easier to get [upstream]
>> attention about a version that *many* distributions adopted.
>> 
>
> Additionally, even if upstream isn't willing to provide any help to
> distros shipping what they consider to be a "stale" version, the distros
> are in a better position to help each other if they're shipping similar
> versions.
Yes, I agree very strongly.

Re: On cadence and collaboration

[Mark Shuttleworth]

Marc Haber wrote:
> On Wed, Aug 05, 2009 at 08:44:29PM +0100, Mark Shuttleworth wrote:
>   
>> My expectation is that Debian will want to have more flexibility in how
>> long the release is baked than Ubuntu would normally give itself. My
>> hope is that we can agree on a GNOME and KDE version, and that Debian
>> will thus benefit from all the work Ubuntu does on that and then have a
>> few extra months (as many as deemed necessary) to bake it to Debian's
>> satisfaction.
>> 
>
> And you are willing to allow Ubuntu to release with outdated KDE and
> outdated GNOME, frozen in Dezember, while both upstreams releasing
> again in January? In the past, so I have been told, Ubuntu has let the
> current versions slip into the April release
We only do this with upstreams which have earned credibility in their
release management. Our general policy is that we only accept things
which are already an upstream stable release at our upstream version
freeze milestone (about two months into the six month cycle). We make
exceptions for those upstreams which have a very good track record of
actually delivering on time, every time, and being good about freezing
early themselves (with appropriate policies for translation and UI
freeze, for example). GNOME set the pace on that, KDE is now also
looking good.

The stronger an upstream's reputation, the easier it is to trust them
and plan for a release which they haven't yet delivered when we freeze.

I doubt we would lightly trust an upstream that had not already gone
through that process once or twice.

> , which would not be possible if you were syncing with Debian.
>   
Well, given that Debian will typically take longer to be satisfied with
a release (more architectures, more packages considered RC, different
approach to QA, volunteer team) it may well be possible to agree to
freeze on something which is not yet released in December, but will be
released early enough to give both Ubuntu and Debian confidence that it
can be a shared component.

> Or do you expect that we would let new KDE and new GNOME into a
> distribution frozen two months earlier to accomodate Ubuntu?
>   
No, I wouldn't expect that, it wouldn't make sense or be congruent with
Debian's values.

> If you mean that Debian continues its staged freeze, starting with the
> toolchain in December, followed by other stages and the last stage
> including the desktop environments in february, do you seriously
> expect us to release before October? That would be overly optimistic,
> we're not that fast.
Well, I agree that prior staged freezes haven't been ideal, but I think
the basic idea has merit, especially in collaboration with other
distributions and upstream.

>  And, even if we were that fast, Ubuntu LTS would
> be on the market half a year earlier, giving Ubuntu a strong advantage
> over Debian stable.
>   
We've been in that situation in the past, for example with Ubuntu 6.06
and Debian Etch, and it didn't make much difference.

Mark

Re: On cadence and collaboration

[Russ Allbery]

Julien BLACHE  writes:
> Marc Haber  wrote:

>> [1] and I am actually quite disturbed that Mark gets to talk to the
>> DPL more often than Debian does

> Bah, journalists get to talk to him even more often, especially the
> hacks at The Register. I learned quite a few things by reading papers
> on The Register. Disturbing, indeed.

I suspect, in both cases, that has something to do with who is actively
seeking him out.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

Mark Shuttleworth  wrote:

> Yes, I would have to agree with your point - having more distributions
> on the same base version of something like Apache or OpenSSH does
> increase the risk of a compromise being systemic rather than limited to
> a particular vendor. The other side to the coin, though, would be the
> benefits in terms of scrutiny and speed to resolve the issue (produce a
> patch, at least) when it does happen. But it's a good point.

Compromises and trade-offs :-)

That'd break common enterprise setups like having 2 firewalls running
different distributions. Not sure how you get around that once all the
distros commonly used/accepted in the enterprise world agree on
shipping the same version of server software.

Using another OS instead of another distribution is a big, big change
that costs a lot and increases the risks (a lot in the short term,
less in the long term) but might be the only way out.

It's one downside, but I think it matters and there are others.

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Mark Shuttleworth]

Marc Haber wrote:
> Hi,
>
> On Wed, Aug 05, 2009 at 09:32:36PM +0200, Jesús M. Navarro wrote:
>   
>> In other words: freeze on december the first doesn't mean that if, say, 
>> Gnome 
>> will publish it's new shiny 1.2 version by december the 15, the last beta 
>> should have to be included, but that the december version will ship version 
>> 1.1 (or whatever is the previous known to work stable).  It's up to the 
>> upstreamer to decide if next time they will publish by november the 15th 
>> instead of december the 15th so their latest greatest gets to be shipped.  
>> 
>
> So we basically force a time-based release schedule upon our upstreams
> when we do time-based freezes? I am not sure whether upstreams are
> going to like this.
>   

No, we give them the opportunity to recommend a version. It might be an
older version, or a version they happen to be about to release, it's not
*necessarily* time-based for them. We're going to pick a version of
their stuff anyway, this just makes it easier to participate in one
conversation with many distros about which would work best.

I do think more upstreams will adopt time-based releases. Kernel, GNOME,
KDE and others are already doing quite well there. X would like to, but
is short of manpower on the RM front.

Mark

Re: On cadence and collaboration

[Julien BLACHE]

Marc Haber  wrote:

> [1] and I am actually quite disturbed that Mark gets to talk to the
> DPL more often than Debian does

Bah, journalists get to talk to him even more often, especially the
hacks at The Register. I learned quite a few things by reading papers
on The Register. Disturbing, indeed.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Mark Shuttleworth]

Julien BLACHE wrote:
> You are on a fight against proprietary software (you made that clear
> through your wording in your first mail). One of the issues with
> proprietary platforms is that everyone running a given platform runs
> the same security holes.
>
> Now, that obviously applies equally if platform = Debian, but not if
> platform = Linux. There aren't different Windows vendors. There's only
> one. There are different Linux vendors. If they all offer the same
> thing, then we have another monoculture and we lose something,
> something very real.
>
> In the free software world, the diversity we have today, which is
> partly due to unaligned releases from the major vendors, is an asset.
>
> You have been talking a lot about the implications at our level and
> a bit about upstream, but there are implications downstream too that
> must not be overlooked and they might not be the most obvious.
>   
Yes, I would have to agree with your point - having more distributions
on the same base version of something like Apache or OpenSSH does
increase the risk of a compromise being systemic rather than limited to
a particular vendor. The other side to the coin, though, would be the
benefits in terms of scrutiny and speed to resolve the issue (produce a
patch, at least) when it does happen. But it's a good point.

Mark


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Josselin Mouette]

Le mercredi 05 août 2009 à 20:25 +0100, Mark Shuttleworth a écrit :
> At the micro-level, across the long tail of thousands of packages, I
> don't expect there to be detailed coordination through a process like
> this. The main benefit would come from the smaller set of core
> infrastructure packages that generate a lot of bugs and maintenance
> issues. Things like:
> 
>  - Python - 2.6, 2.7, 3.2?

> Now, that's not a large percentage of the archive, but they are all
> things that have a lot of consequences, and differences there drive a
> lot of other packaging differences (especially things like Python).

If you want your examples to be meaningful, please don’t invoke cases
where a Canonical employee is specifically holding back development in
Debian.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: On cadence and collaboration

[Marc Haber]

On Wed, Aug 05, 2009 at 08:44:29PM +0100, Mark Shuttleworth wrote:
> My expectation is that Debian will want to have more flexibility in how
> long the release is baked than Ubuntu would normally give itself. My
> hope is that we can agree on a GNOME and KDE version, and that Debian
> will thus benefit from all the work Ubuntu does on that and then have a
> few extra months (as many as deemed necessary) to bake it to Debian's
> satisfaction.

And you are willing to allow Ubuntu to release with outdated KDE and
outdated GNOME, frozen in Dezember, while both upstreams releasing
again in January? In the past, so I have been told, Ubuntu has let the
current versions slip into the April release, which would not be
possible if you were syncing with Debian.

Or do you expect that we would let new KDE and new GNOME into a
distribution frozen two months earlier to accomodate Ubuntu?

> The difference in our language is about the meaning of "freeze" in
> December. I think December is not about actually freezing, it's about
> reviewing and planning and looking for opportunities. Certainly, I think
> the Debian team will want to freeze some things very early (December!),
> but some maintainer teams may well be willing to commit to using
> something that will freeze a little later, especially if they can
> collaborate well with Ubuntu on those packages.

If you mean that Debian continues its staged freeze, starting with the
toolchain in December, followed by other stages and the last stage
including the desktop environments in february, do you seriously
expect us to release before October? That would be overly optimistic,
we're not that fast. And, even if we were that fast, Ubuntu LTS would
be on the market half a year earlier, giving Ubuntu a strong advantage
over Debian stable.

This still looks like marketing suicide for Debian to me.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Anthony Towns]

On Wed, Aug 05, 2009 at 08:44:29PM +0100, Mark Shuttleworth wrote:
> Margarita Manterola wrote:
> > If Debian commits to a December freeze, would that mean that Ubuntu
> > commits to releasing 10.04 with KDE 4.3 (already released) and [...]
> The proposal as I understood it was that in December, the key component
> maintainers / release managers from all interested distributions would
> discuss, on a public mailing list, their plans for the base versions of
> those components in their 2010 releases. 

That seems very different to what's usually meant in Debian by "freeze"
(and "freeze" was the term used in both the debian-announce and
debian-devel-announce mails). AFAICS, a December agreement of that sort
would mean a Debian freeze somewhere between January and March.

> The rough guide I heard was that, if we looked at the list in December,
> we'd probably be able to agree on things like the default versions of
> Python, Perl, X and GCC, but that it might be harder on kernel, GNOME
> and KDE.

It'd be nice to hear from the release team if this was what they were
considering...

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Marc Haber]

On Wed, Aug 05, 2009 at 11:47:23AM -0700, Russ Allbery wrote:
> Marc Haber  writes:
> > At least Debian has epically failed in "wide communication" of this
> > decision by first putting out a press release before informing the
> > community itself.
> 
> Which, of course, is not Ubuntu's fault.  Problems with communication
> internal to the Debian project are not ones that Mark Shuttleworth can
> solve, or should attempt to solve.

I didn't expect him to. I just wanted to point out why the headwind
experienced is so strong. Actually, trying to sync up distributions
might be an interesting idea, and it is -our- release team[1] that
epically failed in communicating, playing a vital part in the current
mess.

Greetings
Marc

[1] and I am actually quite disturbed that Mark gets to talk to the
DPL more often than Debian does

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Marc Haber]

Hi,

On Wed, Aug 05, 2009 at 09:32:36PM +0200, Jesús M. Navarro wrote:
> In other words: freeze on december the first doesn't mean that if, say, Gnome 
> will publish it's new shiny 1.2 version by december the 15, the last beta 
> should have to be included, but that the december version will ship version 
> 1.1 (or whatever is the previous known to work stable).  It's up to the 
> upstreamer to decide if next time they will publish by november the 15th 
> instead of december the 15th so their latest greatest gets to be shipped.  

So we basically force a time-based release schedule upon our upstreams
when we do time-based freezes? I am not sure whether upstreams are
going to like this.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

freezing in december and holidays (was: On cadence and collaboration)

[martin f krafft]

also sprach Manoj Srivastava  [2009.08.05.1708 +0200]:
> I do have objections to starting that with a foreshortened
>  release cycle, and while I am neutral about December as a freeze month
>  in general, I suspect  that the the actual date should come after
>  negotiating with major component package maintainers (and upstream),
>  and efforts in house aimed at improving Debian, and, ultimately, other
>  distributions.

Freezing in December means that the first 2-3 weeks after the freeze
will be mostly lost in terms of preparing a release due to holidays.
In my 10+ years of Debian experience, the Christmas time has usually
been the lowest activity time each year.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"all i know is that i'm being sued for unfair business
 practices by micro$oft. hello pot? it's kettle on line two."
  -- michael robertson


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: On cadence and collaboration

[Julien BLACHE]

"Jesús M. Navarro"  wrote:

Hi,

>> I think we'll lose part of the "we release when it's ready" philosophy
>> (that our RMs seem to despise so much). Because part of this is to
>> freeze when it's ready.
>
> Not at all if done properly.  Freeze on a date simply means that what it's 
> ready on that date is included, what it's not ready won't be included, simply 
> as that.  When you couple that with a freeze date well known in advance, you 
> allow interested people to plan properly.

The freeze date for the past few releases has always been known in
advance and refined as we went. The problem is that a lot of
upstreams do not have a planning that we can compare against and base
our work upon, so for a lot of the packages we "just" follow upstream.

Not to mention our very own infrastructure issues that have bitten us.

> (pleeease, wait for another two weeks for our new and shinny).

That's largely an end-user-induced issue, desperately trying to escape
the "Debian obsolete" nickname for Debian stable. We're weak ;)

>> A time-based freeze could mean for some teams that they'll have to
>> stop work basically for months to a year. It already takes too much
>> time to recover after a release, this won't help.
>
> Why?  I really don't see your point unless you mean for the packager under 
> current conditions where no real branches are allowed on Debian (but the 

That's exactly my point. We suck at freezing.

> everbody's bag that it is 'experimental' that has demonstrated not to be a 
> solution at all).  This needs to be changed and I expect the time-based 
> freeze to be the tick that will finally push this change.

It all boils down to the current testing system being inadapted to our
needs. But that's something we couldn't really know for sure until we
had tried it for a couple of releases, and I think we still won't know
for a release or two because of the new tools that have been put in
place to handle transitions (and others).

> If that's what you meant, I think you don't have an argument against 
> time-based freezes but against the "first time-based freeze on Dec-2009" but 

A lot of things need to line up for a release. Debian is very large
and the windows of opportunity are few and small. Deciding on versions
of core packages between distributions could help, but a fixed-date
freeze probably won't. It could even make things worse, as it could
make it harder to iron out the issues (like having to convince the
release team to let a new upstream in to fix something because there's
really no better way). Seriously, everybody gets bored and fed up
during a freeze.

I am of the opinion that no matter how hard you try, you can't *make*
a Debian release happen. There's some point at which the release
starts to happen, a point where a critical mass of DDs is reached, the
point where everybody uses the word "release" more than any other
word.

> to push it to a latter date in order to have time for the tools to be 
> developed (hey, Mr. Canonical, there you have a very interesting case where 
> your hands and moneys would certainly be more than welcome).

Remember dunc-tank?

>> In this day and age, you have to look at features in addition to the
>> version number, because the latter isn't necessarily very telling of
>> the real changes from one release to another. Major features are
>> delivered in minor releases nowadays...
>
> I already said that to be simply malpractice and beyond a distribution's 
> ability to correct (while I'm with Shuttleworth in that concurrent freezes 
> would help to "show the proper path" to upstreamers).

What we'd need is some sort of "upstream academy" where we could teach
upstream:
 - how to version properly
 - how to properly manage their API/ABI for shared libraries
 - how not to make a mess of their release tarball
 - ... (let's not make a list, it'd be depressing)

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Jan Hauke Rahm]

Hi Mark,

I apologize if this was already said somewhere; somehow I've got lost in
this hundreds of mails... :)

On Wed, Aug 05, 2009 at 03:48:06PM +0100, Mark Shuttleworth wrote:
> No, as I wrote separately, this is more about signalling an emerging cadence
> across multiple distributions. For many reasons, it's easier for more
> commercial organisations to plan in years, and the proposal from the Debian
> release team happens to make that work well.
[...]
> Mandriva would be a likely candidate to participate as well. And I think SUSE
> could be convinced if we can get past this debate, too.

I understand you've been talking to other distributions as well about
syncing releases (or freezes) in order to ship same versions of major
system components. Now, much of the discussion here is about the actual
dates, i.e. the possible freeze in a few month as well as freezing in
the end of odd years to release in spring of even years. This idea seems
to fit best to your (ubuntu's) current release cycle and I feel many
Debian contributors see there your (inacceptable?) influence on Debian.

I'm interested in the reactions of other distributions. Are they likely
to change their release cycle to fit yours? Or would you be willing to
change Ubuntu's release dates if SuSE proposed LTS releases to come out
in odd years or similar?

Hauke


signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Mark Shuttleworth]

Hi Marga

Margarita Manterola wrote:
> If Debian commits to a December freeze, would that mean that Ubuntu
> commits to releasing 10.04 with KDE 4.3 (already released) and GNOME
> 2.28 (to be released in a few months), instead of KDE 4.4 (to be
> released in January) and GNOME 2.30 (to be released in March)?
>
> This has been one of the main concerns of the December freeze, apart
> from the fact that we wouldn't meet our release goals, that you are
> suggesting how to solve.  Ubuntu has shown in the past a tendency to
> ship with the latest versions of software. In the case of GNOME, the
> freeze in Ubuntu usually happens before GNOME is even released, and
> yet the latest GNOME goes into the release.
>
> So, how would that work in this case?

The proposal as I understood it was that in December, the key component
maintainers / release managers from all interested distributions would
discuss, on a public mailing list, their plans for the base versions of
those components in their 2010 releases. It wouldn't be realistic to
hope that every distro joins a consensus on every component - there are
good reasons why some might want to use a more bleeding edge piece and
others may want a more conservative piece. For example, architecture
support in Debian might require a different GCC or kernel than the one
that everyone else goes with, and that's fine.

The rough guide I heard was that, if we looked at the list in December,
we'd probably be able to agree on things like the default versions of
Python, Perl, X and GCC, but that it might be harder on kernel, GNOME
and KDE. That's OK by me - whatever consensus *does* emerge from the
process is a win that we otherwise would not have. Some teams may not be
ready for the discussion, some might be. That's OK too.

My expectation is that Debian will want to have more flexibility in how
long the release is baked than Ubuntu would normally give itself. My
hope is that we can agree on a GNOME and KDE version, and that Debian
will thus benefit from all the work Ubuntu does on that and then have a
few extra months (as many as deemed necessary) to bake it to Debian's
satisfaction.

> It is my opinion that freezing after GNOME releases (and gets into
> testing) would be better for Debian.  This means either April or
> October, depending on which GNOME release we want to ship.
>
> If we think, for real, that December is the best month of the year to
> freeze (I definitely don't), then we would need to somehow convince
> both GNOME and KDE (and then other upstreams as well) to release in
> October/November.  It's not that much of a change for GNOME, but I
> don't see this happening this year for KDE.  Maybe next year, if this
> is planned well in advance.
>   
The difference in our language is about the meaning of "freeze" in
December. I think December is not about actually freezing, it's about
reviewing and planning and looking for opportunities. Certainly, I think
the Debian team will want to freeze some things very early (December!),
but some maintainer teams may well be willing to commit to using
something that will freeze a little later, especially if they can
collaborate well with Ubuntu on those packages.

> But why December? December is a very nasty month to do important
> things, people go on holidays, stay away from their computers for one,
> two or more weeks.  If anything, I think December is the worst month
> to plan for a freeze.
>   
It's true that Decembers a fractured month, and it would arguably be
better to do heavy lifting in another month. I imagine the main work
will really be Feb-March, once the decisions are final and widely
communicated. In December, by this proposal, we would just have a series
of threads on a list like the distributi...@lists.freedesktop.org list,
where we try to establish what consensus we can across the major
components. It would be planning and discussion, not actually starting
the freeze itself except for those components which the maintainers and
release managers felt it necessary.

Mark

Re: On cadence and collaboration

[Noah Meyerhans]

On Wed, Aug 05, 2009 at 03:48:06PM +0100, Mark Shuttleworth wrote:
> >>  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... which in turn makes it easier for
> >>  the security teams and maintainers in the distribution.
> >> 
> >
> > In practice, most upstreams adopt a "you're using a version that's two
> > weeks old, go update to our current development snapshot and see
> > yourself whether the bug is still there" attitude.
> >   
> That's true. To upstream there is "tip" (which all real developers run,
> right? ;-)) and then there's "the cloud of released versions which
> distributions are still shipping". It's hard to get their attention
> about the particular version that any one distribution is shipping, but
> I think it's reasonable to believe it would be easier to get their
> attention about a version that *many* distributions adopted.

Additionally, even if upstream isn't willing to provide any help to
distros shipping what they consider to be a "stale" version, the distros
are in a better position to help each other if they're shipping similar
versions.  We see this sort of cooperation _all the time_ in the
security community via the vendor-sec mailing list.  Patches for a given
problem may be proposed by a representative from one distro, reviewed by
members of several others, finally used by even more.  This may all
happen with or without help from upstream.  Either way, it's easier for
everybody involved if people are using similar versions.  I suspect we'd
see a lot more help from upstream developers if they knew they only had
to come up with a fix for a given problem once, rather than for several
different versions.  We benefit either way, though.

noah



signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Jesús M. Navarro]

Hi, Julien:

On Wednesday 05 August 2009 20:42:03 Julien BLACHE wrote:
> Manoj Srivastava  wrote:
>
> Hi,
>
> >> From the very start of the Debian Project, Debian has been different
> >> from everything else: different package management tools, different
> >> philosophy, different organization, you name it.
> >
> > But most of these will not be lost if we have a time based
>
> I think we'll lose part of the "we release when it's ready" philosophy
> (that our RMs seem to despise so much). Because part of this is to
> freeze when it's ready.

Not at all if done properly.  Freeze on a date simply means that what it's 
ready on that date is included, what it's not ready won't be included, simply 
as that.  When you couple that with a freeze date well known in advance, you 
allow interested people to plan properly.

In other words: freeze on december the first doesn't mean that if, say, Gnome 
will publish it's new shiny 1.2 version by december the 15, the last beta 
should have to be included, but that the december version will ship version 
1.1 (or whatever is the previous known to work stable).  It's up to the 
upstreamer to decide if next time they will publish by november the 15th 
instead of december the 15th so their latest greatest gets to be shipped.  
The fact that they'll know well in advance when the freeze is to be expected 
is what will allow them space enough to make a savvy decision while now, with 
the "freeze when ready" is a matter of luck and a point of friction 
(pleeease, wait for another two weeks for our new and shinny).

> A time-based freeze could mean for some teams that they'll have to
> stop work basically for months to a year. It already takes too much
> time to recover after a release, this won't help.

Why?  I really don't see your point unless you mean for the packager under 
current conditions where no real branches are allowed on Debian (but the 
everbody's bag that it is 'experimental' that has demonstrated not to be a 
solution at all).  This needs to be changed and I expect the time-based 
freeze to be the tick that will finally push this change.

I envision a system where a new upload will create kind of a branch and 
trigger a dependency cascade where all dependent (depend, suggest and 
recomend) packages are alerted so their maintainers can test for obvious 
problems and ack the upgrade or release a new change on the branch that again 
triggers the dependency cascade for its dependants.  Once everybody acks or 
upgrades the whole branch gets commited into what currently is "testing" (the 
ack mech will in turn help for the MIA case: an unanswering maintainer 
would -under proper conditions, automatically meant for the package to be 
orphaned or even retired; a maintanier whose last package goes that way would 
be automatically marked for MIA process).

This way, you could freeze testing almost any day without problems (and Ubuntu 
could easily go on their own if in the end that's better for their interests, 
since the health of testing would be much better any day going almost without 
the "upgrading storms" current process almost guarantee on testing from time 
to time).

If that's what you meant, I think you don't have an argument against 
time-based freezes but against the "first time-based freeze on Dec-2009" but 
to push it to a latter date in order to have time for the tools to be 
developed (hey, Mr. Canonical, there you have a very interesting case where 
your hands and moneys would certainly be more than welcome).

> In this day and age, you have to look at features in addition to the
> version number, because the latter isn't necessarily very telling of
> the real changes from one release to another. Major features are
> delivered in minor releases nowadays...

I already said that to be simply malpractice and beyond a distribution's 
ability to correct (while I'm with Shuttleworth in that concurrent freezes 
would help to "show the proper path" to upstreamers).


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

Mark Shuttleworth  wrote:

>> Being different and independent actually enables us to be better at
>> what we're doing than anyone else.
>
> I agree, that conscious, planned and considered differences are the best
> way to beat the competition or stand for your brand. If you do the same
> thing as everyone else it's very difficult to be better.

Releasing (or freezing, FWIW) at the same time as everyone else is a
part of that. Your developement then becomes bound in just the same
way as everyone else's, with all the consequences you can think of.

As the ultimate goal is to get pretty much all the free software world
to sync up for distro releases, this means everyone will work on the
same fixed schedule (with ca. 2-year development periods). I'm
wondering about the impact this will have on roadmaps in different
projects. I fear it may bring to free software some of the worst
issues of the proprietary/commercial software world (no vision past
the next big release, for instance).

> you vs your competition. In Debian's case, I can think of several things
> that really define the brand and the values. Supporting more
> architectures. Having the most democratic processes. debian-legal. And
> many more. None of them depend on having the same, or different base
> versions of the major components as any other distro.

I'm not sure our governance model is of much interest to the lambda
end-user, she probably also doesn't give a damn about debian-legal and
architecture support.

> some delta. It's worth paying the cost of that delta if it helps you be
> you. It's not worth having a delta just because nobody bothered to sit
> down and talk about it.

If it works that way already, why bother?

Also, what are we really talking about here? Desktop? Is that it? All
of this seems very desktop-centric to me.

What's the story on the server front, and what are the implications?
Do we set an Apache version everybody will ship, too? What impact does
that have on security? When everyone gets the same Apache version
accross all distributions, with the same issues? Does that buy us
anything? Isn't diversity better here?

You are on a fight against proprietary software (you made that clear
through your wording in your first mail). One of the issues with
proprietary platforms is that everyone running a given platform runs
the same security holes.

Now, that obviously applies equally if platform = Debian, but not if
platform = Linux. There aren't different Windows vendors. There's only
one. There are different Linux vendors. If they all offer the same
thing, then we have another monoculture and we lose something,
something very real.

In the free software world, the diversity we have today, which is
partly due to unaligned releases from the major vendors, is an asset.

You have been talking a lot about the implications at our level and
a bit about upstream, but there are implications downstream too that
must not be overlooked and they might not be the most obvious.

>> I don't really care about what they say, I care about how they act
>> upon it afterwards. And unfortunately there's no guarantee that
>> they'll support us better than they do today. Especially if those
>> statements were made without community backing.
>   
> There's no guarantee, no. But community members rally to a good,
> inspiring, intellectually true vision. You may not get them all, and you

Wishful thinking. Community members can also rally to the most popular
proposer, regardless of the proposal she puts forward. Not meant at
you, but to illustrate that things don't necessarily work as they
should.

> may not get the leader, but you will ensure that on every mailing list
> *someone* will be asking the question "what can we do to help those guys
> with their noble cause"?

I get your point.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Mark Shuttleworth]

Steffen Moeller wrote:
> the independence is not necessarily planned. To my perception it is more of a 
> "I am using
> my current distro which I know well and quickly (or less quickly) and 
> incrementally
> improving a package of my interest as good as I can" without looking much 
> left, right or
> down to other dis(s)tros.
>
> We are all (mostly) volunteers and often the looking left or looking right 
> takes much more
> time than the packaging itself.
Agreed. And the more different distributions there are, the more
left-and-right there is to think about.

At the micro-level, across the long tail of thousands of packages, I
don't expect there to be detailed coordination through a process like
this. The main benefit would come from the smaller set of core
infrastructure packages that generate a lot of bugs and maintenance
issues. Things like:

 - Python - 2.6, 2.7, 3.2?
 - Perl - don't even want to go there :-)
 - GCC - 4.4, 4.5?
 - X - 1.8? 1.9?
 - OO.o?
 - Kernel? 2.6.40? 2.6.42?

Now, that's not a large percentage of the archive, but they are all
things that have a lot of consequences, and differences there drive a
lot of other packaging differences (especially things like Python).

I don't think such a process could sustainably get beyond the major
chunks of infrastructure. But achieving that would itself send a huge
signal to the broader upstreams. If nothing else, we may start to see
even small upstreams showing up and saying "OK, we'll recommend this
version as you 2010 general consensus, and in return if you ship that
we'll do point releases to make maintenance easier". Which would be a
win for the security teams :-)

Mark

Re: Debian decides to adopt time-based release freezes

[Carsten Hey]

> Steve Langasek wrote:
> > Does that mean you don't think Ubuntu developers contribute fixes
> > back to Debian today?

As security, contributing fixes back to Debian is not a product nor
a state, it's a process.  We should all be interested in optimizing this
process further.

http://patches.ubuntu.com/ indeed makes the packages easier to merge but
it is not as powerful as our patch tracking system [1].  One possible
step to improve the situation could be a similar service provided by
Ubuntu based on the work which already has been done by Sean Finney.
The source code is available in a public repository and it is GPL2
licensed.

After such a service would have been implemented one could think about
things like adding a special tag to patch headers to recommend these
patches to be merged by Debian.  It could also be useful to be able to
specify how strong such a recommendation is.

Is there already a (wiki) page which describes how a Debian maintainer
can track his packages in Ubuntu or how to handle Ubuntu originated
bugs?  If this is the case it should be promoted better, e.g. in Misc
Developer News.


Carsten

 [1] http://patch-tracking.debian.net/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Jesús M. Navarro]

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, 

Re: On cadence and collaboration

[Andreas Tille]

Hi Mark,

thanks for the time you spended on this mail to improve cooperation.
I'm currently under time pressure - so I pick only a few points. in
my answer.  Please assume general agreement to your reasoning about
the needs of cooperation.

On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote:
> 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. 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.

Thanks for this!

> create divide and disharmony. I stayed away from DebConf this year - the
> first time in six years - because I didn't want to be a flashpoint for
> division,

Ups, the reason for you to stay away to not be a flashpoint makes me
somehow sick.  I was wondering about your reasons - it's a shame if
this would be the main point.

> To achieve anything together, we'll both need to work together, we'll
> need to make compromises or we'll need to contribute effort to the other
> side. If the Debian community is willing to consider a December freeze,
> then Ubuntu (and Canonical) will commit resources to help Debian meet
> that goal. It means we'll get less done in Ubuntu, but the benefits of
> having a schedule which could attract many other distributions would
> outweigh that.

I really really agree here.  My position was always that the diff
between Debian and Ubuntu should be as small a possible and IMHO this
is a great step in this direction (and I think I'm speaking here more
in the interest of Ubuntu than in the interest of Debian - at least
this is my personal view on the issue).

Thanks for your extensive mail.  I read some frustration out of it
and I hope that only a minority in Debian will give reasons to become
frustrated.

Hope to see you at any other event (but did not made up my mind about
DebConf 10)

 Andreas.

-- 
http://fam-tille.de
Klarmachen zum Ändern!


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On syncing freeze dates with other distributions

[Mark Shuttleworth]

Bernd Zeimetz wrote:
> Manoj Srivastava wrote:
>
>   
>> I also think that we should be looking at when we freeze not
>>  merely at when a derived distro freezes, but when major system
>>  components release, and when top level sister distributions freeze
>>  (we'll get far more benefit for Debian users were we to sync up with
>>  fedora/rhel; and have more clout with upstream, especially if Ubuntu
>>  sync's up with Debian/red hat as well).
>> 
>
> Ack. It makes *mucH* more sense for use to keep in sync with fedora/rhel than
> with Ubuntu. Especially Fedora tries out the very latest funky stuff, it is
> often really worth the work to have a look what they're doing. At the end this
> will help Ubuntu, too - if they manage to change their freeze time to an
> appropriate date similar to the one of Debian.
>   
I reached out to RHEL last year to see if they are interested in
adopting a predictable cycle of releases, and collaborating around them.
They did not respond to the email. I've heard it said informally that
they will "never" do that. In fact, I think RHEL could be persuaded to
join such a movement, but only if we have won over almost everyone else
first! That's why I've tried to include Novell in the discussion (they
are more interested, but still not takers to the idea).

Agreeing an approach between Debian and Ubuntu would be a very
significant first step. I believe we could then bring in many of the
smaller distributions, followed by Novell, and ultimately Red Hat too.

Mark

Re: On syncing freeze dates with other distributions

[Mark Shuttleworth]

Manoj Srivastava wrote:
> On Mon, Aug 03 2009, Russ Allbery wrote:
>
>   
>> Michael Banck  writes:
>>
>> 
>>> The other concern I have is lengthening our release cycle to 2 years - I
>>> think this is quite a bit too long, I am very happy with the current
>>> (rather informel) 1,5 years which is just between the 6-month release
>>> cycle of the Fedora, OpenSuSE and Ubuntu community distributions and the
>>> RHEL, SLES, LTS enterprise distributions.
>>>   
>> Amen.  I think two years is a little too long and 18 months would be much
>> better.
>> 
>
> We never actually have managed the 18 month release, have we? We
>  freeze approximatly 18 months after the last release, and then release
>  about 2 years or so after the last release.
>
> So, in steady state, freezing/releasing roughly two years apart
>  will be close to what we do, no?
>   

Yes, in practice, a two year cadence is more achievable for Debian,
based on past performance, and that is a significant contributor to my
feeling that the broader free software ecosystem could align around a
two year cadence. Debian reflects many of the underlying patterns in the
whole ecosystem.

I think that's even more true if it were part of a broader collaboration
with many distributions (not just Ubuntu). In other words, if we make
the commitment, it becomes easier to achieve. On the other hand, if we
demonstrate a spectacular inability to make a commitment, it gets much
harder :-)

Manoj, I would strongly support your call to have more distributions
involved. This is not, to my mind, about Debian-Ubuntu, as much as it's
about coaxing the whole ecosystem to embrace a cadence that in turn
makes collaboration so much easier. I've already reached out to Novell
SUSE, and had a blog scheduled for this week which would make an open
call for others to participate in the summit that was envisaged for
December where we look for opportunities to share common base versions.
I've put that on hold, given the debate unfolding here, but still
believe it's both achievable and beneficial not just to us (Debian and
Ubuntu) but to many other groups in free software too.

Mark

Re: Debian decides to adopt time-based release freezes

[Mark Shuttleworth]

Pierre Habouzit wrote:
> On Tue, Aug 04, 2009 at 10:29:11AM +0100, Steve Langasek wrote:
>   
>> I'm sorry that you have a negative impression of Ubuntu's relationship
>> with Debian, but there's plenty of data available that contradicts
>> your conclusion (including BTS reports that have been posted to this
>> very thread).
>> 
>
> The problem is there is also plenty of data, like for example the recent
> #539950 (on a package never uploaded to Debian) which is looking a _lot_
> like LP#408901. In this bug, the Ubuntu developer is (IMHO) trying to
> make the Debian one find, fix and patch the bug for him.
>
> The problem is (as a DD) that I would expect Ubuntu to collaborate the
> most on the harder core packages, meaning the toolchain, the kernel,
> X... Alas, it happens more coincidentally than on a regular basis, and
> that saddens me.
>
> I'm not saying there aren't any working cases of cooperation, and I
> welcome them. But there are way too many example of bad (or rather
> inexistant) cooperation, or even dirty tricks like #539950, which
> undermines the former tries a lot.
>   
Pierre,

When you have two large, complex, passionate organisations there will
always be plenty of opportunities to find fault with one another. Do you
not believe that it would be possible to find a long list of cases where
Debian developers have acted in a way that made collaboration difficult
or impossible, or could be interpreted as bad faith? Of course it would.

Nevertheless, we never let those incidents poison our commitment to
working better with Debian. On balance, when I look at the huge effort
that has gone into better collaboration with Debian, from many core and
MOTU developers in Ubuntu, I think we should celebrate those successes
and inspire people to do more of that, rather than taking every
opportunity to find fault.

In this conversation, there are large groups of people who's starting
assumption is that "Ubuntu is bad", or "Debian is difficult", and they
find facts to support that assumption. Fair enough, that's human nature.
But it will never improve the state of the world to focus on things that
people believe are absolute - if you want to improve the state of the
world, you need to look for opportunities to make it better.

Instead of saying "there's a bug that was badly handled, so we should
never collaborate better on anything", let's look for opportunities to
make things better. We have a good opportunity to make a profound change
in the way upstreams and distributions engage. A change that will really
help the whole free software ecosystem, and many distributions beyond
Ubuntu and Debian. Isn't it worth exploring that idea for its full value?

Mark

Re: Debian decides to adopt time-based release freezes

[Mark Shuttleworth]

Werner Baumann wrote:
> The two models as I can see them from the discussion so far:
>
> Model 1:
> Debian freezes in December
> Debian developers concentrate on fixing RC bugs
> Ubuntu developers concentrate on including newer versions of major
> software packages
> When the number of RC bugs in Debian is low enough Ubuntu freezes
> Ubuntu and Debian release at approximately the same time
> With this model Debian developers will bear the main burden of bug
> fixing while Ubuntu will use the time to integrate newer software
> packages.
>
> Model 2:
> Debian and Ubuntu freeze at the same time (December?)
> Debian and Ubuntu developers coordinate in fixing RC bugs
> Debian and Ubuntu release at about the same time
> With this model the burden is shared and both operating system will be
> at the same state with respect to the main components. Differences will
> be according to different philosophy (questions asked by the installer,
> components and configuration of a standard installation, what is "user
> friendly"). There may be also differences in the versions of main
> software packages, but this differences would be clear at freeze time
> and due to different philosophy.
>
> While I think model 2 could prove useful for Debian and Ubuntu I can't
> see what Debian would gain from model 1. I believe this discussion
> would look very different if Ubuntu says it agrees on model 2.
>   
We certainly agree on the idea that multiple distributions, and all the
major upstreams, would benefit from a coordinated freeze. If we sit down
and agree to use the same version of the kernel, for example, that helps
the kernel community plan their merge windows and merge criteria in a
way that they have never been able to do before.

It would be substantially easier to collaborate on RC (and non-RC) bug
fixes where the base versions of major components were the same.

That said, I don't believe that any distribution should feel compelled
to go with a particular version. If Mandriva really wants to go with a
different version of X, say, then all power to them. There will be
benefits to being on a common base with others, and there will sometimes
be benefits or constraints which mandate a delta for any particular
distribution.

So, coordinated *freezes* make a lot of sense for distributions *and*
for upstreams.

However, when it comes to the release, there are equally good reasons
for different distributions to take different approaches. We each have
different policies and focuses. We treat different issues as release
blockers. We are focused on different use cases. All of those will drive
differences in release dates.

So, I strongly support your Option 2 as the model, but I don't think it
leads to exactly the same freeze-and-release dates. It leads to a shared
freeze date where we establish how much common signalling we can send to
upstreams, followed by improved collaboration both with other
distributions and with upstreams, and varying release dates.

Is that a bad thing? Well, I think some people will say a distro is
*better* if it releases later. Others will say a distro is better if it
releases on a schedule. There have been so many distributions around for
so long and yet each of the majors, including both Debian and Ubuntu,
have loyal and passionate users. I don't think this is about trying to
convince users to switch - they believe in the brands they believe in,
to the credit of both groups, not to either detriment.

Mark


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Russ Allbery]

Marc Haber  writes:
> On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote:

>> I hear this story all the time from upstreams. "We'd like to help
>> distributions, but WHICH distribution should we pick?"

> I have never heard that story from an upstream, neither have I heard
> that other maintainers have heard that. Especially not from the upstream
> who consider themselves big and powerful.

I have.

Furthermore, even upstreams that currently aren't interested in
cooperating with distributions I suspect would change their minds if they
could support *one* long-term stable release.  It might take a few years
for them to come around, but it starts looking very appealing.

I'm skeptical about whether we can get there, but I think Mark's analysis
is fundamentally correct.

>> As pointed out on this list, Debian and Ubuntu share a great deal.

> I wouldn't call that "share".

I've had almost uniformly positive experiences working with Ubuntu users
of the packages that I maintain and integrating those packages into
Ubuntu, including valuable contributions and improvements that originated
in Ubuntu and were filed as bugs against the Debian packages (although
since I subscribe to all of the Ubuntu packages corresponding to my Debian
packages in Launchpad, I normally short-circuit that).

My corner of Debian would be noticably worse if it were not for Ubuntu,
and this is from someone who has never run Ubuntu and has no interest in
ever doing so.

> At least Debian has epically failed in "wide communication" of this
> decision by first putting out a press release before informing the
> community itself.

Which, of course, is not Ubuntu's fault.  Problems with communication
internal to the Debian project are not ones that Mark Shuttleworth can
solve, or should attempt to solve.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

Manoj Srivastava  wrote:

Hi,

>> From the very start of the Debian Project, Debian has been different
>> from everything else: different package management tools, different
>> philosophy, different organization, you name it.
>
> But most of these will not be lost if we have a time based

I think we'll lose part of the "we release when it's ready" philosophy
(that our RMs seem to despise so much). Because part of this is to
freeze when it's ready.

A time-based freeze could mean for some teams that they'll have to
stop work basically for months to a year. It already takes too much
time to recover after a release, this won't help.

I have doubts as to how that's going to work wrt our current
unstable/testing/stable scheme. We're only now, *years* and *releases*
after it's been introduced, starting to really get that working. I'm
not sure we've enjoyed the benefits of this system yet, yet we'd have
to change it once again for time-based freezes. (due to the
aforementioned issue; we need to keep unstable moving to mitigate
that - and no, experimental doesn't cut it)

>  freeze. Or are you talking about everyone shipping the same package
>  version? I think diversity based on version numbers of software
>  components is a false diversity; and makes people compare apples to

In this day and age, you have to look at features in addition to the
version number, because the latter isn't necessarily very telling of
the real changes from one release to another. Major features are
delivered in minor releases nowadays...

Other than that, I agree with you.

>  oranges. So if everyone ships the same version of GNOME, it allows
>  apples to apples comparison, and should make the strengths of Debian

Depending on how much time our GNOME team did have to beat the thing
into submission...

>  stand out (thought it would make life harder for journalists, since no
>  longer are the platitudes about differing software versions going to be
>  enough to carry a review)

Oh my. That alone would be a very good reason for everybody to sync
up. But hey, being journalists (were you thinking about bloggers, too,
here?), they'd find something else, equally meaningless, to carry
their bogus reviews.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Opera in your repos

[Ana Guerrero]

On Wed, Aug 05, 2009 at 07:10:48PM +0200, Cyril Brulebois wrote:
> (Beware sarcasm tags might be missing.)
> 
> Ana Guerrero  (05/08/2009):
> > Even in the case you release the opera code with a license that allow
> > distributing opera in non-free, there is not much point on
> > distributing it when we already have _totally free_ browsers.
> 
> There is: Linux is about Choice!
>

Like choosing not to give support to propietary stuff ? :D

Ana



-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

Eric Evans  wrote:

Hi,

> Maybe it's just me, but I don't see anything in your response that
> adds anything to the discussion.

You can see Marc's reply as documentation for people new to this
matter. There's some value in that.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Opera in your repos

[Santiago Vila]

On Wed, 5 Aug 2009, Ilya Shpan'kov wrote:

> Hi,
> 
> I work in Opera Software - yes, we make a proprietary browser ;)
> 
> Last 7 years I use GNU/Linux and know that, for example, in Russia the
> Opera browser is very popular in GNU/Linux Community. Unfortunately, not
> always I can see this browser in the non-free repos. Well, there is a
> question: whether Opera is included to your distro and if not - how we can
> fix this problem? We are ready for any discussions, technical help or
> agreement, if necessary.

As explained by Ana, Debian is about making a free operating system,
so we usually try to remove software from non-free when we have free
alternatives, not add more.

Anyway, I'll give you a more technical answer.

I see at least two problems in putting Opera in non-free:

First one, the End User License Agreement does not say anything about
redistribution. It is allowed at all? Under which conditions? Do those
conditions last forever, or may Opera Software terminate them at their
wish? Bear in mind that there are sites like snapshot.debian.net that
would copy each and every upload of opera from non-free to be archived
forever. If we can't do that it would probably not worth the effort.

The second problem I see is the discrimination against some
users. From the LICENSE text:

 You are entitled to use the Software on all personal computers
 (laptops/desktops). "Use" means loaded in temporary memory or
 permanent storage on the computer.

 You may not use the Software on non-PC products, devices, or embedded
 in any other product, including, but not limited to, mobile devices,
 internet appliances, set top boxes (STB), handhelds, PDAs, phones, web
 pads, tablets, game consoles, TVs, gaming machines, home automation
 systems, or any other consumer electronics devices or
 mobile/cable/satellite/television or closed system based service.

Well, the fact is that Debian aims to run on all those devices too.

Putting opera.deb in non-free would be deceptive to those users, as
most people assume that if something is in non-free, then the software
might be proprietary but at least use is not restricted, which would
not be the case here.

As Debian is about creating a free operating system, we don't have any
system or procedure to force people to accept licenses before dowloading
packages. With current tools, whoever bothers to package Opera for
non-free would probably add a debconf question in the line of "Are you
using an ordinary PC (laptop/desktop) or you are using something else?".

If I had to answer questions like that after installing something, I
am not sure I would be glad of doing so from a Debian server.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Opera in your repos

[Cyril Brulebois]

(Beware sarcasm tags might be missing.)

Ana Guerrero  (05/08/2009):
> Even in the case you release the opera code with a license that allow
> distributing opera in non-free, there is not much point on
> distributing it when we already have _totally free_ browsers.

There is: Linux is about Choice!

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Opera in your repos

[Ana Guerrero]

On Wed, Aug 05, 2009 at 05:11:12PM +0200, Ilya Shpan'kov wrote:
> Hi,
> 
> I work in Opera Software - yes, we make a proprietary browser ;)
> 
> Last 7 years I use GNU/Linux and know that, for example, in Russia the
> Opera browser is very popular in GNU/Linux Community. Unfortunately, not
> always I can see this browser in the non-free repos. Well, there is a
> question: whether Opera is included to your distro and if not - how we can
> fix this problem? We are ready for any discussions, technical help or
> agreement, if necessary.
> 
> Thanks in advance,
>

Please, learn about Debian philosophy and you will get the answer to
your question. Read from here:
http://www.debian.org/ all the "about" part.

Also:
http://en.wikipedia.org/wiki/Debian will give you a nice overview.

Even in the case you release the opera code with a license that allow 
distributing opera in non-free, there is not much point on distributing it
when we already have _totally free_ browsers.

Ana


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Manoj Srivastava]

On Wed, Aug 05 2009, Julien BLACHE wrote:

> Mark Shuttleworth  wrote:
>
> [Cc:ed as I don't know whether you're subscribed to -project]
>
> Hi,
>
>> freeze summit, and there are significant benefits to Debian to being
>> part of that rather than on a different schedule.
>
>>From the very start of the Debian Project, Debian has been different
> from everything else: different package management tools, different
> philosophy, different organization, you name it.

But most of these will not be lost if we have a time based
 freeze. Or are you talking about everyone shipping the same package
 version? I think diversity based on version numbers of software
 components is a false diversity; and makes people compare apples to
 oranges. So if everyone ships the same version of GNOME, it allows
 apples to apples comparison, and should make the strengths of Debian
 stand out (thought it would make life harder for journalists, since no
 longer are the platitudes about differing software versions going to be
 enough to carry a review)

IOW, a sync'd release is not likely to reduce diversity,

manoj
-- 
Electrocution, n.: Burning at the stake with all the modern
improvements.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Opera in your repos

[Ilya Shpan'kov]

Hi,

I work in Opera Software - yes, we make a proprietary browser ;)

Last 7 years I use GNU/Linux and know that, for example, in Russia the
Opera browser is very popular in GNU/Linux Community. Unfortunately, not
always I can see this browser in the non-free repos. Well, there is a
question: whether Opera is included to your distro and if not - how we can
fix this problem? We are ready for any discussions, technical help or
agreement, if necessary.

Thanks in advance,

--
Best regards,

Ilya Shpan'kov
Community Outreach Manager for Russia
Opera Software ASA

Mobile: +47 46351421
Web-site: http://my.opera.com/IlyaShpankov/
Skype: shpankov


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Manoj Srivastava]

On Wed, Aug 05 2009, Mark Shuttleworth wrote:

Thanks for the input. This was a far gbetter reasoned mail than
 some that have appeared on the list.

> 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?
>
> Well, the first thing is to agree on the idea of a predictable cadence.
> 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 :-)

Based on Debian's last two releases, I think we have a 22  month
 release cycle going; stretching it to 24 years is not a big
 deal. Speaking for myself, I think have a predictable freeze date,
 every two years, is a good thing. 

I do have objections to starting that with a foreshortened
 release cycle, and while I am neutral about December as a freeze month
 in general, I suspect  that the the actual date should come after
 negotiating with major component package maintainers (and upstream),
 and efforts in house aimed at improving Debian, and, ultimately, other
 distributions.

So yes, I concur.


> How do I think it could work in practice? Well, if Debian and Ubuntu
> went ahead with the summit in December, where we reviewed plans for 2010
> and identified opportunities to collaborate, I think we would get (a)
> several other smaller distributions to participate, and (b) several
> upstreams to participate. That would be a big win. It would set us off
> on a good course. If we delivered, then, we would virtually guarantee
> that almost all the distributions and key upstreams would participate
> the next time around. And if *that* worked, we'd win RHEL over too.

Umm, what summit is this? I think this is something that the
 Debian developer community has not been told about yet (which is
 somewhat irritating, but that is the theme for a different thread).

>
>
> First, there has been no secret cabal or skunkworks effort to influence
> Debian. As best I can tell, folks from both Debian and Ubuntu who have
> deep insight into release management established a shared interest in
> working together better, at many levels, and this was one idea that came
> forward. The fact that those discussions were open and ongoing was no
> secret - I wouldn't have talked about it in the media if it were!
> (Ironically, someone suggested that the fact that I was talking publicly
> about something in Debian implied there was a secret cabal. Aiieee.)

Well, the proof of the pudding is in the eating, no? The fact
 that the majority of the developers have expressed a complaint that
 they were not in the loop seems to indicate that the non secret bit has
 yet to be adequately demonstrated.

This  reminds me of a notice that was on display on the bottom
 of a locked filing cabinet stuck in a disused lavatory with a sign on
 the door saying 'Beware of the Leopard.

> Third, I think we need to call on the people who are not fundamentally
> prejudiced to speak out.

As long as criticism does not immediately accrue the label of
 bias, this is fine.

Now, if, as in a previous mail from you, synchronization implies
 that people are agreeing to ship with the same versions of the tool
 chain, X, KDE/GNOME, and other major components, that would mitigate
 some of the worry heard on this list about Debian being taken advantage
 of. Of course, determining what version of these packages will ship in
 a release needs to involve the maintainers and upstream developers of
 the package in question, with the RM's having a deciding role in what
 does or does not make the cut (decision after consultation is a horse
 of a different color than a priori decisions).

I currently object to shortening the current release, causing
 various teams to shelve their ongoing improvements and development
 plans, in order to hasten towards a sync process that has not even begu
 the process of deciding on which versions of major packages we will
 ship (and, personally, what the status of the reference selinux
 security policy shipped will be).

I see this as a good point to start discussion, not as a point
 where we decide to freeze in four months or so from now.

manoj
-- 
There are two kinds of egotists: 1) Those who admit it 2) The rest of us
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Steffen Moeller]

Hello,

Mark Shuttleworth wrote:
> Julien BLACHE wrote:
>>> Debian stands out in many respects, yes. But being different for the
>>> sake of it isn't a laudable goal: if there's a good idea, it deserves to
>>> be considered, even if others are already considering it.
>>> 
>> Being different and independent actually enables us to be better at
>> what we're doing than anyone else.

> I agree, that conscious, planned and considered differences are the best
> way to beat the competition or stand for your brand. If you do the same
> thing as everyone else it's very difficult to be better.

the independence is not necessarily planned. To my perception it is more of a 
"I am using
my current distro which I know well and quickly (or less quickly) and 
incrementally
improving a package of my interest as good as I can" without looking much left, 
right or
down to other dis(s)tros.

We are all (mostly) volunteers and often the looking left or looking right 
takes much more
time than the packaging itself. And in my view, this is mostly fine this way. 
In a perfect
world, upstream collects packages from the distributions quickly, at least 
those that
matter. And they would all read the bug reports that the distributions collect 
and react
to them - many thanks for launchpad, btw.

The thinking of releases I hope to disappear in some not so distant future. 
This would
then render all this discussion rather irrelevant, right? Instead, we should 
have packages
collected on our machine, whose cutting-edginess depends on the users' personal 
skills and
interests. This would be similar to stable with backports on for selected 
packages only.

Many greetings

Steffen








-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Mark Shuttleworth]

Hi Marc

Marc Haber wrote:
> this is kind of a personal reply; I am therefore writing this to you
> directly and only Cc'ing debian-project, and I do not know whether you
> read that mailing list.
>   
> On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote:
>   
>> 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,
>> 
>
> A pity. I bet many people would like to hear that response.
>   

I've tried to clarify my motivations without responding to personal attacks.


>> I hear this story all the time from upstreams. "We'd like to help
>> distributions, but WHICH distribution should we pick?"
>> 
>
> I have never heard that story from an upstream, neither have I heard
> that other maintainers have heard that. Especially not from the
> upstream who consider themselves big and powerful.
>   
At the last Linux Collaboration Summit, a panel of kernel leaders said
exactly this. We see more and more upstreams adopting time-based
releases, and cadences of 3 or 6 months. A few are starting to think
about 2-year long-term releases, too. So it fits.

>> 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.
>> 
>
> It will also cost the free software ecosystem a lot of what's one of
> its most major properties: diversity.
>   
Diversity in distributions comes from choice of components, not from
choice of component versions. Version skew just makes it much harder to
collaborate.

>>  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... which in turn makes it easier for
>>  the security teams and maintainers in the distribution.
>> 
>
> In practice, most upstreams adopt a "you're using a version that's two
> weeks old, go update to our current development snapshot and see
> yourself whether the bug is still there" attitude.
>   
That's true. To upstream there is "tip" (which all real developers run,
right? ;-)) and then there's "the cloud of released versions which
distributions are still shipping". It's hard to get their attention
about the particular version that any one distribution is shipping, but
I think it's reasonable to believe it would be easier to get their
attention about a version that *many* distributions adopted.

>> Well, the first thing is to agree on the idea of a predictable cadence.
>> 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 :-)
>> 
>
> Most upset that happened on the lists and in real life was about that
> Debian learned about your collaboration from a Debian press release.
>   
I agree, that was unfortunate.


>> As pointed out on this list, Debian and Ubuntu share a great deal.
>> 
>
> I wouldn't call that "share".
>   
We share many things, in the sense of having many things in common.

Do you believe that this is an unfair, or unbalanced relationship? What
does Ubuntu take from you, beyond that which you have freely given? And
whatever Ubuntu brings back to Debian, is that not of value?

>>  We have largely common package names (imagine what a difference that
>>  will make to practical discussions over IRC ;-))
>> 
>
> Right, this makes it much easier for Ubuntu users to pester Debian
> people with the problems that the Ubuntu community wasn't able to
> solve by itself.
>   
Noted.


>>  (most of the strongest Ubuntu
>>  contributors are or have been very strong Debian contributors too,
>> 
>
> yes, and have usually stopped doing their debian duties without
> properly stepping down upon their engagement with Ubuntu. This has
> greatly harmed Debian a few years ago when Ubuntu was still hatching,
> and has obviously also helped Ubuntu in getting more momentum than
> Debian since Ubuntu took privileges from Debian which slowed down
> Debian a great deal.
>   
The people concerned, for whom I have a great deal of respect, don't agree.

>>  and many new Debian maintainers have come to the project through
>>  Ubuntu)
>> 
>
> Yes. Ubuntu should think about the reason for Ubuntu people changing
> over to Debian.
>   
We see this differently. When a person comes to free software as an
Ubuntu user, starts contributing to Ubuntu, then begins the process of
becoming a Debian mai

Re: On cadence and collaboration

[Eric Evans]

[ Marc Haber ]
> this is kind of a personal reply; I am therefore writing this to you
> directly and only Cc'ing debian-project, and I do not know whether you
> read that mailing list.

Kind of a personal reply? Considering all of the accusations, and the
snide, cynical, and sarcastic remarks, I'd say it's quite personal.

Maybe it's just me, but I don't see anything in your response that
adds anything to the discussion. If you feel compelled to send such
"personal replies", could at least spare the list?

Thanks.

> On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote:
> > 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,
> 
> A pity. I bet many people would like to hear that response.
> 
> > I hear this story all the time from upstreams. "We'd like to help
> > distributions, but WHICH distribution should we pick?"
> 
> I have never heard that story from an upstream, neither have I heard
> that other maintainers have heard that. Especially not from the
> upstream who consider themselves big and powerful.
> 
> > 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.
> 
> It will also cost the free software ecosystem a lot of what's one of
> its most major properties: diversity.
> 

> >  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... which in turn makes it easier for
> >  the security teams and maintainers in the distribution.
> 
> In practice, most upstreams adopt a "you're using a version that's two
> weeks old, go update to our current development snapshot and see
> yourself whether the bug is still there" attitude.
> 
> > Well, the first thing is to agree on the idea of a predictable cadence.
> > 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 :-)
> 
> Most upset that happened on the lists and in real life was about that
> Debian learned about your collaboration from a Debian press release.
> 
> > As pointed out on this list, Debian and Ubuntu share a great deal.
> 
> I wouldn't call that "share".
> 
> >  We have largely common package names (imagine what a difference that
> >  will make to practical discussions over IRC ;-))
> 
> Right, this makes it much easier for Ubuntu users to pester Debian
> people with the problems that the Ubuntu community wasn't able to
> solve by itself.
> 
> >  (most of the strongest Ubuntu
> >  contributors are or have been very strong Debian contributors too,
> 
> yes, and have usually stopped doing their debian duties without
> properly stepping down upon their engagement with Ubuntu. This has
> greatly harmed Debian a few years ago when Ubuntu was still hatching,
> and has obviously also helped Ubuntu in getting more momentum than
> Debian since Ubuntu took privileges from Debian which slowed down
> Debian a great deal.
> 
> >  and many new Debian maintainers have come to the project through
> >  Ubuntu)
> 
> Yes. Ubuntu should think about the reason for Ubuntu people changing
> over to Debian.
> 
> > . When I look over the commentary on debian-devel and in debbugs and
> > on #debian-devel, I see a lot of familiar names from Ubuntu,
> > especially on the deep, hard problems that need solving at the core.
> 
> >From new people that weren't hired over to Ubuntu from Debian?
> 
> > So, practically, we would be in a good position to collaborate.
> 
> Of course. Ubuntu _is_ Debian in a very big part.
> 
> > I see mails
> > on this list saying it would be easier and better for Debian to
> > coordinate with distributions that I think would be almost *impossible*
> > to work with practically,
> 
> It is almost impossible to work with Ubuntu as soon as one doesn't agree.
> 
> > How do I think it could work in practice? Well, if Debian and Ubuntu
> > went ahead with the summit in December, where we reviewed plans for 2010
> > and identified opportunities to collaborate, I think we would get (a)
> > several other smaller distributions to participate, and (b) several
> > upstreams to participate.
> 
> You're a true visionary.
> 
> > A December summit is not about tying anybody's hands. It's about looking
> > for opportunities, where they exist naturally, and communicating those

Re: On cadence and collaboration

[Mark Shuttleworth]

Julien BLACHE wrote:
>> Debian stands out in many respects, yes. But being different for the
>> sake of it isn't a laudable goal: if there's a good idea, it deserves to
>> be considered, even if others are already considering it.
>> 
>
> Being different and independent actually enables us to be better at
> what we're doing than anyone else.
I agree, that conscious, planned and considered differences are the best
way to beat the competition or stand for your brand. If you do the same
thing as everyone else it's very difficult to be better.

But it is wise to think carefully about the things that one really wants
to do differently. In business it makes sense to standardise on as much
as possible, then be different on the key things that really do define
you vs your competition. In Debian's case, I can think of several things
that really define the brand and the values. Supporting more
architectures. Having the most democratic processes. debian-legal. And
many more. None of them depend on having the same, or different base
versions of the major components as any other distro.

There's a great expression that says "if you always do what you always
did, you can only expect to get again what you got before". In other
words, it's always worth thinking about what can be done differently.

>  If we were tied to something or
> someone one way or another, this would not be possible.
>   
Having a cadence and discussion across many distros to try and find
opportunities for common base versions of major components does not tie
anybody. If Debian wants to have a different version of ANY component to
any other distro, of course it can! And if it wants to take 9 months to
bake the release, instead of 6 months, of course it can too. There are
real differences in approach (architectures etc) that will always drive
some delta. It's worth paying the cost of that delta if it helps you be
you. It's not worth having a delta just because nobody bothered to sit
down and talk about it.

>>> Overall, it's been working fine for the last 16 years.
>>>   
>>   
>> A lot has been achieved, yes. Could more be done? Could Debian be
>> stronger? Are there weaknesses that may be addressed? I think it's
>> always worth considering how things can be improved.
>> 
>
> Indeed. And I truly don't see how being tied to and restricted by
> other projects with differing interests can help us there. Quite to
> the contrary.
>   
This proposal does not tie Debian in any way.


>> Well, we believe differently, and that's OK. I think it's easy enough to
>> go and speak to a few upstreams, and ask them this: "what would you do
>> differently if you knew that multiple distributions would all sit down
>> and think about which version of your code to ship with their big 2010
>> release?" I think you'd find most of them say "that would be amazing".
>> 
>
> I don't really care about what they say, I care about how they act
> upon it afterwards. And unfortunately there's no guarantee that
> they'll support us better than they do today. Especially if those
> statements were made without community backing.
>   
There's no guarantee, no. But community members rally to a good,
inspiring, intellectually true vision. You may not get them all, and you
may not get the leader, but you will ensure that on every mailing list
*someone* will be asking the question "what can we do to help those guys
with their noble cause"?

Mark

Re: Debian decides to adopt time-based release freezes

[Aurelien Jarno]

On Wed, Aug 05, 2009 at 09:04:46AM +0100, Steve Langasek wrote:
> I'm not sure whether this subthread is really going anywhere, given that it
> seems to have devolved into a complaint about the handling of a particular
> bug, and playing whack-a-mole on a public mailing list in response to
> individual interactions seems a thoroughly ineffective way to change
> anything about the Debian-Ubuntu relationship at large.  Still, given that I
> have personal knowledge of the bug in question, I can't help but respond...

The bug is actually not a single bug but reflects the cooperation
between Ubuntu and Debian on the eglibc side. It may be different in
some other areas, but it reflect my daily feelings.

> On Tue, Aug 04, 2009 at 11:18:26PM +0200, Pierre Habouzit wrote:
> > On Tue, Aug 04, 2009 at 10:29:11AM +0100, Steve Langasek wrote:
> > > I'm sorry that you have a negative impression of Ubuntu's relationship
> > > with Debian, but there's plenty of data available that contradicts
> > > your conclusion (including BTS reports that have been posted to this
> > > very thread).
> 
> > The problem is there is also plenty of data, like for example the recent
> > #539950 (on a package never uploaded to Debian) which is looking a _lot_
> > like LP#408901. In this bug, the Ubuntu developer is (IMHO) trying to
> > make the Debian one find, fix and patch the bug for him.
> 
> The package has not yet been uploaded to Debian, but the package that was
> uploaded to Ubuntu is based on the Debian repo where eglibc 2.10 is being
> staged for upload.  Why do you conclude that the Ubuntu developer is trying
> to make Debian find and fix the bug?  Do you think that Ubuntu developers
> should only communicate with Debian about bugs they already know the fixes
> for, and that anything else implies that Ubuntu is expecting Debian to fix
> the bug for them?  Is sharing information about known bugs not *also* a
> useful form of collaboration?
>
> Do you think Ubuntu developers should not communicate with Debian developers
> about possible upcoming regressions?  Or are you only arguing that such
> communication should not take place in the BTS?  (I can certainly sympathize
> with the latter, since using non-existent version numbers when filing bugs
> in the BTS is effectively garbage data; I'm just not clear exactly what your
> objection is in this case.)
> 
> Given that this is almost certainly an upstream bug, and a regression vs.
> 2.9, I would think that the Debian maintainers would, in the general case,
> welcome being kept in the loop about such a bug.  If that's not true, how
> should the Ubuntu developers know this?  In this instance, the bug was
> forwarded to Debian by a developer who does a significant proportion of the
> glibc work in Ubuntu, and is not an unknown entity to the Debian glibc
> maintainers.  If the Debian glibc maintainers don't want to receive warning
> about such upcoming issues, or want to receive it by other means, has any
> effort been made to communicate this to Matthias?  (Posting to
> debian-project certainly doesn't count...)  How in the general case is
> Ubuntu developer X supposed to know whether Debian maintainer Y is going to
> welcome being kept apprised of upcoming problems they will face when
> upgrading to a new upstream version, or will instead regard it as a "dirty
> trick"?

In an ideal world seeing such a bug report in the Debian BTS would have
been appreciated. In practice, except a few minor exceptions, the code
always flows from Debian to Ubuntu, so I clearly have some a priori.

I have been personally informed about this bug about 15 minutes after it
has been submitted in the Ubuntu BTS, thanks to IRC. I usually get 
informed about problems on the Ubuntu side that way, and until recently 
I answered or fixed them depending on my *free time*.

In short Ubuntu is doing cosmetic tweaks to the packaging, and Debian is
maintaining the packaging, writing patches, and does most of the
interaction with upstream. Add to that Debian is currently lacking
manpower to follow the rate of the bug reports.

With all those reasons, seeing a bug report from Ubuntu without much 
analysis than in the original bug report really makes me think Ubuntu
wants to see the bug fixed by Debian.

I am pretty fine cooperating with Ubuntu, provided that Ubuntu adds some
manpower to do part of the job.

> > The problem is (as a DD) that I would expect Ubuntu to collaborate the
> > most on the harder core packages, meaning the toolchain, the kernel,
> > X... Alas, it happens more coincidentally than on a regular basis, and
> > that saddens me.
> 
> With the exception of the kernel, where the packaging is more or less a
> complete fork between Debian and Ubuntu, I think all of these components are
> areas where Ubuntu developers collaborate.  Many of the packages are often
> in sync between Debian and Ubuntu (with experimental if not with unstable),
> changes originating with Ubuntu are frequently made available in bo

Re: On cadence and collaboration

[Margarita Manterola]

Hi!

Mark, thanks for the mail and the many things said.  I have basically
one important point that I'd like you to answer.

On Wed, Aug 5, 2009 at 6:21 AM, Mark Shuttleworth wrote:
> To achieve anything together, we'll both need to work together, we'll need
> to make compromises or we'll need to contribute effort to the other side. If
> the Debian community is willing to consider a December freeze, then Ubuntu
> (and Canonical) will commit resources to help Debian meet that goal.

If Debian commits to a December freeze, would that mean that Ubuntu
commits to releasing 10.04 with KDE 4.3 (already released) and GNOME
2.28 (to be released in a few months), instead of KDE 4.4 (to be
released in January) and GNOME 2.30 (to be released in March)?

This has been one of the main concerns of the December freeze, apart
from the fact that we wouldn't meet our release goals, that you are
suggesting how to solve.  Ubuntu has shown in the past a tendency to
ship with the latest versions of software. In the case of GNOME, the
freeze in Ubuntu usually happens before GNOME is even released, and
yet the latest GNOME goes into the release.

So, how would that work in this case?

It is my opinion that freezing after GNOME releases (and gets into
testing) would be better for Debian.  This means either April or
October, depending on which GNOME release we want to ship.

If we think, for real, that December is the best month of the year to
freeze (I definitely don't), then we would need to somehow convince
both GNOME and KDE (and then other upstreams as well) to release in
October/November.  It's not that much of a change for GNOME, but I
don't see this happening this year for KDE.  Maybe next year, if this
is planned well in advance.

But why December? December is a very nasty month to do important
things, people go on holidays, stay away from their computers for one,
two or more weeks.  If anything, I think December is the worst month
to plan for a freeze.

-- 
Besos,
Marga


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Ben Finney]

Julien BLACHE  writes:

> Indeed. And I truly don't see how being tied to and restricted by
> other projects with differing interests can help us there. Quite to
> the contrary.

I take it then that another part of Mark's message you discarded was the
part where he explained the goal is to discover and better advertise
existing opportunities to collaborate, and *not* to have one project
“restricted” by another.

> > Well, we believe differently, and that's OK. I think it's easy
> > enough to go and speak to a few upstreams, and ask them this: "what
> > would you do differently if you knew that multiple distributions
> > would all sit down and think about which version of your code to
> > ship with their big 2010 release?" I think you'd find most of them
> > say "that would be amazing".
> 
> I don't really care about what they say, I care about how they act
> upon it afterwards.

Right. If they gave that answer, I'd be responding “you didn't answer
the question: what would you do differently?”.

-- 
 \   “For of those to whom much is given, much is required.” —John |
  `\F. Kennedy |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On Torvalds' POV towards freedom (Re: On cadence and collaboration)

[Pierre Habouzit]

On Wed, Aug 05, 2009 at 02:12:24PM +0200, Robert Millan wrote:
> 
> Hi Mark,
> 
> Sorry that I don't comment on your proposal, as I'm not really the most
> indicate, except to say I appreciate it, and I hope it's succesful.
> 
> But there's something I'd really like to comment on.
> 
> On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote:
> > I enjoyed
> > Linus Torvalds' recent interview where he talked about prejudice against
> > Microsoft in the Linux community, and how poisonous it is. The same is
> > true of prejudice against Ubuntu here in Debian.
>
> I think you're misscharacterizing Torvalds' statement.
[...]
> which basically amounts to: "If you speak about freedom, you're an extremist
> full of hate".

Nice.

-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

On Torvalds' POV towards freedom (Re: On cadence and collaboration)

[Robert Millan]

Hi Mark,

Sorry that I don't comment on your proposal, as I'm not really the most
indicate, except to say I appreciate it, and I hope it's succesful.

But there's something I'd really like to comment on.

On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote:
> I enjoyed
> Linus Torvalds' recent interview where he talked about prejudice against
> Microsoft in the Linux community, and how poisonous it is. The same is
> true of prejudice against Ubuntu here in Debian.

I think you're misscharacterizing Torvalds' statement.  He said that hatred is
a disease, but that's a generally agreed upon fact, and I don't think it's the
core of his message.  He also said:

  "There are ‘extremists’ in the free software world, but that’s one
   major reason why I don’t call what I do ‘free software’ any more.
   I don’t want to be associated with the people for whom it’s about
   exclusion and hatred."

which basically amounts to: "If you speak about freedom, you're an extremist
full of hate".

Torvalds' message is that of an extremist itself.  In Torvalds' mind, it is
not conceiveable that people care about freedom out of love, and that they
don't hate anyone because of it.

In his narrow view of reality, standing and defending your rights is the same
thing as hating the person who'd take them away from you.

Mark, since you speak about free software yourself, I assume you don't
adhere to this point of view.  I think it would be in your best interest
to watch carefully before subscribing to something this person said.

Thanks

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Julien BLACHE]

Mark Shuttleworth  wrote:

Hi,

> Debian stands out in many respects, yes. But being different for the
> sake of it isn't a laudable goal: if there's a good idea, it deserves to
> be considered, even if others are already considering it.

Being different and independent actually enables us to be better at
what we're doing than anyone else. If we were tied to something or
someone one way or another, this would not be possible.

>> Overall, it's been working fine for the last 16 years.
>   
> A lot has been achieved, yes. Could more be done? Could Debian be
> stronger? Are there weaknesses that may be addressed? I think it's
> always worth considering how things can be improved.

Indeed. And I truly don't see how being tied to and restricted by
other projects with differing interests can help us there. Quite to
the contrary.

> Well, we believe differently, and that's OK. I think it's easy enough to
> go and speak to a few upstreams, and ask them this: "what would you do
> differently if you knew that multiple distributions would all sit down
> and think about which version of your code to ship with their big 2010
> release?" I think you'd find most of them say "that would be amazing".

I don't really care about what they say, I care about how they act
upon it afterwards. And unfortunately there's no guarantee that
they'll support us better than they do today. Especially if those
statements were made without community backing.

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On cadence and collaboration

[Mark Shuttleworth]

Julien BLACHE wrote:
> [Cc:ed as I don't know whether you're subscribed to -project]
>   
I am subscribed, yes, but thanks for the cc.

> From the very start of the Debian Project, Debian has been different
> from everything else: different package management tools, different
> philosophy, different organization, you name it.
>   
Debian stands out in many respects, yes. But being different for the
sake of it isn't a laudable goal: if there's a good idea, it deserves to
be considered, even if others are already considering it.

> Overall, it's been working fine for the last 16 years.
>   
A lot has been achieved, yes. Could more be done? Could Debian be
stronger? Are there weaknesses that may be addressed? I think it's
always worth considering how things can be improved.
> What do you think the changes you are proposing can gain us?
>
> I don't believe in the "upstreams will care" stuff (there are good
> examples of upstreams not giving a damn about distributors over the
> past months) and I don't believe in the 100% end-user-centric focus
> you're displaying in your mail.
>   
Well, we believe differently, and that's OK. I think it's easy enough to
go and speak to a few upstreams, and ask them this: "what would you do
differently if you knew that multiple distributions would all sit down
and think about which version of your code to ship with their big 2010
release?" I think you'd find most of them say "that would be amazing".

> Once I've removed that from your mail, and the "but Ubuntu loves you!"
> stuff, there's nothing left.
>   

Mark

Re: On cadence and collaboration

[Marc Haber]

Mark,

this is kind of a personal reply; I am therefore writing this to you
directly and only Cc'ing debian-project, and I do not know whether you
read that mailing list.

On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote:
> 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,

A pity. I bet many people would like to hear that response.

> I hear this story all the time from upstreams. "We'd like to help
> distributions, but WHICH distribution should we pick?"

I have never heard that story from an upstream, neither have I heard
that other maintainers have heard that. Especially not from the
upstream who consider themselves big and powerful.

> 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.

It will also cost the free software ecosystem a lot of what's one of
its most major properties: diversity.

>  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... which in turn makes it easier for
>  the security teams and maintainers in the distribution.

In practice, most upstreams adopt a "you're using a version that's two
weeks old, go update to our current development snapshot and see
yourself whether the bug is still there" attitude.

> Well, the first thing is to agree on the idea of a predictable cadence.
> 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 :-)

Most upset that happened on the lists and in real life was about that
Debian learned about your collaboration from a Debian press release.

> As pointed out on this list, Debian and Ubuntu share a great deal.

I wouldn't call that "share".

>  We have largely common package names (imagine what a difference that
>  will make to practical discussions over IRC ;-))

Right, this makes it much easier for Ubuntu users to pester Debian
people with the problems that the Ubuntu community wasn't able to
solve by itself.

>  (most of the strongest Ubuntu
>  contributors are or have been very strong Debian contributors too,

yes, and have usually stopped doing their debian duties without
properly stepping down upon their engagement with Ubuntu. This has
greatly harmed Debian a few years ago when Ubuntu was still hatching,
and has obviously also helped Ubuntu in getting more momentum than
Debian since Ubuntu took privileges from Debian which slowed down
Debian a great deal.

>  and many new Debian maintainers have come to the project through
>  Ubuntu)

Yes. Ubuntu should think about the reason for Ubuntu people changing
over to Debian.

> . When I look over the commentary on debian-devel and in debbugs and
> on #debian-devel, I see a lot of familiar names from Ubuntu,
> especially on the deep, hard problems that need solving at the core.

>From new people that weren't hired over to Ubuntu from Debian?

> So, practically, we would be in a good position to collaborate.

Of course. Ubuntu _is_ Debian in a very big part.

> I see mails
> on this list saying it would be easier and better for Debian to
> coordinate with distributions that I think would be almost *impossible*
> to work with practically,

It is almost impossible to work with Ubuntu as soon as one doesn't agree.

> How do I think it could work in practice? Well, if Debian and Ubuntu
> went ahead with the summit in December, where we reviewed plans for 2010
> and identified opportunities to collaborate, I think we would get (a)
> several other smaller distributions to participate, and (b) several
> upstreams to participate.

You're a true visionary.

> A December summit is not about tying anybody's hands. It's about looking
> for opportunities, where they exist naturally, and communicating those
> more widely.

At least Debian has epically failed in "wide communication" of this
decision by first putting out a press release before informing the
community itself.

> First, there has been no secret cabal or skunkworks effort to influence
> Debian.

Not?

>  As best I can tell, folks from both Debian and Ubuntu who have deep
>  insight into release management established a shared interest in
>  working together better, at many levels, and this was one idea that
>  came forward. The fact that those discussions were open and ongoing
>

Re: On cadence and collaboration

[Julien BLACHE]

Mark Shuttleworth  wrote:

[Cc:ed as I don't know whether you're subscribed to -project]

Hi,

> freeze summit, and there are significant benefits to Debian to being
> part of that rather than on a different schedule.

>From the very start of the Debian Project, Debian has been different
from everything else: different package management tools, different
philosophy, different organization, you name it.

Overall, it's been working fine for the last 16 years.

What do you think the changes you are proposing can gain us?

I don't believe in the "upstreams will care" stuff (there are good
examples of upstreams not giving a damn about distributors over the
past months) and I don't believe in the 100% end-user-centric focus
you're displaying in your mail.

Once I've removed that from your mail, and the "but Ubuntu loves you!"
stuff, there's nothing left.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

On cadence and collaboration

[Mark Shuttleworth]

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!

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 - your
code will land in most users hands through one or other distribution -
maybe RHEL, maybe Fedora, maybe Debian or Ubuntu or Gentoo. And you can
maintain a few personal relationships with distribution-space that help
to straighten things out, but more often than not, users will get your
code from a distribution with whom you have little contact. To make
things worse, at any given time, different distributions may be shipping
wildly different versions of your code. That makes all the bug reports
harder to evaluate, and all the patches harder to apply. It also makes
it harder to know where to commit precious resources to stable version
maintenance.

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.

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... which in turn makes it
easier for the security teams and maintainers in the distribution.

We're already seeing a growing trend towards cadence in free software,
which I think is a wonderful move. Here, we are talking about elevating
that to something that the world has never seen in proprietary software
(and never will) - an entire industry collaborating. Collaboration is
the primary tool we have in our battle with proprietary software, we
should take the opportunities that present themselves to make that
collaboration easier and more effective.

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?

Well, the first thing is to agree on the idea of a predictable cadence.
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 :-)

The second thing is to find the opportunities that are most likely to be
successful. That depends as much on psychology and practical interaction
as anything else.

As pointed out on this list, Debian and Ubuntu share a great deal. We
have largely common package names (imagine what a difference that will
make to practical discussions over IRC ;-)) and we have established
relationships between folks who care about most of the major components
already. We have lots of people with shared experience in both projects
(most of the strongest Ubuntu contributors are or have been very strong
Debian contributors too, and many new Debian maintainers have come to
the project through Ubuntu). When I look over the commentary on
debian-devel and in debbugs and on #debian-devel, I see a lot of
familiar names from Ubuntu, especially on the deep, hard problems that
need solving at the core. I'm proud of that.

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? Or how neighboring countries that share
the same food, the same dress, the same values, can often be the
bitterest feuds? Some days I think that applies between us. I see mails
on this list saying it would be easier and better for Debian to
coordinate with distributions that I think would be almost *impossible*
to work with practically, but somehow they are more attractive because
they are not family. Perhaps we know each other too well. It's hard to
be a prophet in your home town.

How do I think it could work in practice? Well, if Debian and Ubuntu
went ahead with the summit in December, where we reviewed plans for 2010
and identified opportunities to collaborate, I think we would get (a

Re: Debian decides to adopt time-based release freezes

[Steve Langasek]

On Tue, Aug 04, 2009 at 11:49:09AM -0500, Manoj Srivastava wrote:
> Perhaps Ubuntu should correct it's web page, then, in light of
>  the apparent fact that automatic feeding of patches upstream is
>  not in fact reality?

Yes, I've forwarded this bug to the attention of the Ubuntu webmaster.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Steve Langasek]

I'm not sure whether this subthread is really going anywhere, given that it
seems to have devolved into a complaint about the handling of a particular
bug, and playing whack-a-mole on a public mailing list in response to
individual interactions seems a thoroughly ineffective way to change
anything about the Debian-Ubuntu relationship at large.  Still, given that I
have personal knowledge of the bug in question, I can't help but respond...

On Tue, Aug 04, 2009 at 11:18:26PM +0200, Pierre Habouzit wrote:
> On Tue, Aug 04, 2009 at 10:29:11AM +0100, Steve Langasek wrote:
> > I'm sorry that you have a negative impression of Ubuntu's relationship
> > with Debian, but there's plenty of data available that contradicts
> > your conclusion (including BTS reports that have been posted to this
> > very thread).

> The problem is there is also plenty of data, like for example the recent
> #539950 (on a package never uploaded to Debian) which is looking a _lot_
> like LP#408901. In this bug, the Ubuntu developer is (IMHO) trying to
> make the Debian one find, fix and patch the bug for him.

The package has not yet been uploaded to Debian, but the package that was
uploaded to Ubuntu is based on the Debian repo where eglibc 2.10 is being
staged for upload.  Why do you conclude that the Ubuntu developer is trying
to make Debian find and fix the bug?  Do you think that Ubuntu developers
should only communicate with Debian about bugs they already know the fixes
for, and that anything else implies that Ubuntu is expecting Debian to fix
the bug for them?  Is sharing information about known bugs not *also* a
useful form of collaboration?

Do you think Ubuntu developers should not communicate with Debian developers
about possible upcoming regressions?  Or are you only arguing that such
communication should not take place in the BTS?  (I can certainly sympathize
with the latter, since using non-existent version numbers when filing bugs
in the BTS is effectively garbage data; I'm just not clear exactly what your
objection is in this case.)

Given that this is almost certainly an upstream bug, and a regression vs.
2.9, I would think that the Debian maintainers would, in the general case,
welcome being kept in the loop about such a bug.  If that's not true, how
should the Ubuntu developers know this?  In this instance, the bug was
forwarded to Debian by a developer who does a significant proportion of the
glibc work in Ubuntu, and is not an unknown entity to the Debian glibc
maintainers.  If the Debian glibc maintainers don't want to receive warning
about such upcoming issues, or want to receive it by other means, has any
effort been made to communicate this to Matthias?  (Posting to
debian-project certainly doesn't count...)  How in the general case is
Ubuntu developer X supposed to know whether Debian maintainer Y is going to
welcome being kept apprised of upcoming problems they will face when
upgrading to a new upstream version, or will instead regard it as a "dirty
trick"?

> The problem is (as a DD) that I would expect Ubuntu to collaborate the
> most on the harder core packages, meaning the toolchain, the kernel,
> X... Alas, it happens more coincidentally than on a regular basis, and
> that saddens me.

With the exception of the kernel, where the packaging is more or less a
complete fork between Debian and Ubuntu, I think all of these components are
areas where Ubuntu developers collaborate.  Many of the packages are often
in sync between Debian and Ubuntu (with experimental if not with unstable),
changes originating with Ubuntu are frequently made available in both Debian
and Ubuntu simultaneously when feasible, and when not, the changes are still
(IME) published to Debian ASAP when they make sense in a Debian context.

Now perhaps what you mean isn't that you expect Ubuntu to collaborate
better, but that you expect Ubuntu /to do more of the work/.  That's a
different question, and not one that can be solved at the level of
individual developers - the Ubuntu developer community is much smaller than
the Debian developer community, and if the work output from Ubuntu doesn't
meet your expectations, it's not because Ubuntu developers are sitting idle
waiting for Debian to do all the work.

Given that there is a (healthy) process of Ubuntu contributors continually
being integrated into Debian, I don't think anyone wanting "Ubuntu" to carry
significantly more of the Debian development work is ever going to be
satisfied.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: info on debian packaging and installer

[Tapio Lehtonen]

On Wed, Aug 05, 2009 at 09:54:30AM +0530, Vinoth vijaybabu wrote:
> Hi,
> I am vinoth, and i am trying do a project called packaging and installer,
> and i want create my own debian packaging and installer. Can you help to do
> this.
> -- 
> V.Vinoth Vijaybabu

This mailing list, debian-project, is for "Discussion about
non-technical topics related to the Debian Project.". Try contacting
the following mailing list and getting the manuals: 

Debian installer developers have their own mailing list,
http://lists.debian.org/debian-boot/

Debian packaging:
http://www.debian.org/doc/maint-guide/

-- 
Tapio Lehtonen
tapio.lehto...@iki.fi
http://www.iki.fi/tapio.lehtonen


signature.asc
Description: Digital signature