Re: On cadence and collaboration

[martin f krafft]

also sprach Andre Felipe Machado  
[2009.08.17.1457 +0200]:
> Please, forgive my limited english language skill. I hope clarify
> the subject a bit more. By no means I intended to discount Debian
> contributors, but to ADD more skilled people from the Canonical
> team to Debian efforts.

I think the problem was not your English, but my perception error.
Thanks for clarifying. I now agree.

-- 
 .''`.   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 women become like their mothers. that is their tragedy. no man
 does. that's his."
-- oscar wilde


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

Re: On cadence and collaboration

[Andre Felipe Machado]

Hello,
Please, forgive my limited english language skill. I hope clarify the subject a
bit more.
By no means I intended to discount Debian contributors, but to ADD more skilled
people from the Canonical team to Debian efforts.
There is (still) a limited supply of skilled people around the world on FOSS,
and grouping more of them at same tasks will (likely) improve results and reduce
individual efforts, and time to accomplish things.
Canonical has its own view of what should be a distribution, and (likely) will
keep its way of distro shape, but some convergent efforts for mutual benefit
could be reached.

The proposal is not an "all or nothing" approach. It is a fully adjustable one.
>From one package to entire repository.

Trying small number of relevant packages at first round, and carefully
evaluating efforts and commitment, and adjusting workflow until a working one
could be agreed, could get good results with minimal risk for both projects.
Some Debian Teams will not take part of the experiment because they have release
goals unfeasible at such reduced time frame (even with more 3 months).
Also, the releases will not be equal, because many packages will not be part of
the experiment, and , say, number of acceptable release RC bugs for each project
are different. But releasing same base versions (at least) will ease
collaborative patching after freeze AND after respective releases.
Continuous evaluation and adjustment are key factors for the future of the
"cadence and collaboration". Commitment of both sides to accomplish results for
MUTUAL benefit in the long run (even without knowing how to do this with details
at starting, so the adjustments and small group of packages) is important. Any
action perceived as a "trick" would be seriously detrimental. Clear directions
and collective planning at mailing list (a new dedicated one, maybe utnubu [0]),
mutual "good will" at this experiment and "benefit of doubt: ask details before
reaction" in case of any attrition will help.
Regards.
Andre Felipe Machado

[0] http://lists.alioth.debian.org/mailman/listinfo/utnubu-discuss


> I wouldn't go as far as speaking of "more skilled contributions", as
> that would discount quite a lot of Debian contributors, but there
> are certainly opportunities in this for us.
> 

Re: On cadence and collaboration

[Tshepang Lekhonkhobe]

2009/8/16 Andre Felipe Machado :
> - Given that Debian Project has around 2000 commited devs and

last I checked, that number was about 400 DD's who were actually active

> [0] ([Off Topic and not deserving answer as it is an unqualified
> suggestion]: Maybe, Canonical could be improve margins if Ubuntu
> becomes, ACTUALLY, a debian pure blend, differentiating itself with
> package preconfigurations (preseed) and package sets, and even release
> dates because pure-blends could release "cuts" of sid or testing,
> afaik). Maintaining a distro alone is a costly proposition. But it may
> not be feasible anymore. Maybe, with improving working collaboration,
> Ubuntu could come back to be _fully_ Debian source code progressively.)

Now the CUT thing is actually something exciting, hard-to-do as it is.


-- 
my place on the web:
floss-and-misc.blogspot.com


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

[martin f krafft]

also sprach Andre Felipe Machado  
[2009.08.16.1915 +0200]:
> After this first round trip, the whole process would be evaluated and
> adjusted. Maybe cancelled or broadned. But without trying with a small
> group of highly user visible packages, we will not know.

I agree very much with your proposed suggestion: before Debian can
commit/agree to any "cadence", we need to get a trial of the
benefits for us, if we are to deviate from the way we (used to) do
things: resources to get our release into shape, and resources to
maintain our software post-release. 

> Mr. Shuttleworth is a business man and will likely perceive the
> value proposition and benefits for Canonical business model in the
> long run, despite requiring some more commitment of resources
> ahead and after release, but limited to a small group of key
> packages that causes lots of bug reports and or binary
> incompatibilities during release life cycle. Not having to deal
> alone with these versions' bugs will reduce Canonical costs. And
> neither Debian alone. [0] 

Exactly. His suggestion bears benefits for Canonical, but in the
business world, return follows investment, not the other way.

> At Debian Project side, there could be benefits of more skilled
> contributions and BTS reports and patches, with consolidated
> collaboration even synergetic in future, and predictable work
> oportunity windows for Teams. Plans could be articulated with more
> teams.

I wouldn't go as far as speaking of "more skilled contributions", as
that would discount quite a lot of Debian contributors, but there
are certainly opportunities in this for us.

-- 
 .''`.   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
 
"one should never trust a woman who tells her real age.
 if she tells that, she will tell anything."
-- oscar wilde


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

Re: On cadence and collaboration

[Andre Felipe Machado]

Hello,
Having read all thread, and letting some time to calm down the subject,
I would like to suggest a few points, presuming that synchronizing could
be done in a way in benefit of both projects. (please, forgive my poor
english skill, if you have doubts, please ask for detailment).

- Given that Debian Project has around 2000 commited devs and
contributors, and Ubuntu around 156 (please, correct and update all
numbers), and that Canonical has resources to commit deadlines for some
tasks, Canonical needs Debian for its business model and Debian wants
skilled commited devs and contributors and useful larger user base bug
reports (and patches) for same versions.
- Given that Debian has more than 25000 packages and Ubuntu LTS server
around 800 and desktop around 2000 (please, correct and update numbers),
a "basic" synchronization could be tried.
- Maybe, as already suggested, the first try could has a 3 month delay
to be feasible.
- Maybe, the first try could be version sync for a small (or even *very
small*) group of high profile "user visible" packages that also cause
large number of bug reports and or (binary?) package compatibility
problems (Ex.: kernel, gcc, postgresql, mysql, apache, php, gnome and or
kde, etc).
- For such an agreed small group of packages, Debian Project could list
teams needing help to accomplish deadlines and Canonical could commit
*enough  resources* to help these teams meet freeze deadlines.
- The work would be performed at Debian infrastructure (the "upstream")
not Launchpad, and compliant with Debian quality procedures and
criteria.
- The commitment and quality of Canonical efforts and resources
contributions could be evaluated for future steps to a broad
collaboration.
- All efforts should be directed to diverge the respective distro
patches for the agreed set of packages to an actual minimum, ideally,
zero code difference. Kernel could be a special case, but having the
*same upstream version as base* will be a good thing.
- After the version freeze period, the release date would be each
project decision. But versions would be definitive (at least until some
tragic RC bug is found) for the package subset agreed.
- The respective release dates will be different, given the different
requirements and pre-conditions (more platforms, # of acceptable RC
bugs, different number of packages released, etc ).

- Canonical *WILL* release Ubuntu LTS server and LTS desktop with such
agreed group of package *versions*. Period.

- After the freeze and continuing after release, Canonical will commit
the resources for help cleaning the bugs, and keeping security, that get
into BTS and forward relevant Launchpad reports - and patches- to BTS as
soon as possible.
- Again, the commitment and quality of Canonical efforts and resources
contributions at this phase could be evaluated for future steps to a
broad collaboration.

After this first round trip, the whole process would be evaluated and
adjusted. Maybe cancelled or broadned. But without trying with a small
group of highly user visible packages, we will not know.

Mr. Shuttleworth is a business man and will likely perceive the value
proposition and benefits for Canonical business model in the long run,
despite requiring some more commitment of resources ahead and after
release, but limited to a small group of key packages that causes lots
of bug reports and or binary incompatibilities during release life
cycle. Not having to deal alone with these versions' bugs will reduce
Canonical costs. And neither Debian alone. [0] 

At Debian Project side, there could be benefits of more skilled
contributions and BTS reports and patches, with consolidated
collaboration even synergetic in future, and predictable work oportunity
windows for Teams. Plans could be articulated with more teams.


Starting with a small group of key packages has chance to succeed and
will not have too much risk for both projects.
Both projects will have to concede "some" next release goals to reduce
scope and needed work. Maybe some Debian release goal could be
accomplished in a longer time frime but involved packages will NOT be
part of the small group of agreed packages for FREEZE date.
Thus, Debian will release with such planned goal, but the involved
packages will not be the same of Ubuntu LTS, not being part of the
agreed group, but without much fuss because respective Teams were not
commited to release without such goal.

Improvements and corrections for these suggestions are welcome.
Regards.
Andre Felipe Machado














[0] ([Off Topic and not deserving answer as it is an unqualified
suggestion]: Maybe, Canonical could be improve margins if Ubuntu
becomes, ACTUALLY, a debian pure blend, differentiating itself with
package preconfigurations (preseed) and package sets, and even release
dates because pure-blends could release "cuts" of sid or testing,
afaik). Maintaining a distro alone is a costly proposition. But it may
not be feasible anymore. Maybe, with improving w

Re: On cadence and collaboration

[Gunnar Wolf]

Vipin Mathew dijo [Thu, Aug 13, 2009 at 08:24:21AM -0700]:
> mozilla has shown how we can build something which is in every way
> better than the closed ones by effective collaboration. if we all
> come together we could create another great brand called linux. n we
> can win. a win for all the community. just think what we would be
> able to achieve if all the developers in various distros came
> together.

[OT] Some people (me not included, I refuse to even try it) will point
out that it has beaten the pants out of MSIE, but propietary browsers
such as Opera or Safari are way ahead. There was a (short) thread
recently on d-devel where even some Debian Developers (of course,
everybody is free to use what they prefer!) say they prefer Opera over
any Mozilla derivative.

But anyway, please don't reply to this, it is not needed. Just raising
the point that Mozilla might not be the best example after all. And
don't get me started on OpenOffice! ;-)

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

[Vipin Mathew]

I admit that i m no developer who has a strong word in a debate. i m just an 
average joe end user who just wish that opensource software becomes better. if 
opensource wins, it would be a win for the community. an evidence that even in 
this world filled with walls, men can still cooperate breaking all barriers to 
create something which rivals even the closed n boxed ones.

mozilla has  shown how we can build something which is in every way better than 
the closed ones by effective collaboration. if we all come together we could 
create another great brand called linux. n we can win. a win for all the 
community. just think what we would be able to achieve if all the developers in 
various distros came together. 

i really really wish that all will come together to collaborate setting aside 
all the differences. n i really wish  to see a better world. n thank u mark for 
taking this initiative..



  Yahoo! recommends that you upgrade to the new and safer Internet Explorer 
8. http://downloads.yahoo.com/in/internetexplorer/

Re: On cadence and collaboration

[Mark Shuttleworth]

Gunnar Wolf wrote:
> Of course, many upstreams will not accept this, as it breaks their
> workflow and might just feel outside influence from people they don't
> care too much about (and I'm not meaning the Linux desktops, as they
> obviously care about Linux distributions, but mainly OS-agnostic
> projects). Still, I think it would be worth a try.
>   
This is a good point. We do already see lots of upstreams moving to a
cadence, which is improving their release energy and practices. There is
*some* alignment between various upstreams, but at this stage it will
take getting two or more distributions together in order to create a
real center of gravity.

Mark

Re: On cadence and collaboration

[Manoj Srivastava]

On Wed, Aug 12 2009, Gunnar Wolf wrote:

> Manoj Srivastava dijo [Wed, Aug 05, 2009 at 10:08:13AM -0500]:
>> 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. 
>
> Umm... But the time from freeze until release is so far not
> predictable at all. Etch was way swifter than Lenny (or FFS than
> Sarge). They were all intended to be frozen for much less time than
> they ended up being. So… Freezing every 24 months (I won't even make a
> pun on your 24 years) can push us over the edge. Yes, I understand
> that this means the 24 months include the freeze time for the previous
> release. Still.


In the time line below, I am considering freeze of the toolchain
 and base (d-i) as the start of the freeze, since we have not yet done
 that for Squeeze). These are culled from the d-d-a archive, looking for
 the mail announcing thte tool chain freeze.

 sarge:   2004/08 - 2005/06 (10) (freeze in stages)
 etch:2006/08 - 2007/04 (5) 24 months between freezes, 22 for release
 lenny:   2008/07 - 2009/02 (7) 21 months between freezes, 22 for release
 squeeze: 2010/?? -

This is different from the time line AJ posted, since I am
 counting from the time we froze toolchain/base packages, since as far
 as I know the tool chain freeze date has not been announced.

So it seems to me that we have pretty much stable interfreeze
 and ihnter-release cycles, and which is why I think we can manage to
 sustain 2 year release cycles.

manoj
-- 
You will lose an important disk file.
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

[Gunnar Wolf]

Hi,

No, not quoting a bit. And answering to the top of the thread. Over a
week old, also. And even more, not having read a majority of the
replies. Still.

Mark, I think you are personally among the best positioned people to
be heard on this topic - And your goal is quite worthy. However, I
think pushing the distributions to freeze semi-coordinatedly (as much
coordinatedly as possible) is not the best way. As you have witnessed
with Debian, some people will grill you at full flame. RH didn't pay
much attention.

I'd suggest you to try approaching from the other side, although it
will surely prove a very hard path as well: If we say now, «All
distributions should freeze in December», many groups in each will cry
because it breaks their plans. Because their upstreams are working
full-steam (and are either at the most unstable point in their release
cycle or because they are in mid-freeze). 

I have been bitten by this before (i.e. by the not-precisely-2.0
mod_perl that was shipped in Sarge, breaking source compatibility with
any other mod_perl in the face of Earth, which in turn made me
miserable when having a development machine running Sid), and will
quite probably be bitten again (i.e. the Ruby interpreter crew worked
on and announced how their upstream version management scheme will be
handled, and we will probably soon have to rush on a binary package
recreation/renaming frenzy soon). Some things will/would be probably
left out (i.e. the "officially useful" Perl 6.0 release).

Anyway - I think that a key for having distributions agree to a
coordinated freeze is to have upstream development also feel and
adhere to this cadence. If upstreams try to stabilize towards
mid-even-years (i.e. July 2009, July 2011, …), we distributors will
have a much easier time integrating them. And your idea will have a
much better shot at being accepted.

Of course, many upstreams will not accept this, as it breaks their
workflow and might just feel outside influence from people they don't
care too much about (and I'm not meaning the Linux desktops, as they
obviously care about Linux distributions, but mainly OS-agnostic
projects). Still, I think it would be worth a try.

Greetings,

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


pgpIHVAx41dUr.pgp
Description: PGP signature

Re: On cadence and collaboration

[Gunnar Wolf]

Manoj Srivastava dijo [Wed, Aug 05, 2009 at 10:08:13AM -0500]:
> 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. 

Umm... But the time from freeze until release is so far not
predictable at all. Etch was way swifter than Lenny (or FFS than
Sarge). They were all intended to be frozen for much less time than
they ended up being. So… Freezing every 24 months (I won't even make a
pun on your 24 years) can push us over the edge. Yes, I understand
that this means the 24 months include the freeze time for the previous
release. Still.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


-- 
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 mardi 11 août 2009 à 02:48 +0300, Martin-Éric Racine a écrit :
> > 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.
> 
> I think that this point truly deserves to be discussed for a number of 
> reasons.
> 
> Personally, I think that releasing a new distribution right after
> GNOME or KDE has produced a new major version is an extremely bad
> idea, because the X.XX.0 release of anything tends to have too many
> rough edges (feature regressions, out of sync translations, etc.) that
> usually need further polishing via X.XX.1 and X.XX.2 releases before a
> new major desktop release becomes truly usable by non-technical people
> i.e. not requiring any workaround for some stupid regression that gets
> fixed later in point releases, much after the initial distribution
> release has started shipping with X.XX.0.

Which is precisely why, during freezes, the release team lets migrate
minor releases for GNOME packages, based on the strict policies upstream
adopts during stable cycles.

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

[Martin-Éric Racine]

On Wed, 5 Aug 2009 10:26:07 -0300, Marga wrote:
> 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.
>
> 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.

I think that this point truly deserves to be discussed for a number of reasons.

Personally, I think that releasing a new distribution right after
GNOME or KDE has produced a new major version is an extremely bad
idea, because the X.XX.0 release of anything tends to have too many
rough edges (feature regressions, out of sync translations, etc.) that
usually need further polishing via X.XX.1 and X.XX.2 releases before a
new major desktop release becomes truly usable by non-technical people
i.e. not requiring any workaround for some stupid regression that gets
fixed later in point releases, much after the initial distribution
release has started shipping with X.XX.0.

As such, I'd prefer if whatever common freeze for core packages that
is agreed between Debian and its derivatives (Ubuntu and others) only
happened after the next X.XX.2 versions of GNOME and KDE have been
released. This will of course require GNOME and KDE to sync their
clocks as well and my understanding is that recent Guadecs and
aKademies have seen the two communities visiting each other and
working towards this goal, which is very good news indeed. Some people
might also find ensuring that XFCE and LXDE are also kept in the loop
is desirable too and, if that's the case, it would be desirable to
help them achieve this goal as well.

I think that the fact we're having this discussion and are taking
concrete actions towards achieving cadence is a step in the right
direction. I'd however humbly hope that distributions would be as
willing to accommodate upstream cycles as they hope to see upstream
accommodate distribution cycles. Both sides will have to give some
slack and agree to shift their release cycles by a couple of months
and meet half-way, for this cadencing idea to work. One simply cannot
expect upstream to magically jump just because one or two major
distributions reached a consensus. The same way that Mark suggested
Ubuntu lending resources to help Debian reach the target freeze on
time, resources will need to be lent to upstream to reach the same
target date on time.

Best Regards,
Martin-Éric


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

[Paul Wise]

On Thu, Aug 6, 2009 at 10:25 PM, Matthias Andree wrote:

>  i.   if you can't deal with a bug, tell somebody who can. Leaving it to rot
>       is going to drive users away.

Leaving bugs to rot happens everywhere, in various upstreams, in
Debian, Ubuntu, Fedora and probably other distributions. There just
are not enough free software developers in existence to perform all of
the needed maintenance on each and every free software project in
existence.

>  ii.  make package owners explicit. Just assigning package responsibilities 
> for
>       all packages to some opaque mailing list evidently does not work. The
>       list gets my upstream maintainer updates to the bug, yet nobody cares.

IIRC Ubuntu universe specifically works the opposite way and I'm
unsure if Ubuntu have enough universe developers to change this.

> I'm not going to ferret up all possible downstreams.

One tool that makes that easier is 'whohas':

http://www.philippwesche.org/200811/whohas/intro.html

I've personally used it with both upstream and Debian hats on and was
very happy to find that it exists.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bernd Zeimetz  writes:

> As long as it is (partly?) based on the fact that bugs will be fixed by
> Debian for free so Ubuntu can just reuse the bugfixes and get the money
> for them, I think it should be discussed.

People keep saying things like this, but no one I know who's running
Ubuntu is paying for it.  Clearly Canonical does have a business model and
is charging for some things, but are they making money off of *our bug
fixes*?  That's not clear to me at all.  Personally, I view Ubuntu users
as just a larger audience for the same packages I'm making for Debian.  If
something specific to Ubuntu breaks a package, well, Ubuntu gets to keep
both pieces unless it's fairly obvious to me what's wrong.  But insofar as
those users find problems that affect the package in general, it's just
more input to make it better for everyone.

(Also, separately, I came to terms with people making money off of my work
without necessarily giving anything back a long time ago.  I think that's
just part of free software.)

> There is nothing bad in general with that as long as Ubuntu gives their
> bugfixes back to Debian and we don't have to retrieve them out of a mess
> of Ubuntu patches...

This can be a major problem for some packages, but I have to say, I think
that's way overstated for most things.  For example, I've never had much
trouble extracting relevant fixes from Ubuntu patches for my packages.

-- 
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: The Python mess in Debian (was: Re: On cadence and collaboration)

[Philipp Kern]

On 2009-08-08, Bernd Zeimetz  wrote:
> Wrong. Several people tried to contact Matthias on various ways and never got 
> a
> reply. He also completely failed to communicate with those people who maintain
> most Python related packages on Debian, except during Debconf. This is *NOT* 
> the
> way how Python should be maintained. Actually several people already thought
> abut hijacking Python due to the complete lack of communication with the 
> Python
> Maintainer, who prefers to force his changes on people instead of finding an
> acceptable resolution. While I think that large parts of this are the result 
> of
> him being overworked due to Ubuntu stuff, this is not the way how things 
> should
> go. During Debconf [1] came up, but I can't see it happen soon as there are
> *way* too many problems with the proposal, and it would bring us back to
> pre-Etch areas..
> There were rumours that Python 2.6 was not uploaded to unstable due to bugs or
> missing things in python-support, but as usual there was no bug filed, and
> nobody talked to the python-support maintainer.

I think there were at least two things (I think not check them, but from memory
what Matthias told me):

 * python-support breaks upstream assumptions about relative imports.
 * python-support does not always have stable symlink handling, i.e. they
   should maybe be shipped by the package instead.  (I'm relatively unsure
   about this though, as I don't recall the program; but I think it also
   has to do with the fact that you sometimes need to call update-python-
   modules from maintainer script.)

It might be true however that most of the issues he has left did not manifest
themselves in bug reports, probably because the personal relationship of the
two maintainers misses some trust and needs a neutral party to communicate it.

Matthias also stated during UDS that he wouldn't mind python-central to be
dropped when some remaining issues in python-support are fixed (at the very
least the first point above).  I don't know if Debconf changed something
in this regard.

Anyway I don't know how responsive he is wrt emails.  I can understand that
the hostility on d-python didn't help in that regard, but maybe To'ing or
Cc'ing him on some mails might help.

Kind regards,
Philipp Kern



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

The Python mess in Debian (was: Re: On cadence and collaboration)

[Bernd Zeimetz]

To come back to Debian

Luk Claes wrote:
> Hmm, AFAICT python2.6 did not really happen in Debian yet because
> Mathias is trying to not continue with the existing hacks that have
> major issues when upgrading and wants to have a clean solution.

The only hack is the broken piece of python-central and Matthias not being able
to accept that somebody else is able to provide a well working solution without
a ton of hacks which makes it a pain in the ass to migrate away from it. We now
have a *lot* of packages with extra maintainer scripts which take care of
cleaning up behind python-central. That's not the way ho things should work.

> AFAICS
> that was already communicated in February [0] and was only really acted
> on around DebConf [1].

Wrong. Several people tried to contact Matthias on various ways and never got a
reply. He also completely failed to communicate with those people who maintain
most Python related packages on Debian, except during Debconf. This is *NOT* the
way how Python should be maintained. Actually several people already thought
abut hijacking Python due to the complete lack of communication with the Python
Maintainer, who prefers to force his changes on people instead of finding an
acceptable resolution. While I think that large parts of this are the result of
him being overworked due to Ubuntu stuff, this is not the way how things should
go. During Debconf [1] came up, but I can't see it happen soon as there are
*way* too many problems with the proposal, and it would bring us back to
pre-Etch areas..
There were rumours that Python 2.6 was not uploaded to unstable due to bugs or
missing things in python-support, but as usual there was no bug filed, and
nobody talked to the python-support maintainer.

> You can blame everyone involved, but I think it
> might be better to cooperate on fixing it instead.

Don't even think about blaming me for not trying to cooperate on Python related
things if you have no damn clue.


> [0] http://lists.debian.org/debian-devel/2009/02/msg00431.html
> [1] http://lists.debian.org/debian-python/2009/08/msg3.html


Cheers,

Bernd

-- 
 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 cadence and collaboration

[Bernd Zeimetz]

Luk Claes wrote:
> Bernd Zeimetz wrote:
>> Sandro Tosi wrote:
>>
>>> what can happen is that he prepare a rough solution, sent to debian in
>>> a sense "hey, take it, I've done my work, it's an ugly hack but I have
>>> no time to prepare an elegant solution; Now I got to go, I have
>>> another 1000 things to do". I'm not sure it will happen, but I fear it
>>> would.
>> That happens already. See the Python 2.6 migration for a lot of bad 
>> examples...
> 
> Hmm, AFAICT python2.6 did not really happen in Debian yet because

I'm not talking about Debian, but about the Python 2.6 transition in Ubuntu.


-- 
 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 cadence and collaboration

[Luk Claes]

Bernd Zeimetz wrote:
> Sandro Tosi wrote:
> 
>> what can happen is that he prepare a rough solution, sent to debian in
>> a sense "hey, take it, I've done my work, it's an ugly hack but I have
>> no time to prepare an elegant solution; Now I got to go, I have
>> another 1000 things to do". I'm not sure it will happen, but I fear it
>> would.
> 
> That happens already. See the Python 2.6 migration for a lot of bad 
> examples...

Hmm, AFAICT python2.6 did not really happen in Debian yet because
Mathias is trying to not continue with the existing hacks that have
major issues when upgrading and wants to have a clean solution. AFAICS
that was already communicated in February [0] and was only really acted
on around DebConf [1]. You can blame everyone involved, but I think it
might be better to cooperate on fixing it instead.

Cheers

Luk

[0] http://lists.debian.org/debian-devel/2009/02/msg00431.html
[1] http://lists.debian.org/debian-python/2009/08/msg3.html


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

[Bernd Zeimetz]

Sandro Tosi wrote:

> what can happen is that he prepare a rough solution, sent to debian in
> a sense "hey, take it, I've done my work, it's an ugly hack but I have
> no time to prepare an elegant solution; Now I got to go, I have
> another 1000 things to do". I'm not sure it will happen, but I fear it
> would.

That happens already. See the Python 2.6 migration for a lot of bad examples...


-- 
 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 cadence and collaboration

[Bernd Zeimetz]

Michael Banck wrote:
> On Fri, Aug 07, 2009 at 10:55:36AM +0200, Julien Cristau wrote:
>> On Fri, Aug  7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote:
> 
>>> How does Ubuntu want to do a proper (commercial) support for their packages 
>>> if
>>> they don't even have the time/manpower to take care of their bugs? Taking 
>>> care
>>> of bugs is something that should be done properly in every distribution.
>>  
>> You can look at bugs filed by paying customers, and ignore the rest.
> 
> Really, I don't think discussing Canonical's business model and/or
> Ubuntu/Canonical's approach to QA/bug triaging/bug fixing has to be
> discussed here.

As long as it is (partly?) based on the fact that bugs will be fixed by Debian
for free so Ubuntu can just reuse the bugfixes and get the money for them, I
think it should be discussed. There is nothing bad in general with that as long
as Ubuntu gives their bugfixes back to Debian and we don't have to retrieve them
out of a mess of Ubuntu patches...

-- 
 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 cadence and collaboration

[Sandro Tosi]

On Fri, Aug 7, 2009 at 00:30, Michael Bienia wrote:
> On 2009-08-06 16:25:47 +0200, Matthias Andree wrote:
>
> [I'm Ubuntu developer (MOTU to be more specific), so I might be biased]
>
> I certainly won't excuse some things that are not happening, I know that
> Ubuntu needs to improve in some aspects. But realising this and get
> things improved are still not the same. I just want to add some data
> which hopefully explains why things are happening or not happening.
...
> I'm sorry about this but the amount of bugs flowing in into Ubuntu is
> bigger that can be handled by the available man power, being it
> developer or community members.
> Bug #20 was filed March 2008
> Bug #30 was filed Nov 2008
> Bug #40 was filed Jul 2009
> This is around 10 bugs per 9 months, or around 350 bugs per day.
> While these might include also bugs filed only on projects using
> Launchpad for bug tracking, the fast amount of them are filed on Ubuntu
> packages.
> While this is not really pleasant but it's happening that some bugs are
> not looked upon for month (or even longer).
...
> Unlike Debian, Ubuntu hasn't this one maintainer per package approach
> (don't know about other distributions). In Ubuntu whole teams are
> responsible for the components: core-dev for packages in "main" and MOTU
> for packages in "universe" and "multiverse". Both approaches have there
> pro and con.
>
> For and a package being in "main" doesn't necessarily mean that it's
> better maintained than packages in "universe" (on a best effort basis).
> They might only be in "main" because they are needed by an other package
> in "main" (sorry, don't know the reason for bogofilter being in main).
>
> While Debian has over 1000 persons with upload rights, Ubuntu counts
> only 135 persons with upload rights (from those only 56 can upload to
> "main"). At the same time there are over 3000 source packages in "main"
> and over 12000 source packages in "universe".
> One can easily see that this won't work to get every package the amount
> of care that it deserves. So in the end many packages are taken
> unchanged from Debian.
> Yet bugs don't stop getting filed in Ubuntu and need to be looked at and
> acted accordingly.

This internal view shows how Ubuntu developers are already
under-staffed; so where will the resources for "collaboration" be
taken from? If current developers do not even have the time to look at
bugs, how can they work on the "collaboration" tasks and at what
price? for both of us:

- for Ubuntu, because you have to redirect attention of a developer to
another task, while he had already too many to work on;
- for Debian, because we *can* (it's a possibility) receive work of
"low" quality; consider the generic Ubuntu developer that must work
(because his time was committed to it) to do a "collaboration" task:
what can happen is that he prepare a rough solution, sent to debian in
a sense "hey, take it, I've done my work, it's an ugly hack but I have
no time to prepare an elegant solution; Now I got to go, I have
another 1000 things to do". I'm not sure it will happen, but I fear it
would.

How can this be solved?

I used Debian just to keep the example real (and because it's the
distro I care about).

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

[Sandro Tosi]

On Fri, Aug 7, 2009 at 18:37, Luk Claes wrote:
> It was and still is not meant as a decision, but as a proposal though
> the announcement said otherwise due to miscommunication from my side
> which I cannot undo unfortunately.
>
> I'm not convinced that we will be able to freeze in December anymore and
> I still want to talk to teams and people to see how their schedules can
> fit in with a proposal of a new freeze date. I do consider that we
> should delay the date significantly as many of the feedback already
> received indicates that there is more time needed before we freeze.

I'd like to loudly thank you for admit there was a problem in how this
was "released" to the public and for revisiting your proposed plan
after feedbacks received (even if some was rather hard).

This is a clear sign of the professionality you're putting in this
role (and how hard it is to wear that hat).

Thanks,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

[Luk Claes]

Mark Shuttleworth wrote:
> Cyril Brulebois wrote:
>> 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.)
>>   
> 
> At least on the Ubuntu side, there would be room to agree in advance on
> items that are as yet unreleased, but which have for various reasons
> clear advantages and well understood risks.

Just providing a bit of Debian specific context:

A freeze in Debian is usually very strict and only allows small diffs
that fix release critical bugs, release goal bugs (and sometimes
documentation or translation bugs).

> So, for example, if someone on the toolchain team said "GCC 4.5 is going
> to be released in February, and we've run a test rebuild of the archive
> and there were only 20 FTBFS's" then it might well be possible to get
> consensus around that new version being planned as a consensus base
> version for releases in 2010.

This is normally out of the question within a Debian freeze, just before
the freeze could be an option if there is a clear commitment to fix the
remaining bugs though.

Cheers

Luk


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

[Luk Claes]

Bernd Zeimetz wrote:
> Luk Claes wrote:
> 
>> If the freeze date is well known in advance the question becomes moot
>> unless some maintainer wants to work against the freeze AFAICS. Having a
>> known freeze date is meant to help everyone to be able to plan better
>> and refrain from doing high impact changes right before the freeze.
> 
> There is nothing bad with a fixed freeze date. Just with the way it was 
> planned
> for December.

s/planned/announced/

It was and still is not meant as a decision, but as a proposal though
the announcement said otherwise due to miscommunication from my side
which I cannot undo unfortunately.

I'm not convinced that we will be able to freeze in December anymore and
I still want to talk to teams and people to see how their schedules can
fit in with a proposal of a new freeze date. I do consider that we
should delay the date significantly as many of the feedback already
received indicates that there is more time needed before we freeze.

Cheers

Luk



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

[Michael Banck]

On Fri, Aug 07, 2009 at 10:55:36AM +0200, Julien Cristau wrote:
> On Fri, Aug  7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote:

> > How does Ubuntu want to do a proper (commercial) support for their packages 
> > if
> > they don't even have the time/manpower to take care of their bugs? Taking 
> > care
> > of bugs is something that should be done properly in every distribution.
>  
> You can look at bugs filed by paying customers, and ignore the rest.

Really, I don't think discussing Canonical's business model and/or
Ubuntu/Canonical's approach to QA/bug triaging/bug fixing has to be
discussed here.


Michael


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

Cyril Brulebois wrote:
> 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.)
>   

At least on the Ubuntu side, there would be room to agree in advance on
items that are as yet unreleased, but which have for various reasons
clear advantages and well understood risks.

So, for example, if someone on the toolchain team said "GCC 4.5 is going
to be released in February, and we've run a test rebuild of the archive
and there were only 20 FTBFS's" then it might well be possible to get
consensus around that new version being planned as a consensus base
version for releases in 2010.

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

[Julien Cristau]

On Fri, Aug  7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote:

> Michael Bienia wrote:
> 
> > I'm sorry about this but the amount of bugs flowing in into Ubuntu is
> > bigger that can be handled by the available man power, being it
> > developer or community members.
> 
> How does Ubuntu want to do a proper (commercial) support for their packages if
> they don't even have the time/manpower to take care of their bugs? Taking care
> of bugs is something that should be done properly in every distribution.
> 
You can look at bugs filed by paying customers, and ignore the rest.

Cheers,
Julien


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

[Bernd Zeimetz]

Luk Claes wrote:

> If the freeze date is well known in advance the question becomes moot
> unless some maintainer wants to work against the freeze AFAICS. Having a
> known freeze date is meant to help everyone to be able to plan better
> and refrain from doing high impact changes right before the freeze.

There is nothing bad with a fixed freeze date. Just with the way it was planned
for December.

-- 
 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 cadence and collaboration

[Bernd Zeimetz]

Michael Bienia wrote:

> I'm sorry about this but the amount of bugs flowing in into Ubuntu is
> bigger that can be handled by the available man power, being it
> developer or community members.

How does Ubuntu want to do a proper (commercial) support for their packages if
they don't even have the time/manpower to take care of their bugs? Taking care
of bugs is something that should be done properly in every distribution.

-- 
 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: upstart and the LSB (was: On cadence and collaboration)

[martin f krafft]

also sprach Steve Langasek  [2009.08.07.0012 +0200]:
> > Sure, it has compatibility addons, but primarily it conflicts
> > with sysvinit and encourages vendors to provide upstart control
> > files for packages, instead of init.d scripts.
> 
> Why in the world does it matter whether it's a compat layer, or if
> it's what the distributor uses for its own work?
> 
> Do you advocate throwing away Policy and replacing it with the
> LSB?

No, I certainly don't. I also didn't make myself clear in the last
message.

What I've seen are packages by vendors specifically declared to be
for Ubuntu. That used to suggest to me that they're not willing to
deal with other users and didn't put me off if I needed them on
a Debian system.

However, when I tried to install the package on Debian, it wanted to
pull in upstart and remove sysvinit. No way, not yet.

So I extracted the files to get it working quickly, but had to
discover that it only came with an upstart control file and no
init.d script. It was at that point that I wondered whether we had
just been catapulted back a step.

Hope this clears it up. Again, I think upstart is the right step in
the right direction. I also didn't want to suggest that this is
Scott's or Ubuntu's or Canonical's fault, really. You provided a new
tool and the vendor immediately started using it. In ways that's
an impressive adoption rate. ;)

I suppose there could be stuff in place in upstart to actively
discourage this sort of experimental approach for now.

-- 
 .''`.   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
 
"life is what happens to you while you're busy making other plans."
-- john lennon


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

Re: On cadence and collaboration

[Russ Allbery]

Philipp Kern  writes:
> On 2009-08-06, Russ Allbery  wrote:

>> The apparently partly-automated bug reports from what appears to be
>> your live CD system are particularly bad.  Many of them are automated
>> dumps of translated install logs with translated error messages, which
>> drastically limits the number of people who can figure out what's going
>> on.

> While the upgrade errors are mildly annoying (somebody *did* expirience
> them, though), the automated coredump retracing is very, very useful.
> If anybody hits a segv in my C++ packages and go through the bug
> reporting process it's obvious what the problem is almost every time.
> But I guess we'll get there as soon as we have debug packages in place.

Yeah, the ones that I was thinking of were the dpkg traces.  Automated
coredump backtraces would be awesome.  The dpkg traces were much less
useful.

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

[Philipp Kern]

On 2009-08-06, Russ Allbery  wrote:
> The apparently partly-automated bug reports from what appears to be your
> live CD system are particularly bad.  Many of them are automated dumps of
> translated install logs with translated error messages, which drastically
> limits the number of people who can figure out what's going on.

While the upgrade errors are mildly annoying (somebody *did* expirience them,
though), the automated coredump retracing is very, very useful.  If anybody
hits a segv in my C++ packages and go through the bug reporting process it's
obvious what the problem is almost every time.  But I guess we'll get there
as soon as we have debug packages in place.

Kind regards,
Philipp Kern


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

[Matthias Andree]

Am 06.08.2009, 22:22 Uhr, schrieb Pierre Habouzit :


On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote:

[Please Cc: replies back to me, I'm not on debian-proj...@]


FWIW, this is an excellent mail, and I share many of your opinions and
hindsights here.

Note that by your count Debian isn't always a good player with
upstreams, I'm pretty sure you will find rotting bugs in the Debian BTS
on your packages too ;)


Definitely, but I consider myself lucky that the current Debian packagers  
of my upstream projects are quite good at taking the relevant issues  
upstream and being responsive and helpful if needed, so at least I'm/we're  
aware upstream and can see if issues are reported from one end user as a  
random finding, or if constant streams of reports come from various places.


Rotting bugs? Indeed there are some. In doubt, I prefer keeping stable  
versions going over abandoning them for a development version that is  
going to be finished many a year in the future. It's annoying to see this  
"if I could overhaul subsystem X and Y, I could finally fix bug 12345"  
while receiving bug reports or browsing the trackers, but it avoids the  
far bigger annoyance of letting an old stable version rot and not having a  
new devel version stable yet -- that would be a real PITN for both end  
users and downstream distros.


--
Matthias Andree


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

"Michael Bienia"  writes:

> I'm sorry about this but the amount of bugs flowing in into Ubuntu is
> bigger that can be handled by the available man power, being it
> developer or community members.

> Bug #20 was filed March 2008
> Bug #30 was filed Nov 2008
> Bug #40 was filed Jul 2009

> This is around 10 bugs per 9 months, or around 350 bugs per day.
> While these might include also bugs filed only on projects using
> Launchpad for bug tracking, the fast amount of them are filed on Ubuntu
> packages.

> While this is not really pleasant but it's happening that some bugs are
> not looked upon for month (or even longer).

You know those long, heated arguments that Debian has had in the past
about web-based bug-tracking systems, reports from users who don't know
how to report bugs, how getting a large quantity of bugs isn't necessarily
useful compared to getting high-quality bugs, and how making it too easy
to report bugs can just result in the bug tracking system being flooded
with bugs that no one ever looks at?

Yeah, that.

Certainly, my experience is that for many of the packages that I maintain
in Debian which are also in Ubuntu, the only person who ever looks at the
Ubuntu bugs and does anything about them is me.  Which is ironic, given
that I don't use Ubuntu and can't test directly any of the problems that
people report.

The apparently partly-automated bug reports from what appears to be your
live CD system are particularly bad.  Many of them are automated dumps of
translated install logs with translated error messages, which drastically
limits the number of people who can figure out what's going on.

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

[Michael Bienia]

On 2009-08-06 16:25:47 +0200, Matthias Andree wrote:

[I'm Ubuntu developer (MOTU to be more specific), so I might be biased]

I certainly won't excuse some things that are not happening, I know that
Ubuntu needs to improve in some aspects. But realising this and get
things improved are still not the same. I just want to add some data
which hopefully explains why things are happening or not happening.

> 1. General communication with upstream maintainers, and consequences
> 
> I recently - out of curiosity - looked at the launchpad.net Ubuntu bugs for
> packages I (co-)maintain upstream. Upstream here is "at the origin", not 
> Debian
> packaging or something, list as above.
> 
> Some were relevant and still current, and Ubuntu failed to either do something
> about the bugs (as in debug, write a patch) or at least tell people who were 
> in
> a position to do something about the problem, concretely, forward the bug
> upstream. This is the very least you must do.
> 
> Example: https://bugs.launchpad.net/ubuntu/+source/bogofilter/+bug/320829
> This had sufficient information to debug, and lay around for half a year.
> Nobody in Ubuntu bothered to look at the report, or to forward it to the 
> upstreams.

I'm sorry about this but the amount of bugs flowing in into Ubuntu is
bigger that can be handled by the available man power, being it
developer or community members.
Bug #20 was filed March 2008
Bug #30 was filed Nov 2008
Bug #40 was filed Jul 2009
This is around 10 bugs per 9 months, or around 350 bugs per day.
While these might include also bugs filed only on projects using
Launchpad for bug tracking, the fast amount of them are filed on Ubuntu
packages.
While this is not really pleasant but it's happening that some bugs are
not looked upon for month (or even longer).

> Another observation is that Ubuntu bugs and bug changes are frequently 
> forwarded
> to dozens of people, yet nobody cares to look. All you get is "me too" or
> dramatic narrations of how the bug ate somebody's dog. From maintainers, such 
> as
> ubuntu core maintainers, for core packages: deafening silence.

When you mean the "Also notified" list: this list includes people
subscribed to bugmail for a package (none are subscribed for bogofilter)
and people subscribed to all bugmail. I don't know why so many people
subscribe to all bugmail as I certainly couldn't handle that volume.

> I'm happy to help distributions (without picking any particular, I don't care
> about your name, but about how you act), but I'm definitely not going to 
> ferret
> up the downstream maintainers or "their" bugs. This was a one-time event.
> 
> Some proposals for Ubuntu's part in this:
> 
>   i.   if you can't deal with a bug, tell somebody who can. Leaving it to rot
>is going to drive users away.

I know :( I was about to nearly stop filing bugs myself for this reason
(no one commented) before I got involved into Ubuntu and realized myself
that there is simply not enough manpower for everything.

>   ii.  make package owners explicit. Just assigning package responsibilities 
> for
>all packages to some opaque mailing list evidently does not work. The
>list gets my upstream maintainer updates to the bug, yet nobody cares.

Unlike Debian, Ubuntu hasn't this one maintainer per package approach
(don't know about other distributions). In Ubuntu whole teams are
responsible for the components: core-dev for packages in "main" and MOTU
for packages in "universe" and "multiverse". Both approaches have there
pro and con.

For and a package being in "main" doesn't necessarily mean that it's
better maintained than packages in "universe" (on a best effort basis).
They might only be in "main" because they are needed by an other package
in "main" (sorry, don't know the reason for bogofilter being in main).

While Debian has over 1000 persons with upload rights, Ubuntu counts
only 135 persons with upload rights (from those only 56 can upload to
"main"). At the same time there are over 3000 source packages in "main"
and over 12000 source packages in "universe".
One can easily see that this won't work to get every package the amount
of care that it deserves. So in the end many packages are taken
unchanged from Debian.
Yet bugs don't stop getting filed in Ubuntu and need to be looked at and
acted accordingly.

Michael


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

Re: upstart and the LSB (was: On cadence and collaboration)

[Steve Langasek]

On Thu, Aug 06, 2009 at 08:50:36PM +0200, martin f krafft wrote:
> … and all of the efforts of the LSB to standardise sysvinit so that
> every vendor can drop init.d scripts into place and expect them to
> work, are undermined by upstart.

Right, just like the efforts of the LSB to standardize a package format are
undermined by our use of .deb.

> Sure, it has compatibility addons, but primarily it conflicts with
> sysvinit and encourages vendors to provide upstart control files for
> packages, instead of init.d scripts.

Why in the world does it matter whether it's a compat layer, or if it's what
the distributor uses for its own work?

Do you advocate throwing away Policy and replacing it with the LSB?

> I will not replace sysvinit or /sbin/init on crucial systems with
> something that hasn't been around enough long enough for people to
> understand and embrace with all their heart.

> Don't get me wrong: I long for upstart's functionality. It just
> seems "half-baked" and counter-productive when viewed in the light
> of the LSB efforts.

Not in the least.

-- 
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: On cadence and collaboration

[Pierre Habouzit]

On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote:
> [Please Cc: replies back to me, I'm not on debian-proj...@]

FWIW, this is an excellent mail, and I share many of your opinions and
hindsights here.

Note that by your count Debian isn't always a good player with
upstreams, I'm pretty sure you will find rotting bugs in the Debian BTS
on your packages too ;)

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

[Tim Webster]

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

There is unnecessary incompatibility between Ubuntu and Debian. Their
incompatible bts is one that personally bits me.

 The Ultimate Debian Database helps show ubuntu/debian package
relationships.
http://udd.debian.org/
http://wiki.debian.org/UltimateDebianDatabase

Unfortunately Debian and Ubuntu use incompatible bts systems. Currently
Ubuntu's launchpad based bug tracking system _bts_ is lacking accessible
package version information. Bug tracking information tied to package
version is essential for debian where packages go through many version
iterations between releases. Package bugs should not be tracked based on the
release. They must be tracked based on their version.

This was part of the original design for Launchpad Bugs, but it never came
to fruition. The very earliest bug still open on Launchpad Bugs asks for
this:
https://bugs.launchpad.net/malone/+bug/424

Up to and including Hardy, ubuntu used apt-listbugs which referred to
debian's bts with package version tracking. Even though this pulled bug
information from the debian bts, it gave a reasonable indication of what
packages contained significant bugs. apt-listbugs was withdrawn, because
ubuntu package customization increasing has made the related debian bts
irrelevant.

Topic branches and topic trees of are ways by which package customization
can be tracked.
 In order to meet the Debian Collaboration Team's objective the launchpad
bts must interface with the debian bts. Only this way developers benefit
from the topic branches, trees of distributed package source control. To
collaborate bugs must be tracked across both debian and ubuntu and be
accessible to both native debian and ubuntu developers.

upstart and the LSB (was: On cadence and collaboration)

[martin f krafft]

also sprach Matthias Andree  [2009.08.06.1625 +0200]:
> Ubuntu has some interesting approaches, such as Upstart. However, these are
> incomplete, underdocumented, and in consequence half-baked. If you care about
> the end user experience, you've got to bite the bullet and not only lick it.
> Discussing about superimposing schedules and conferences doesn't help at all.
> 
> Providing half-baked solutions is a real nuisance for the end user and the
> upstreams: it creates the very inconsistencies that you'd like to avoid, and 
> it
> adds one more item to the half-baked items list. Users get deprived of the old
> way of doing things (or it's a whole heap more work to do it the old way), the
> new way doesn't work yet, and upstreams sometimes see the fallout of such
> downstream changes.

… and all of the efforts of the LSB to standardise sysvinit so that
every vendor can drop init.d scripts into place and expect them to
work, are undermined by upstart.

Sure, it has compatibility addons, but primarily it conflicts with
sysvinit and encourages vendors to provide upstart control files for
packages, instead of init.d scripts.

I can make Check Point Firewall-1, which is said to only work on
RedHat -2 work on Debian in a jiffy.

I will not replace sysvinit or /sbin/init on crucial systems with
something that hasn't been around enough long enough for people to
understand and embrace with all their heart.

Don't get me wrong: I long for upstart's functionality. It just
seems "half-baked" and counter-productive when viewed in the light
of the LSB efforts.

-- 
 .''`.   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
 
anyone who says sunshine brings happiness
has never danced in the rain.


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

Re: On cadence and collaboration

[Leo "costela" Antunes]

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

It is exactly the point of this thread if you use it as an argument
against a common freeze cycle.

> This was only an example, there are others, nitpicking
> on this one (or any other, for that matter) is pointless.

It's OK to bring it up as an argument, but not to counter it?

Counter-argument != nitpicking. I wholeheartedly agree there are other
examples, pro and con, but since you brought this up as an argument,
there's nothing pointless in countering it.


Cheers

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


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

[Pierre Habouzit]

On Thu, Aug 06, 2009 at 03:18:08PM +0200, Stefano Zacchiroli wrote:
> On Thu, Aug 06, 2009 at 02:08:26AM +0200, Cyril Brulebois wrote:
> > Or is some incremental freeze still supposed to happen?
>
> During the talk/discussion at DebConf, IIRC Luk stated that
> incremental freezes had a negative effect because for many developers
> it was not clear what/when was going to be frozen. The logical
> consequence drawn there (again, IIRC) has been that the release team
> would prefer freezing all at once.
>
> Note, however, that we have always used to have unblocks during
> freezes; the policy on how unblocks are handled is completely
> orthogonal to how "sharply" you freeze.
>
> > (Putting -release in Cc to catch their attention.)
>
> Keeping that to ensure I'm not on crack with my memories :-)

You're not, it's IMHO a faithful wording of our position (with the
s/releasing/freezing/ fix ;p)

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

Re: On cadence and collaboration

[Russ Allbery]

Philipp Kern  writes:
> On 2009-08-06, Josselin Mouette  wrote:

>> And this is precisely why it was asked that for squeeze, frozen and
>> testing remain different suites during the freeze. Currently I have no
>> idea of whether this will happen.
>
> While I see the point of this I don't know if I would be happy.  If
> people just continue with business as usual for unstable and testing we
> will not release.  See the RC bug fixing activity of the last release.
>
> A short freeze just means that people would actually have to squash some
> bugs, but it seems that the majority of DDs simply don't care.  Freezing
> a bit of unstable helps us to apply some peer pressure.  Kudos to all of
> them who helped releasing in the last freezing cycle.  I just don't like
> the perspective of feeling alone in the next one.

Those who haven't seen it already might want to watch Theo de Raadt's
presentation this year on how OpenBSD releases.  It seems directly
relevant and very similar to our current release process, except they
manage more consistent timing (in large part, I think, because the amount
of software they're freezing is smaller and they have more control over
it).

http://www.youtube.com/watch?v=i7pkyDUX5uM

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

[Felix Zielcke]

Am Donnerstag, den 06.08.2009, 18:01 +0200 schrieb Marc Haber:
> On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote:
> > GRUB 2 is going to be another opportunity where Ubuntu can prove
> > either useful or detrimental to your stated goals: invest time to
> > polish it and contribute back to the upstream; or use it raw as it is
> > and leave the user with the shards if it breaks. The upstream
> > abandoned GRUB 1, GRUB 2 isn't ready.
> 
> This is a good point where people can actually help: GRUB 2 is,
> besides all other shortcomings, severely underdocumented. Ubuntu
> as a very user-friendly distribution probably has skilled writers at
> hand - task some of them to produce useable documentation on GRUB 2.
> 

But please note that if you want to help with an official GRUB 2 manual,
then everyone needs to assign copyright to FSF.


-- 
Felix Zielcke
Proud Debian Maintainer


-- 
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 Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote:
> GRUB 2 is going to be another opportunity where Ubuntu can prove
> either useful or detrimental to your stated goals: invest time to
> polish it and contribute back to the upstream; or use it raw as it is
> and leave the user with the shards if it breaks. The upstream
> abandoned GRUB 1, GRUB 2 isn't ready.

This is a good point where people can actually help: GRUB 2 is,
besides all other shortcomings, severely underdocumented. Ubuntu
as a very user-friendly distribution probably has skilled writers at
hand - task some of them to produce useable documentation on GRUB 2.

The rest of the mail which I am replying to gets a clear +1.

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

[Margarita Manterola]

On Wed, Aug 5, 2009 at 4:44 PM, 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.

Well, this is not the proposal as it was announced, and this is
definitely not what we understand as "freeze" in Debian.  In Debian,
"freezing" in December means that no new versions enter testing after
the freeze begins.

I think the proposal as you word it would be fine, since this would
probably mean freezing later on.  Maybe March or so.  This would make
much more sense, from my point of view.  But this is NOT what was
announced and communicated to us.

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

I don't think it makes sense to rush our release as much as it's being
proposed only to finish with different versions of big components.  I
understand that GCC and X are important, but I don't think all the
hard work makes sense unless we can also sync the desktops.

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

That's not how it has worked in the past. We've had some scaled
freeze, freezing the toolchain first and the rest of the packages
afterwards, but it's never been "some maintainer teams" who decided
what was frozen and what wasn't, it's always been the Release Team.
And the Release Team has said that they'd rather not do the scaled
freeze this time, they'd rather just do one freeze, and get it over
fast.

I think that there is a significant difference on how Debian and
Ubuntu work towards a release which means that speaking about a
"December freeze" has very different consequences on each
distribution.  So, maybe we need to change the terms, so that we are
both speaking about the same thing.

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

Again, this was not what was announced, it's not what we were
expecting after the "We freeze in December" plan.

I personally wouldn't object to a general "let's decide what we want
in our distro" discussion in December, as long as the freeze is done
after those components have been included.  That means that if we want
March's GNOME, we would have to freeze in April.

If we (as in Debian) freeze in December, then there's absolutely
nothing to discuss.  We already know what we are going to ship.

Finally, the whole idea of the time based freezes was to know when we
were going to freeze, so that maintainers could work towards that.  If
the freeze date is decided in the December discussions, then we are
back to the current (or past) model, of freezing at some unknown
point.

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

[Harald Braumann]

On Wed, 05 Aug 2009 10:21:38 +0100
Mark Shuttleworth  wrote:

> Hi folks

Hi there

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

Truly an enthusiastic speech which gives us a vision of a bright new
world and even includes the yes we can spirit. And yet I lack
the trust that such will ever happen. To convince so many and so diverse
groups to all commit to a single goal, and may it just be something as
profane as a common freeze date, would be unprecedented in human
history.

But let's assume I'm wrong, and it is actually going to happen ...

> 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 :-)

I'm sorry then to rain on your parade. Despite the risk of being
accused of heresy, let me state my doubts about such a move in general.
I leave discussions about specific advantages or disadvantages that this
might hold for Debian to others, much more competent on the matter.
Instead I would like to approach this issue more abstractly.

We know of many examples in nature, human society, economics,
computing, etc., that show that distributed, non-hierarchical,
self-organising system can be much more powerful than centrally
controlled systems. It can be proved, for instance, that a swarm of
independent units without central control can converge a solution in
cases, where classical iterative schemes that have such a central
control do not[0]. Add central control (a central clock) and this power
vanishes.

While it is not clear if such a model applies to the FLOSS world
without doing extensive research, I strongly believe that it would
harm the system if you add a central control (in this case some central
committee that decides on freeze dates). While it might look appealing
at first sight to have a central authority to decide on certain
matters, this rips the system of the ability to change quickly and
adapt to new circumstances.

But let's again assume that I'm wrong and that it would do the FLOSS
world good. 

But: good how? What exactly will be better? It is an
ambitious goal you propose which will require projects to make
compromises, to invest time and possibly money, to change their
priorities. So at the end of the day people will want to know if it was
worth the investment. What are the criteria on which this question can
be decided? 

That, say, GNOME releases in time for the distributions to pick it up
is easily testable, but not an advantage on its own. That the world
becomes a better place is a worthwhile goal but impossible to verify.

Would you please give verifiable and falsifiable criteria which can be
evaluated objectively to answer such a question? Examples would be
- the "productive" work/bug fixing ration increases 
- less security leaks
- number of people moving to GNU/Linux per year increase
- etc.

At the moment it is not clear for me, what the real advantage for
projects and users would be.

However, I completely agree that collaboration helps everybody. But
instead of inserting an additional level in the hierarchy to
govern such collaborations, I believe the better approach is to tighten
the collaboration-network. Here collaboration happens on a different
level. Between package maintainers and their upstream, between projects
that depend on each other, between Debian package maintainers and
Ubuntu package maintainers, etc.

Cheers,
harry

[0] Gerardo Beni: Order by Disordered Action in Swarms.


signature.asc
Description: PGP signature

Re: On cadence and collaboration

[Matthias Andree]

[Please Cc: replies back to me, I'm not on debian-proj...@]

Mark,

I think you have a biassed view in your role as Ubuntu maintainer.
This isn't bad in itself, but it needs to be written so that positions are 
clear.

My position is: I'm currently using openSUSE for my development, with occasional
portability tests on Solaris, NetBSD, FreeBSD, Ubuntu.  I'm looking after my
Mom's Ubuntu installation.

More importantly, I'm also an upstream maintainer of fetchmail and leafnode, and
I'm also co-maintainer of bogofilter. I would not consider any of these projects
large. This is not Mozilla, Adobe.  Still, my upstream maintenance considers
needs of users and distributors, i. e. I will usually accept bug reports for
outdated versions if I know that area of the code hasn't changed.

The whole longish message of yours is about telling that others need to move and
how good it all could be if everbody did, and you're pulling an argument that
this was in the interest of end users. This is but a pretext, Ubuntu apparently
doesn't catch enough karma among developers through deeds and achievements, and
your begging for compromises isn't bound to improve on that, but quite the 
contrary.


There are some key points of criticism I'd like to mention:

1. General communication with upstream maintainers, and consequences

I recently - out of curiosity - looked at the launchpad.net Ubuntu bugs for
packages I (co-)maintain upstream. Upstream here is "at the origin", not Debian
packaging or something, list as above.

Some were relevant and still current, and Ubuntu failed to either do something
about the bugs (as in debug, write a patch) or at least tell people who were in
a position to do something about the problem, concretely, forward the bug
upstream. This is the very least you must do.

Example: https://bugs.launchpad.net/ubuntu/+source/bogofilter/+bug/320829
This had sufficient information to debug, and lay around for half a year.
Nobody in Ubuntu bothered to look at the report, or to forward it to the 
upstreams.


Another observation is that Ubuntu bugs and bug changes are frequently forwarded
to dozens of people, yet nobody cares to look. All you get is "me too" or
dramatic narrations of how the bug ate somebody's dog. From maintainers, such as
ubuntu core maintainers, for core packages: deafening silence.

I'm happy to help distributions (without picking any particular, I don't care
about your name, but about how you act), but I'm definitely not going to ferret
up the downstream maintainers or "their" bugs. This was a one-time event.

Some proposals for Ubuntu's part in this:

  i.   if you can't deal with a bug, tell somebody who can. Leaving it to rot
   is going to drive users away.

  ii.  make package owners explicit. Just assigning package responsibilities for
   all packages to some opaque mailing list evidently does not work. The
   list gets my upstream maintainer updates to the bug, yet nobody cares.

  iii. if you take my work (i. e. upstream tarball), and you're a downstream
   packager, it's your moral duty to approach me and tell me who you are and
   what you do.

   We appear to share the intention of improving user experience, but as
   written earlier, I'm not going to ferret up all possible downstreams.

   And there is prior evidence that my expectations work out: I have
   occasional contact with the downstream maintainers of other
   distributions, such as FreeBSD, NetBSD/pkgsrc, Debian, Fedora/Red Hat,
   OpenBSD, openSUSE. Often, new-coming packagers will approach the
   upstreams and introduce themselves, and perhaps share questions, bug
   reports or patches. I've never seen this happen for Ubuntu.

Bottom line: Ubuntu has to work about something, or to contact whoever they feel
fit, if they want something to change.


2. Getting innovations right, and going them all the way

Ubuntu has some interesting approaches, such as Upstart. However, these are
incomplete, underdocumented, and in consequence half-baked. If you care about
the end user experience, you've got to bite the bullet and not only lick it.
Discussing about superimposing schedules and conferences doesn't help at all.

Providing half-baked solutions is a real nuisance for the end user and the
upstreams: it creates the very inconsistencies that you'd like to avoid, and it
adds one more item to the half-baked items list. Users get deprived of the old
way of doing things (or it's a whole heap more work to do it the old way), the
new way doesn't work yet, and upstreams sometimes see the fallout of such
downstream changes.

Across all Linux distributions, the most prominent innovations I recall are, in
random order: X, X-autoconfig, Intel driver for X, dbus/HAL, NetworkManager,
Pulseaudio, Upstart, KDE4 (and particularly the lack of established and crucial
features therein, such as X.509 certificate management).

You can't expect other distributions to collaborate if you don't muster 

Re: On cadence and collaboration

[Stefano Zacchiroli]

On Thu, Aug 06, 2009 at 03:18:08PM +0200, Stefano Zacchiroli wrote:
> During the talk/discussion at DebConf, IIRC Luk stated that
> incremental freezes had a negative effect because for many developers
> it was not clear what/when was going to be frozen. The logical
> consequence drawn there (again, IIRC) has been that the release team
> would prefer releasing all at once.
   ^

Here of course I meant "freezing".
.oO( is that an instance of a "freudian typo" ?)

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Stefano Zacchiroli]

On Thu, Aug 06, 2009 at 02:08:26AM +0200, Cyril Brulebois wrote:
> Or is some incremental freeze still supposed to happen?

During the talk/discussion at DebConf, IIRC Luk stated that
incremental freezes had a negative effect because for many developers
it was not clear what/when was going to be frozen. The logical
consequence drawn there (again, IIRC) has been that the release team
would prefer releasing all at once.

Note, however, that we have always used to have unblocks during
freezes; the policy on how unblocks are handled is completely
orthogonal to how "sharply" you freeze.

> (Putting -release in Cc to catch their attention.)

Keeping that to ensure I'm not on crack with my memories :-)

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Steve Langasek]

On Thu, Aug 06, 2009 at 02:21:49PM +0200, Cyril Brulebois wrote:
> Luk Claes  (06/08/2009):
> > If the freeze date is well known in advance the question becomes moot
> > unless some maintainer wants to work against the freeze AFAICS. Having
> > a known freeze date is meant to help everyone to be able to plan
> > better and refrain from doing high impact changes right before the
> > freeze.

> We already have maintainers working against any kind of common sense. We
> have maintainers breaking transitions, delaying them, or starting them
> when they're not welcome. We even have a mechanism to enforce sanity
> (transition-related upload prevention/blocks).

> Why would/should the freeze be treated in a different manner?

There have always been, and always will be, a small subset of developers who
work against our freezes out of ignorance or even hostility.  For the most
part, however, developers seem to be pretty good at acting in their own
enlightened self-interest, and not behave in ways that are guaranteed to
make the freeze longer by making it harder to release.

It's hard to measure this quantitatively because you don't have a real
control, but certainly my subjective experience is that this is very
effective.

-- 
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: the role of the LSB (was: On cadence and collaboration)

[Michael Banck]

On Thu, Aug 06, 2009 at 08:52:10AM +0200, martin f krafft wrote:
> I think it's the job of something like the LSB to ensure a necessary
> baseline across distros on which vendors can build. 

Well, maybe; however the LSB is *very* baseline, so not very useful.

Besides, it is heavily geared towards ISVs, not other FLOSS projects.
Having a unified set of core packages across a number of important
distributions would make it easier for other upstream projects to target
their support at (as opposed to just supported the latest stable or even
unstable/snapshot release).

And in the end, the LSB would profit as well, as it could more easily
define the set of base packages required, based on what is decided upon
by the those interacting distributions.

Whether this is something Debian should desire is a different matter I
have not made up my mind upon.


Michael


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

Re: the role of the LSB (was: On cadence and collaboration)

[Mark Brown]

On Thu, Aug 06, 2009 at 02:49:37PM +0200, Pierre Habouzit wrote:
> On Thu, Aug 06, 2009 at 02:02:59PM +0200, martin f krafft wrote:

> > I am failing to accept that vendors need to use those very specific
> > things in their software.  just like I doubt that people need IE-HTML
> > to make their sites render properly. I think laziness^W business
> > thinking is more likely an option.

> Probably because you don't write this kind of software then. I'm working
> for telco stuff, we have very specific needs towards the high
> availability interfaces (epoll and similar) linux provides, and its SCTP
> stack. This only has caused us major issues in the past.

For that sort of stuff you normally end up needing to validate the
binary image of the system anyway - especially if the telco thinks it
can get away with charging you for compliance testing on any change.
What coding to standards buys you is a greater degree of protection
against things breaking underneath you which does get you 90% of the way
there.


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

Re: the role of the LSB (was: On cadence and collaboration)

[Pierre Habouzit]

On Thu, Aug 06, 2009 at 02:02:59PM +0200, martin f krafft wrote:
> also sprach Pierre Habouzit  [2009.08.06.1104 +0200]:
> > You're comparing apples and oranges here, for HTML is a standard,
> > and theoretically, following the standard is enough (and even that
> > is probably -- and sadly -- a fallacy).
> 
> LSB is growing to be just that, but it won't stand a chance if
> people/distros don't work with it.
> 
> > When it comes to the LSB, it doesn't say what happens when you're
> > using very specific bits of the Linux kernel or the GNU libc, and
> > when you're doing networking stuff for example, well, that matters
> > a lot.  That's why LSB doesn't work for many vendors because of
> > the very different toolchains.
> 
> I am failing to accept that vendors need to use those very specific
> things in their software.  just like I doubt that people need IE-HTML
> to make their sites render properly. I think laziness^W business
> thinking is more likely an option.

Probably because you don't write this kind of software then. I'm working
for telco stuff, we have very specific needs towards the high
availability interfaces (epoll and similar) linux provides, and its SCTP
stack. This only has caused us major issues in the past.

Then you add the fact that binary compatibility is a joke (openssl has
not the same soname on RH and Debian e.g.).

And on top of that you add binutils so crappy that our software
misbuilds on those platforms.

Sorry but no, you cannot make abstraction of that, on this, _you_ are
not living in the reality.


FWIW I would dream for my work that I could count on decently similar
kernels, toolchains and libcs on all distros. Only that would be cause
for joy and happiness here.

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

[Cyril Brulebois]

Luk Claes  (06/08/2009):
> If the freeze date is well known in advance the question becomes moot
> unless some maintainer wants to work against the freeze AFAICS. Having
> a known freeze date is meant to help everyone to be able to plan
> better and refrain from doing high impact changes right before the
> freeze.

We already have maintainers working against any kind of common sense. We
have maintainers breaking transitions, delaying them, or starting them
when they're not welcome. We even have a mechanism to enforce sanity
(transition-related upload prevention/blocks).

Why would/should the freeze be treated in a different manner?

Mraw,
Mooty
KiBi.


signature.asc
Description: Digital signature

Re: On cadence and collaboration

[Luk Claes]

Cyril Brulebois wrote:
> 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.)

If the freeze date is well known in advance the question becomes moot
unless some maintainer wants to work against the freeze AFAICS. Having a
known freeze date is meant to help everyone to be able to plan better
and refrain from doing high impact changes right before the freeze.

Cheers

Luk


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

Re: the role of the LSB (was: On cadence and collaboration)

[martin f krafft]

also sprach Pierre Habouzit  [2009.08.06.1104 +0200]:
> You're comparing apples and oranges here, for HTML is a standard,
> and theoretically, following the standard is enough (and even that
> is probably -- and sadly -- a fallacy).

LSB is growing to be just that, but it won't stand a chance if
people/distros don't work with it.

> When it comes to the LSB, it doesn't say what happens when you're
> using very specific bits of the Linux kernel or the GNU libc, and
> when you're doing networking stuff for example, well, that matters
> a lot.  That's why LSB doesn't work for many vendors because of
> the very different toolchains.

I am failing to accept that vendors need to use those very specific
things in their software, just like I doubt that people need IE-HTML
to make their sites render properly. I think laziness^W business
thinking is more likely an option.

Anyway, if there is something that should be standardised, well,
bring it up to the LSB. The W3C and web-standards groups didn't
suggest to synchronise the rendering engines between all browsers.
They defined standards. I think that's what we ought to do too.

-- 
 .''`.   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
 
"this sentence contradicts itself -- no actually it doesn't."
 -- douglas hofstadter


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

Re: On cadence and collaboration

[Philipp Kern]

On 2009-08-06, Josselin Mouette  wrote:
> And this is precisely why it was asked that for squeeze, frozen and
> testing remain different suites during the freeze. Currently I have no
> idea of whether this will happen.

While I see the point of this I don't know if I would be happy.  If people
just continue with business as usual for unstable and testing we will not
release.  See the RC bug fixing activity of the last release.

A short freeze just means that people would actually have to squash some
bugs, but it seems that the majority of DDs simply don't care.  Freezing
a bit of unstable helps us to apply some peer pressure.  Kudos to all of
them who helped releasing in the last freezing cycle.  I just don't like
the perspective of feeling alone in the next one.

Kind regards,
Philipp Kern


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

Re: the role of the LSB (was: On cadence and collaboration)

[Pierre Habouzit]

On Thu, Aug 06, 2009 at 08:52:10AM +0200, martin f krafft wrote:
> also sprach Pierre Habouzit  [2009.08.05.2333 +0200]:
> > 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).
> 
> I think it's the job of something like the LSB to ensure a necessary
> baseline across distros on which vendors can build. Anyone gearing
> software at distro-specifics is committing the same fallacy as
> people writing HTML for Internet Exploder. And distros who are
> actively ignoring or superseeding the LSB are counter-productive.

You're comparing apples and oranges here, for HTML is a standard, and
theoretically, following the standard is enough (and even that is
probably -- and sadly -- a fallacy).

When it comes to the LSB, it doesn't say what happens when you're using
very specific bits of the Linux kernel or the GNU libc, and when you're
doing networking stuff for example, well, that matters a lot.  That's
why LSB doesn't work for many vendors because of the very different
toolchains.  You have to do regression tests for every single distro out
there, which many corporations cannot do, hence certify only for a
couple of distributions (and often only one: RHEL).

Anyways we're drifting away from the original point, so just let cut
that here.

> I just don't think it'll solve the vendors problem, nor eliminate
> all other problems relating to distro diversity. Heck, it might even
> create new problems, e.g. security issues as Julien suggested.

That's beside the point, if anyone thought I was saying that aiming to
synchronized freeze would solve the vendor problem, then I've probably
been ambiguous. I've never meant it.

I was merely explaining why the Distribution diversity is, in my
opinion, not something that one can call an _asset_. It's a variable
that you have to live with in the free software world. It has its upside
and its downsides, but it's neither an asset nor a defect.


I'm really sorry if I let people think that I'm advocating synced
freezes so that "LSB can be done right". It had never even crossed my
mind.

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

Re: On cadence and collaboration

[Russ Allbery]

Julien BLACHE  writes:
> Steve McIntyre  wrote:
>> Julien BLACHE  writes:

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

Some teams had to work in experimental, some teams had to work on feature
development in a VCS instead of on package uploads, and a lot of package
uploads had to be delayed or staged in external repositories, but "stop
work" is an exaggeration.  Considerable dpkg work happened during the
freeze, for example, and dpkg was affected as badly as anything in Debian.
Notice the huge changelogs for 1.15.0 and 1.15.1.

If you had to stop work because of the freeze, you have an opportunity to
improve your development infrastructure by building ways to stage work
without having to upload everything to unstable.  I did lots of work on my
packages targetted at squeeze during the lenny freeze when there wasn't
anything to do for lenny for them.  Most of that work was uploaded to
experimental.

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

[Paul van der Vlis]

Mark Shuttleworth schreef:

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

Redhat/Fedora seems to be difficult to win, but is a strong partner.
Maybe we could try to make a freeze with both Debian and Ubuntu on a
date that RedHat freezes in the hope Redhat likes it for a next time. We
can do our best to make it attractive for them.

Ubuntu will maybe be the first to release. No problem for me. Important
point for me to choose Debian is the security-support on all packages.
And Debian stable has more time so it can learn from problems in other
distributions.

With regards,
Paul van der Vlis.




-- 
http://www.vandervlis.nl/


-- 
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 jeudi 06 août 2009 à 08:08 +0200, Julien BLACHE a écrit :
> >>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.

And this is precisely why it was asked that for squeeze, frozen and
testing remain different suites during the freeze. Currently I have no
idea of whether this will happen.

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

the role of the LSB (was: On cadence and collaboration)

[martin f krafft]

also sprach Pierre Habouzit  [2009.08.05.2333 +0200]:
> 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).

I think it's the job of something like the LSB to ensure a necessary
baseline across distros on which vendors can build. Anyone gearing
software at distro-specifics is committing the same fallacy as
people writing HTML for Internet Exploder. And distros who are
actively ignoring or superseeding the LSB are counter-productive.

Vendors will always find reasons to limit themselves to one or two
distros. IME in the past, that has not been because those distros
are the only ones that can run their software, it's much more the
case that their software engineers have no time to do the testing
across all distros, and their support engineers don't know anything
else and are thus unwilling to support it (warranty void).

Synchronising software isn't going to change that — the distros will
still be unique in their own ways.

But let me put this into the proper relation: I think collaboration
across distros is desirable (cf. vcs-pkg.org). I think it would be
great if we got GNOME to agree on a long-term-support version, and
dto. for Apache, gcc, all the others as it means time savings for
everyone (less work duplication), and the possibility for more
innovation.

I just don't think it'll solve the vendors problem, nor eliminate
all other problems relating to distro diversity. Heck, it might even
create new problems, e.g. security issues as Julien suggested.

Let's just stay real.

-- 
 .''`.   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
 
"verbing weirds language."
   -- calvin


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

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