Re: Bits from the Release Team - Kicking off Wheezy

[Marc 'HE' Brockschmidt]

Hi,

Lucas Nussbaum  writes:
> Eh? How do you fix stuff in the next release if you don't make uploads?
> I'm not saying that the number of uploads should stay the same: it's
> normal to see it going down during freezes, since there are less things
> to change. However, if we think that DDs participate in RC bug fixing,
> the number of distinct uploaders should not go down.

Of course it should go down. People lose interest as soon as they have
cleaned up their packages and some few things they are interested
in. In a perfect world, they would re-invest their time in fixing bugs
in other packages, or uploading their great new crap to experimental -
but in a perfect world, they would also only need to work 3 hours a day
to pay for their lifestyle. It's not gonna happen.

Your argument is basically that freezing reduces the time developers
spend on Debian. However, trying to maximize developer time spent on
Debian is not the same as maximizing the quality of the resulting
product (be it a stable release, a constantly usable testing or some new
rolling/unstable-pre-2000 distribution). 

What we are seeing in a freeze is what happens shortly before a release
in every software company around the world - crappy jobs noone likes
need to be done: last-minute fixes, documentation, testing, ...
The difference is that in a company, someone can force people to do what
they don't like. In Debian, we cannot do this, thus people turn
away until they can do their fun projects again. This will not magically
change. Giving in to that will mean that the last-minute fixes,
documentation and testing will not get done at all - and that's not what
I expect of Debian.

Marc
-- 
BOFH #414:
tachyon emissions overloading the system


pgpzlIAY9EfYq.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

[Raphael Hertzog]

On Fri, 29 Apr 2011, Andreas Barth wrote:
> > Good. I just want to point out that "frozen" built on top on rolling
> > (which is what we're proposing here) is different from "frozen" built on
> > top of unstable (which is what we had before the introduction of testing).
> 
> The main drawback for frozen was that there is now a suite with quite
> some bad bugs which need to be fixed.

Yes, and testing was supposed to fix that and limit the scope of the
problem. And it probably has although we have grown again since 2000
so even a small percentage of buggy packages makes for a big number
of RC bugs.

> And that we're lacking man power to fix that independend from unstable.

It's not entirely independent from unstable, not all packages diverge
from day 0. The percentage of divergent packages increases steadily. The
shorter the freeze the more packages will be able to be fixed via
unstable.

That said, we're lacking man power to fix bugs, I don't think that
it changes much whether the bug is fixed via unstable or via frozen.
Once we are to the point where we have been able to fix a bug in
unstable, it's usually not very difficult to fix it in frozen too (unless
the fix is in a new upstream version, but that would not help in the
current scheme either).

The core problem with the "man power" is that a (small) set of maintainers
are not taking care of their RC bugs with due diligence.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430071417.gd19...@rivendell.home.ouaza.com

Re: Bits from the Release Team - Kicking off Wheezy

[Raphael Hertzog]

On Fri, 29 Apr 2011, Andreas Barth wrote:
> People try out new things in experimental, and it seems to work mostly
> well to get new stuff migrated from there via unstable to testing once
> the release is done (except that we try to not do too many things in
> parallel - and things have improved within the recent years).

No, experimental is not satisfying:
1/ packages in experimental are not correctly tested, the userbase is too small.
2/ migrating from experimental to unstable requires source uploads and all
   the rebuildds (with the accompanying delays for slow arches)
3/ experimental is not meant for daily usage, so it's doesn't help users
   who really want a rolling release

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430071955.ge19...@rivendell.home.ouaza.com

Re: Bits from the Release Team - Kicking off Wheezy

[sean finney]

Hi!

(accumulated replies FTW)

On Fri, Apr 29, 2011 at 11:20:31PM +0200, Andreas Barth wrote:
> >  * unstable always feeds to testing
> >  * "release N" == "testing", until the "freeze".
> 
> You know that we had once "frozen", and have given up since as that
> didn't scale even back then?

I think it has already been pointed out at some point that it's not a
complete analog.  Specifically (AIUI), way back then, "frozen" was
basically a snapshot of unstable, with all the bugs problems, etc.
Indeed, it was a large part of the motivation for having testing in the
first place.

What most of the proposals here are suggesting is that we have something
similar, but based off of a "testing" snapshot instead.

> This concept needs double or tripple man power from what we currently
> have. That's the show-stopper.

I don't totally agree with that estimate but as I've pointed out before
it *will* be more work, just lke maintaining two branches in a VCS instead
of one would be.  Additionally, the proposal would suggest that:

 * much of the extra work could be done by the package maintainers themselves.
 * much of the additional overhead could be automated/scripted.

Whether it actually *could* is of course another question, but that's
why it's part of a hypothesis.

On Fri, Apr 29, 2011 at 11:48:53PM +0200, Andreas Barth wrote:
> On the other hand, the entry barier into the release team isn't too
> high. If someone is willing to work e.g. only on encouraging packages
> fixing important bugs to testing faster, please get in contact with
> one of the release managers (or me), and we can certainly arrange
> something in the interesst of all.
> 
> But just making more mess in testing for PR reasons doesn't sound like
> a good idea to me.

I don't think it's for PR reasons.  It's because currently, when Debian
is in the middle of forming it's rock-solid stable release, EVERYTHING ELSE
slows down too.  When AJT introduced testing he referred to it as a
"sludgey" alternative to frozen, but when the entire project is sludgey
for extended periods of time, it affects the number of fun and innovative
things happening in Debian.  I'm a big proponent of the "when it's ready"
camp, but also think we could come up with a way that lowers the collateral
damage to other parts of the project.

On Fri, Apr 29, 2011 at 11:22:54PM +0200, Andreas Barth wrote:
> I don't think the plan is straightforward, but just "not working".
> It's easy to write down things that other people need to do - but that
> won't work.
> 
> Please show the man power necessary to get your plan implemented -
> otherwise, all is moot.

As I've said before, I'm willing to do more than throw popcorn from
the armchair here :)  My biggest hesitation for rolling up my sleeves
and getting right at it is that I wasn't sure whether it would fall on
deaf ears and be a collossal waste of time.  And note that I'm not
pinning "waste of time" to "accept/reject" for the proposal--I think this
is a very intresting experiment, and regardless of the outcome we'd
probaly walk away with some new ideas/tools/questions.

To kinda put my money where my mouth is, I'd be willing to sign up as
some kind of release assistant, helping with the current release processes
while working on this proposal.

On Fri, Apr 29, 2011 at 06:50:04PM -0400, Michael Gilbert wrote:
> Actions speak a whole lot loader than words and design by committee is
> unlikely to get you anywhere.  And a GR (as mentioned in your blog
> 
> So, really what I'm saying is just go for it.  Prove that its
> something worthwhile so the project has a basis for adopting it.

I think the best way forward at this point is something along those lines.
I'll take out a DEP for starters, so we can have authoritative place
with a "project plan" (i.e. not scattered across ML's and blog posts).


sean

-- 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430072644.ga15...@cobija.connexer.com

Re: Bits from the Release Team - Kicking off Wheezy

[Raphael Hertzog]

Hi,

On Sat, 30 Apr 2011, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> Raphael, it would be so great to reply to messages in single mails
> instead of squeezing (are you release-themed, or what?) all of your
> answers into one mail. I'm really tired of chasing a specific answer
> From you through the whole thread.

I thought it was a good practice to reduce the overall amount of mails and
to be able to avoid too many repetitions or references to other mails.

> Raphael Hertzog  writes:
> > But I don't plan to work on any of those if the project does not agree to
> > promote testing to something that can be advertised as usable by end-users
> > and as something that we strive to support on a best-effort basis.
> 
> What does a best-effort basis mean?  I cannot imagine a use case where this
> might make sense, and I haven't found any presentation of one by you.

"best-effort" characterizes the way we contribute to Debian, it means
the maintainer should do its best to ensure his packages in testing are
in a good shape. There might be times when he fails due to lack of time
but then he should try to get help.

Right now, a maintainer can legitimately ignore testing until freeze
because Debian does not support testing, testing is just a tool to prepare
a release. I want to change that and never hear that objection again.
I want that new maintainers that join Debian know up-front that
their task involves managing packages in stable and in rolling
(and in frozen should that happen).

> Who is going to install a "rolling" release instead of "testing"?

If we change our documentation to say that rolling can be used by anyone
who likes a constantly evolving distribution (and can live with the
occasionnal hiccup) and that we will do our best to support it, then the
public of testing/rolling will be larger.

And a larger public, in particular in that set of users who likes bleeding
edge stuff, is likely to mean more efficient testing of packages and
possibly more contributors.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430074538.gf19...@rivendell.home.ouaza.com

Re: Bits from the Release Team - Kicking off Wheezy

[Philipp Kern]

On 2011-04-30, Raphael Hertzog  wrote:
> On Fri, 29 Apr 2011, Andreas Barth wrote:
>> People try out new things in experimental, and it seems to work mostly
>> well to get new stuff migrated from there via unstable to testing once
>> the release is done (except that we try to not do too many things in
>> parallel - and things have improved within the recent years).
> No, experimental is not satisfying:
> 1/ packages in experimental are not correctly tested, the userbase is too 
> small.
> 2/ migrating from experimental to unstable requires source uploads and all
>the rebuildds (with the accompanying delays for slow arches)

So here this is a problem while for frozen you're arguing that we could easily
do sourceful uploads and just wait for the builds to trickle in?

> 3/ experimental is not meant for daily usage, so it's doesn't help users
>who really want a rolling release

It's not that it isn't meant.  Of course we could also look at overlay
solutions.  (That said, while I'm very happy about mozilla.debian.net, I
somehow still feel that those packages should be added in a co-installable way
into some official suites.  But then you get back to the "we don't support
all architectures yet" department, I presume.)

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnirnfn6.j3h.tr...@kelgar.0x539.de

Re: Bits from the Release Team - Kicking off Wheezy

[Russ Allbery]

Raphael Hertzog  writes:

> Right now, a maintainer can legitimately ignore testing until freeze
> because Debian does not support testing, testing is just a tool to
> prepare a release. I want to change that and never hear that objection
> again.  I want that new maintainers that join Debian know up-front that
> their task involves managing packages in stable and in rolling (and in
> frozen should that happen).

I'm not sure that this is going to be solved by any sort of change along
these lines.  Those objections usually strike me as more "you're not the
boss of me" sort of objections against doing something that they don't
want to bother with, rather than something based on a philosophical
understanding of testing.  I suspect that, after an introduction of a
rolling distribution, that same objection would just morph into "I'm not
interested in supporting rolling."

I think this is a fairly small portion of our developer base, and most
developers do care about testing and pursue issues, particularly when
informed of them by the excellent mail messages letting people know that
packages haven't migrated as expected.  Most of the current failure to fix
problems in testing is probably more because people just haven't noticed
(or because the problem is hard, as it is with a couple of my packages
right now), not because they're blowing off testing because they think it
only matters during a freeze.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874o5gw4we@windlord.stanford.edu

Re: Bits from the Release Team - Kicking off Wheezy

[Charles Plessy]

Le Fri, Apr 29, 2011 at 11:20:31PM +0200, Andreas Barth a écrit :
> 
> This concept needs double or tripple man power from what we currently
> have. That's the show-stopper.

Hi all,

one way to increase the manpower is to give more permissions to the package
maintainers.

For instance, one could imagine to use a command file or directory writable by
every DD, that would cause packages to be moved or removed from our non-stable
suites, with features like the following:

 - Only for leaf packages of priority optional or lower,
 - a system to keep an eye on the changes (commit list or RSS feed),
 - a temporisation mechanism so that changes are not executed immediately,
 - stored in a VCS so that it is easy to revert changes.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430085350.gc11...@merveille.plessy.net

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 09:14 AM, Raphael Hertzog wrote:


That said, we're lacking man power to fix bugs, I don't think that it
changes much whether the bug is fixed via unstable or via frozen.
Once we are to the point where we have been able to fix a bug in
unstable, it's usually not very difficult to fix it in frozen too
(unless the fix is in a new upstream version, but that would not help
in the current scheme either).



I'm not so sure. Contributors will introduce new versions… as we've seen
with Chromium, sometimes it's just impossible to fix the old version
(because it requires much time and manpower), and we will be forced to
accept the new version. We did it _once_ for Chromium, it's not said
that we will do that again! So this argument doesn't stand either. It's
making a big assumptions on various things.

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbbd0ac.3050...@dogguy.org

Re: Bits from the Release Team - Kicking off Wheezy

[Marc 'HE' Brockschmidt]

Heya,

Raphael Hertzog  writes:
> On Sat, 30 Apr 2011, Marc 'HE' Brockschmidt wrote:
>> Raphael, it would be so great to reply to messages in single mails
>> instead of squeezing (are you release-themed, or what?) all of your
>> answers into one mail. I'm really tired of chasing a specific answer
>> From you through the whole thread.
> I thought it was a good practice to reduce the overall amount of mails and
> to be able to avoid too many repetitions or references to other mails.

It means that my MUA, which is good as threading, cannot help me to
organize discussions. It requires me to spend time instead of CPU cycles.

>> Raphael Hertzog  writes:
>>> But I don't plan to work on any of those if the project does not agree to
>>> promote testing to something that can be advertised as usable by end-users
>>> and as something that we strive to support on a best-effort basis.
>> What does a best-effort basis mean?  I cannot imagine a use case where this
>> might make sense, and I haven't found any presentation of one by you.
> "best-effort" characterizes the way we contribute to Debian, it means
> the maintainer should do its best to ensure his packages in testing are
> in a good shape. 

So "best-effort" is only a new label for the current status, right?

> Right now, a maintainer can legitimately ignore testing until freeze
> because Debian does not support testing, testing is just a tool to prepare
> a release.

Who does that? Is that a relevant problem you have examples for?
Preferably related to non-fringe packages?

>> Who is going to install a "rolling" release instead of "testing"?
> If we change our documentation to say that rolling can be used by anyone
> who likes a constantly evolving distribution (and can live with the
> occasionnal hiccup) and that we will do our best to support it, then the
> public of testing/rolling will be larger.

Why can't we do the same for testing and have the same result?

> And a larger public, in particular in that set of users who likes bleeding
> edge stuff, is likely to mean more efficient testing of packages and
> possibly more contributors.

Yeah, where "likely" means "you believe it" - I don't. You seem to
believe that Debian's attractiveness is directly depending on providing
newer software - I don't.

Debian once was attractive for users because it was introducing new,
wonderful technologies to a broader user base. Proper package
management, well-tested integration of packages, the ability to automate
installations, thousands of packages, ... were features that at some
point of time were things that Debian provided and no other big
distribution did. Today, almost every other Linux distribution provides
all these features.

In the last years, Debian hasn't been able to contribute any important
feature to the F/OSS distribution world - change (leading to both good
or bad results) happens at other places (namely Ubuntu) at the moment.
I believe this has a simple, technical reason - Debian has become too
big. Every change requires a massive amount of work on thousands of
packages, interaction with hundreds of (sometimes absent) volunteers and
is thus increasingly costly. This high cost makes experiments
impossible, because backing out of a change is a waste of the scare
resources of the Debian project.

Debian is perfectly good at holding the status quo - it's a
well-integrated, stable, mostly state of the art distribution suited for
almost anything you can come up with. Trying to repaint one of the
existing bikesheds with your new "rolling" color will not attract the
developers (nor users) interested in making it a hip place again.

Marc

[Yes, I'm old and frustrated. Do not comment on that part.]


pgpdkmYDZzi9h.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Raphael Hertzog (hert...@debian.org) [110430 09:46]:
> > Who is going to install a "rolling" release instead of "testing"?
> 
> If we change our documentation to say that rolling can be used by anyone
> who likes a constantly evolving distribution (and can live with the
> occasionnal hiccup) and that we will do our best to support it, then the
> public of testing/rolling will be larger.

Do you have numbers for that, or is that just a PR claim from you?


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430100521.gp15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Holger Levsen]

Hi,

On Samstag, 30. April 2011, Raphael Hertzog wrote:
> If we change our documentation to say that rolling can be used by anyone
> who likes a constantly evolving distribution (and can live with the
> occasionnal hiccup) and that we will do our best to support it, then the
> public of testing/rolling will be larger.
> 
> And a larger public, in particular in that set of users who likes bleeding
> edge stuff, is likely to mean more efficient testing of packages and
> possibly more contributors.

I'm starting to think that this could be true.

:-)


cheers,
Holger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104301206.34666.hol...@layer-acht.org

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Philipp Kern (tr...@philkern.de) [110430 09:49]:
> It's not that it isn't meant.  Of course we could also look at overlay
> solutions.  (That said, while I'm very happy about mozilla.debian.net, I
> somehow still feel that those packages should be added in a co-installable way
> into some official suites.  But then you get back to the "we don't support
> all architectures yet" department, I presume.)

I think it would make quite sense to get something like e.g. ppa done for
Debian. But thats something else than it's proposed here.


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430100724.gq15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Russ Allbery (r...@debian.org) [110430 09:54]:
> I think this is a fairly small portion of our developer base, and most
> developers do care about testing and pursue issues, particularly when
> informed of them by the excellent mail messages letting people know that
> packages haven't migrated as expected.

Yes, most developers act very helpful regarding to testing. That's at
least my observation from the last 5 or more years.


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430100857.gr15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Mike Hommey]

On Sat, Apr 30, 2011 at 07:48:54AM +, Philipp Kern wrote:
> On 2011-04-30, Raphael Hertzog  wrote:
> > On Fri, 29 Apr 2011, Andreas Barth wrote:
> >> People try out new things in experimental, and it seems to work mostly
> >> well to get new stuff migrated from there via unstable to testing once
> >> the release is done (except that we try to not do too many things in
> >> parallel - and things have improved within the recent years).
> > No, experimental is not satisfying:
> > 1/ packages in experimental are not correctly tested, the userbase is too 
> > small.
> > 2/ migrating from experimental to unstable requires source uploads and all
> >the rebuildds (with the accompanying delays for slow arches)
> 
> So here this is a problem while for frozen you're arguing that we could easily
> do sourceful uploads and just wait for the builds to trickle in?
> 
> > 3/ experimental is not meant for daily usage, so it's doesn't help users
> >who really want a rolling release
> 
> It's not that it isn't meant.  Of course we could also look at overlay
> solutions.  (That said, while I'm very happy about mozilla.debian.net, I
> somehow still feel that those packages should be added in a co-installable way
> into some official suites.  But then you get back to the "we don't support
> all architectures yet" department, I presume.)

Co-installable would be hell. Especially with the new mozilla release
schedule.

That being said, it would be really helpful to be able to get buildds
to build the mozilla.d.n packages...

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430101603.gb25...@glandium.org

Re: Bits from the Release Team - Kicking off Wheezy

[Stefano Zacchiroli]

On Sat, Apr 30, 2011 at 11:28:17AM +0200, Marc 'HE' Brockschmidt wrote:
> In the last years, Debian hasn't been able to contribute any important
> feature to the F/OSS distribution world - change (leading to both good
> or bad results) happens at other places (namely Ubuntu) at the moment.
> I believe this has a simple, technical reason - Debian has become too
> big. Every change requires a massive amount of work on thousands of
> packages, interaction with hundreds of (sometimes absent) volunteers and
> is thus increasingly costly. This high cost makes experiments
> impossible, because backing out of a change is a waste of the scare
> resources of the Debian project.

No, no, and ... uhm ... no :-)
(although we're getting a bit off-topic here, I'll bite)

I agree with your analysis above, but exactly because I agree with it, I
argue that you cannot single out "big" as the main cause. To disprove
that as the main cause, it would be enough to notice that some of our
derivatives are, by definition, as big as Debian is, but still can make
significant changes on top of what we offer them.

So the overall issue is rather the interaction among the size and the
processes that govern that huge package repository monster that we
are. As an example, consider a maintainer willing to devote her time in
making a change that touches 300 packages. Let's assume that the change
is consensual. To deploy the change in Debian either you are lucky and:
1) all the packages are in the same VCS and 2) you've commit write
access to it (in which case you've very little procedural obstacles in
your way). Or rather you need to ping maintainers, chase the "sometimes"
absent people, do NMUs, etc. And that is the easy case where the change
is consensual!

Size is just one ingredient. There are plenty of other ways to diminish
barrier to deploy big changes in Debian: wider commit access rights,
larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly,
several Debian derivatives have decide to pursue those other ways and
one might argue that they have done so learning from Debian experience.)

Of course each such change will have consequences elsewhere, but please
don't assume that size is the only problem. I've the impression that
will simply stop our creativity in improving our processes.

> Debian is perfectly good at holding the status quo - it's a
> well-integrated, stable, mostly state of the art distribution suited for
> almost anything you can come up with. Trying to repaint one of the
> existing bikesheds with your new "rolling" color will not attract the
> developers (nor users) interested in making it a hip place again.

And how do you know that?

In fact, I'm even happy to see becoming manifest the various
disagreement and different expectations we have around testing: on such
"vague" aspects it's hard to have upfront agreements.  But both you and
Raphael are taking guesses on the number of users / developers / effects
of a thing which does not exist yet. At this point, it can only be
speculation. You might disagree how much as you please, but there is
only one way to know who is right: build the thing.

As long as that does not step on others toes and as long as there are
volunteers willing to put their energy into a new experiment, that's
just fine.  Big changes after all also need people willing to go ahead
against some odds and show they were right --- or alternatively fail
miserably.

Cheers.

> [Yes, I'm old and frustrated. Do not comment on that part.]

/me hugs Marc

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Bits from the Release Team - Kicking off Wheezy

[Marc 'HE' Brockschmidt]

Stefano Zacchiroli  writes:

> On Sat, Apr 30, 2011 at 11:28:17AM +0200, Marc 'HE' Brockschmidt wrote:
>> In the last years, Debian hasn't been able to contribute any important
>> feature to the F/OSS distribution world - change (leading to both good
>> or bad results) happens at other places (namely Ubuntu) at the moment.
>> I believe this has a simple, technical reason - Debian has become too
>> big. Every change requires a massive amount of work on thousands of
>> packages, interaction with hundreds of (sometimes absent) volunteers and
>> is thus increasingly costly. This high cost makes experiments
>> impossible, because backing out of a change is a waste of the scare
>> resources of the Debian project.
> No, no, and ... uhm ... no :-)
> (although we're getting a bit off-topic here, I'll bite)

Can I get my "I've successfully baited the DPL" shirt, please?

> I agree with your analysis above, but exactly because I agree with it, I
> argue that you cannot single out "big" as the main cause. To disprove
> that as the main cause, it would be enough to notice that some of our
> derivatives are, by definition, as big as Debian is, but still can make
> significant changes on top of what we offer them.

Uhm, not really. Ubuntu, as main example, is not as big as Debian (well,
that of course depends on your measure, but still...). It doesn't need
to care about the weirder architectures, and its support for non-core
packages is minimal. Our derivatives do not only extend Debian, they
also cut away (or demote to be of lesser importance) some of the
complexities that they do not want to handle.

>> Debian is perfectly good at holding the status quo - it's a
>> well-integrated, stable, mostly state of the art distribution suited for
>> almost anything you can come up with. Trying to repaint one of the
>> existing bikesheds with your new "rolling" color will not attract the
>> developers (nor users) interested in making it a hip place again.
> And how do you know that?

I don't. I believe it - it should have been worded accordingly, of course.

> In fact, I'm even happy to see becoming manifest the various
> disagreement and different expectations we have around testing: on such
> "vague" aspects it's hard to have upfront agreements.  But both you and
> Raphael are taking guesses on the number of users / developers / effects
> of a thing which does not exist yet. At this point, it can only be
> speculation. You might disagree how much as you please, but there is
> only one way to know who is right: build the thing.

Well, of course I would love to see how Raphael does a
rolling.debian.net archive and proves me wrong here - but I don't have
the impression that this is what's supposed to happen here. 
In his blog, he presented a GR draft that wants to rename the existing
testing suite to rolling. In this thread, he furthermore explained
that he wants that rolling is governed by a different policy than
testing. 
This would replace a core part of the current development model and
doing that on the unfounded belief that this will attract new users and
contributors is something I want to avoid.

Marc


pgpas45Vi26xk.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 09:45 AM, Raphael Hertzog wrote:



Who is going to install a "rolling" release instead of "testing"?


If we change our documentation to say that rolling can be used by
anyone who likes a constantly evolving distribution (and can live
with the occasionnal hiccup) and that we will do our best to support
 it, then the public of testing/rolling will be larger.

And a larger public, in particular in that set of users who likes
bleeding edge stuff, is likely to mean more efficient testing of
packages and possibly more contributors.



Your proposal if full of optimism and good intentions, and I appreciate
that. But, I really think that:

1) it's going to kill stable for reasons already mentioned.
2) you won't be able to bring as much users as you tend to think because
one the big problems of testing right now is not the freeze but the lack
of installer. If you want to get more users for testing, please do
contribute to d-i. We need a lot of manpower and new ideas to implement
there. (I'm a big fan of d-i team already because they're doing much
work, but they do need help).

Users are not interested in installing stable and then upgrade to
testing. Why should they bother? there are other distros out there that
offer much better installers¹ (in terms of user interface and ease of
use). Not to say that we don't even have official llive-cds yet…

¹: although, I do personally prefer Debian's installer.

"rolling" won't fix those problems. And, saying that it'll be supported
on a 'best-effort basis', it doesn't ring any bell to me, tbh. We all
already do that, except a few (I don't even know who they are). Those
won't change their behavior because it's already 'on best-effort basis'
for them too :)

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbbea12.8080...@dogguy.org

PPAs for Debian

[Stefano Zacchiroli]

On Sat, Apr 30, 2011 at 12:07:24PM +0200, Andreas Barth wrote:
> * Philipp Kern (tr...@philkern.de) [110430 09:49]:
> > It's not that it isn't meant.  Of course we could also look at overlay
> > solutions.  (That said, while I'm very happy about mozilla.debian.net, I
> > somehow still feel that those packages should be added in a co-installable 
> > way
> > into some official suites.  But then you get back to the "we don't support
> > all architectures yet" department, I presume.)
> 
> I think it would make quite sense to get something like e.g. ppa done for
> Debian. But thats something else than it's proposed here.

Yes, absolutely. I'd even dare to say that having something like PPA for
Debian is a priority. It would be yet another way to enable people to
experiment with big changes in Debian, showing their value, with minimum
impact on the work of others.

It happens that I've a recent update on this topic to share. There were
some concerns about the need of something like a NEW queue for Debian's
PPA, for legal reasons. I had a long phone call with SPI lawyer about
this just yesterday. It turns out that there are a few provisions we
should follow to stay on the safe side, but there is no specific blocker
either. We can go ahead, individual maintainers will be responsible of
what they upload / distribute via PPA.

What we lack for that to become a reality is "just" the code. Marc and
Tollef had set up a nice proposal [1] for GSoC this year and were
willing to mentor it, but unfortunately no student has shown up. If
there are people willing to contribute some development cycles to Debian
(no need to be a DD), that's a wonderful opportunity.

Some FAQ on this topic:

Q: Why don't you use Launchpad's PPA? 
A: Last time I looked into it (together with some Launchpad engineers at
   past UDS), the PPA module was too tightly integrated with other
   Launchpad parts to be deployable on Debian infrastructure

Q: Didn't Canonical offer a PPA service to Debian?
A: Only rumors, TTBOMK. And anyhow I believe it would be better to have
   an independent infrastructure that we are in full control of. That
   poses extra constraints on which kind of offer would fit our needs
   (constraints that we cannot force an independent company to fulfill)

Cheers.

[1] http://wiki.debian.org/SummerOfCode2011/DevPkgRepo

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 12:28 PM, Stefano Zacchiroli wrote:

Debian is perfectly good at holding the status quo - it's a
well-integrated, stable, mostly state of the art distribution
suited for almost anything you can come up with. Trying to repaint
one of the existing bikesheds with your new "rolling" color will
not attract the developers (nor users) interested in making it a
hip place again.


And how do you know that?



The first point is confirmed by the number of derivatives of Debian.
The second can be argued, IMHO, by the fact that there won't be releases of
"rolling". They won't be working installers at all times. It's supported
on 'best-effort' basis… we *already* try to do that. Advertising that
won't change anything for developers (we are not evil), but only for
users! Well, some of them, those reading planet, d-d-a, or
$whatever_news_media that will explain clearly and in a faithful way the
change.


In fact, I'm even happy to see becoming manifest the various
disagreement and different expectations we have around testing: on
such "vague" aspects it's hard to have upfront agreements.  But both
you and Raphael are taking guesses on the number of users /
developers / effects of a thing which does not exist yet. At this
point, it can only be speculation. You might disagree how much as
you please, but there is only one way to know who is right: build
the thing.



And you can do that right now, without waiting. Go book
"rolling.debian.net" and set up a britney instance there. It's not a
difficult task. It will help us to know who actually uses it, when, how
much, etc… Please do prove us wrong!

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbbec8d.3010...@dogguy.org

Re: PPAs for Debian

[Andreas Barth]

* Stefano Zacchiroli (lea...@debian.org) [110430 12:56]:
> What we lack for that to become a reality is "just" the code. Marc and
> Tollef had set up a nice proposal [1] for GSoC this year and were
> willing to mentor it, but unfortunately no student has shown up. If
> there are people willing to contribute some development cycles to Debian
> (no need to be a DD), that's a wonderful opportunity.

Yes, PPAs "just" need someone who does it. Not more, but also not
less.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430110424.gh2...@mails.so.argh.org

mozilla.d.n (was: Bits from the Release Team - Kicking off Wheezy)

[Andreas Barth]

* Mike Hommey (m...@glandium.org) [110430 12:16]:
> That being said, it would be really helpful to be able to get buildds
> to build the mozilla.d.n packages...

Would it work to build the packages in unstable? If so, why not
uploading them to experimental and re-branding them in mozilla.d.n?


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430110657.gt15...@mails.so.argh.org

Re: mozilla.d.n (was: Bits from the Release Team - Kicking off Wheezy)

[Mike Hommey]

On Sat, Apr 30, 2011 at 01:06:57PM +0200, Andreas Barth wrote:
> * Mike Hommey (m...@glandium.org) [110430 12:16]:
> > That being said, it would be really helpful to be able to get buildds
> > to build the mozilla.d.n packages...
> 
> Would it work to build the packages in unstable? If so, why not
> uploading them to experimental and re-branding them in mozilla.d.n?

I'm not sure to understand what you are suggesting.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430112806.ga28...@glandium.org

Re: mozilla.d.n (was: Bits from the Release Team - Kicking off Wheezy)

[Andreas Barth]

* Mike Hommey (m...@glandium.org) [110430 13:28]:
> On Sat, Apr 30, 2011 at 01:06:57PM +0200, Andreas Barth wrote:
> > * Mike Hommey (m...@glandium.org) [110430 12:16]:
> > > That being said, it would be really helpful to be able to get buildds
> > > to build the mozilla.d.n packages...
> > 
> > Would it work to build the packages in unstable? If so, why not
> > uploading them to experimental and re-branding them in mozilla.d.n?
> 
> I'm not sure to understand what you are suggesting.


The question is how could we get the packages built so that we don't
need to setup yet another buildd suite (or more general, I want to
avoid setting one suite per package). Of course, ppa would come to
rescue here, and it's really only a question of "someone would need to
write the code".

I would propose the following for now:

1. For unstable users, upload the packages to experimental, and
extract them from there once they are built.
2. For testing users, do the same (but only take the packages if they
have dependencies fullfilable in testing)
3. For stable and oldstalbe users, upload the packages to bpo, and
extract them from there.

All that can (and should) be scripted of course.


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430121806.gu15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Raphael Hertzog]

On Sat, 30 Apr 2011, Andreas Barth wrote:
> * Raphael Hertzog (hert...@debian.org) [110430 09:46]:
> > > Who is going to install a "rolling" release instead of "testing"?
> > 
> > If we change our documentation to say that rolling can be used by anyone
> > who likes a constantly evolving distribution (and can live with the
> > occasionnal hiccup) and that we will do our best to support it, then the
> > public of testing/rolling will be larger.
> 
> Do you have numbers for that, or is that just a PR claim from you?

I don't have numbers. But even if I'm wrong, what does it cost us to
try it and to be honest about we're trying to achieve?

(That said the reactions I've read on various CUT proposals always tended
to confirm this gut feeling of mine)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430122829.ga18...@rivendell.home.ouaza.com

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/28/2011 08:20 PM, Lucas Nussbaum wrote:


The sooner we get the big transitions done, the sooner we can focus
on fixing the remaining bugs.



There will be always new transitions… you're gonna to wait for ever.

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc0132.9050...@dogguy.org

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Raphael Hertzog (hert...@debian.org) [110430 14:28]:
> On Sat, 30 Apr 2011, Andreas Barth wrote:
> > * Raphael Hertzog (hert...@debian.org) [110430 09:46]:
> > > > Who is going to install a "rolling" release instead of "testing"?
> > > 
> > > If we change our documentation to say that rolling can be used by anyone
> > > who likes a constantly evolving distribution (and can live with the
> > > occasionnal hiccup) and that we will do our best to support it, then the
> > > public of testing/rolling will be larger.
> > 
> > Do you have numbers for that, or is that just a PR claim from you?
> 
> I don't have numbers. But even if I'm wrong, what does it cost us to
> try it and to be honest about we're trying to achieve?

Feel free to use rolling.debian.net, set it up and have success. Like
aj did with setting up testing (after frozen has burned IIRC three
release managers without an release). "Show that it works" is the
Debian principle, and it works pretty well.

But don't expect that you can commander my time.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430123604.gi2...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.04.2011 14:36, Andreas Barth wrote:
> Feel free to use rolling.debian.net, set it up and have success. Like
> aj did with setting up testing (after frozen has burned IIRC three
> release managers without an release).

Perhaps that's a not a particular fair demand. See, crucial for Raphaels
idea as I read it is "official" support to users using a rolling
distribution. For both, user support and bug fixing of course.

How could he ever succeed if he can't be sure people involved into
Debian development would at least partially support his approach then?
Imagine people would ask for help on various d-u lists or in the Debian
IRC support channels and all they get is "Sorry, we don't support
rolling.debian.net, get lost and bother $r_d_n_people"; documentation
suggests "don't use anything but stable" and maintainer don't care about
fixing bugs which could improve r.d.n stability.

> "Show that it works" is the
> Debian principle, and it works pretty well.

I agree. This does not imply others should sabotage his efforts
actively. Sure the approach needs to be proven to work before being
integrated into Debian, but one should give r.d.n interested people at
least a chance to succeed.

- -- 
with kind regards,
Arno Töll
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNvAu6AAoJEMcrUe6dgPNtMOgQALLH64Ibk9xANeFBYbvNvEYu
iZZ7OXXcrzZuY1W4ulF4qXjhksFMJKDKFuN7Obyb3Vc6CW21ztJ/xzmIlJ8nH/Gv
sQG1hHwzJzHYuY4k/FFcD23m8b9IXMjXXGOX4gLHIPAzKpGV48R0yPRIULBDADdj
8kr0+gVEgEf3QRjFoua47GP2nm5Rtve2VdZw51QSzRONYSlzXAiR8zygNCYVhKld
39aCZM3whp5M3xlgM+McJRpnZLmQqPP3w9pKtylx1LzW9vd0atTtiZOIAd5Lp55a
AA3qsZXFuJsHaBB/r7NWMVg1GpA3zK4RRRc/4gHmWcEOIMmpEywOAfTJsTeHgtOo
B2SXuaqsDIZQxJiPBXUQ6lDhgJKtYGJabuLr2Za/GGyQf1fjYqTN376byc7giHF3
tiku5oVtmUSziKBx/WVtJWoAHYeNEuTohU+EdWSkaMqisSH94HoCY6Nn6dUwdBQN
PBt03JfR4LUpDGMqeeqFT1YZj6+bZzRdHh5Gii5q1o3tMAC1ji92E8MFThjc95a8
wlGswgxcrtgFdKqk9hL5TWMcmUmeDSR/iqu6f0Q5AKqLdLprZ2ssXnzR6cC5IIPU
WRr7wB8HKbfdGuX03TO8GVP83fpf6CDNp5B4hFcxQb8U8wATgJ3EEgud81V4sqa1
DXpldNOOvboApRE2IDUI
=1rdA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc0bba.4030...@toell.net

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 03:16 PM, Arno Töll wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1

On 30.04.2011 14:36, Andreas Barth wrote:

Feel free to use rolling.debian.net, set it up and have success.
Like aj did with setting up testing (after frozen has burned IIRC
three release managers without an release).


Perhaps that's a not a particular fair demand. See, crucial for
Raphaels idea as I read it is "official" support to users using a
rolling distribution. For both, user support and bug fixing of
course.



In this particular case, the "official" bit won't change anything for
developers. It's only a buzz word to attract more users, IMHO.


How could he ever succeed if he can't be sure people involved into
Debian development would at least partially support his approach
then? Imagine people would ask for help on various d-u lists or in
the Debian IRC support channels and all they get is "Sorry, we don't
support rolling.debian.net, get lost and bother $r_d_n_people";


"rolling" won't have its own set of packages with source modified. It will
use packages from unstable, as testing does right now. So, if a bug is
found in a package provided by "rolling", it's very likely to be found
in sid as well.


documentation suggests "don't use anything but stable" and
maintainer don't care about fixing bugs which could improve r.d.n
stability.



Who said that? which documentation are you talking about? Whoever told
you that is wrong.


"Show that it works" is the Debian principle, and it works pretty
well.


I agree. This does not imply others should sabotage his efforts
actively.


Sorry, but there is no sabotage at all! Everyone if free to set up a
rolling.d.n, and it doesn't anything else than manpower and time. All
tools and data are already published and free software. And, if he needs
assistance to set up one of the needed tools, I'm sure he'll find some.

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc0da3.4080...@dogguy.org

Re: Bits from the Release Team - Kicking off Wheezy

[Lucas Nussbaum]

On 30/04/11 at 14:31 +0200, Mehdi Dogguy wrote:
> On 04/28/2011 08:20 PM, Lucas Nussbaum wrote:
> >The sooner we get the big transitions done, the sooner we can focus
> >on fixing the remaining bugs.
> 
> There will be always new transitions… you're gonna to wait for ever.

OK, but I'm under the impression that in the first 6 months of a release
cycle, we usually have a lot more transitions than during the next 6
months. Also, the fact that we don't have a clear release schedule with
a freeze date fixed in advance probably encourages people to start new
transition when the reasonable thing to do would be to stop there and
stabilize.

One thing that I really enjoyed when I was more active in Ubuntu was the
clearly defined release schedules, split into the time when you can
break the world, and the time when everybody works towards stabilizing
(long before the final freeze).

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430132451.gb5...@xanadu.blop.info

Re: Bits from the Release Team - Kicking off Wheezy

[Lucas Nussbaum]

On 30/04/11 at 14:36 +0200, Andreas Barth wrote:
> * Raphael Hertzog (hert...@debian.org) [110430 14:28]:
> > On Sat, 30 Apr 2011, Andreas Barth wrote:
> > > * Raphael Hertzog (hert...@debian.org) [110430 09:46]:
> > > > > Who is going to install a "rolling" release instead of "testing"?
> > > > 
> > > > If we change our documentation to say that rolling can be used by anyone
> > > > who likes a constantly evolving distribution (and can live with the
> > > > occasionnal hiccup) and that we will do our best to support it, then the
> > > > public of testing/rolling will be larger.
> > > 
> > > Do you have numbers for that, or is that just a PR claim from you?
> > 
> > I don't have numbers. But even if I'm wrong, what does it cost us to
> > try it and to be honest about we're trying to achieve?
> 
> Feel free to use rolling.debian.net, set it up and have success. Like
> aj did with setting up testing (after frozen has burned IIRC three
> release managers without an release). "Show that it works" is the
> Debian principle, and it works pretty well.

Note that the "you can do it on your own" argument doesn't really hold,
because it can only work if there's a project-wide agreement that we
should work in that direction.

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430131904.ga5...@xanadu.blop.info

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 03:24 PM, Lucas Nussbaum wrote:

On 30/04/11 at 14:31 +0200, Mehdi Dogguy wrote:

On 04/28/2011 08:20 PM, Lucas Nussbaum wrote:

The sooner we get the big transitions done, the sooner we can
focus on fixing the remaining bugs.


There will be always new transitions… you're gonna to wait for
ever.


OK, but I'm under the impression that in the first 6 months of a
release cycle, we usually have a lot more transitions than during the
next 6 months.


True. But, big transitions are announced (fortunately), and long time
before they start, generally. So, you can see what RC is likely to be
fixed by a new upstream release that will be part of a transition, and
which won't. YMMV and I can understand that.


Also, the fact that we don't have a clear release schedule with a
freeze date fixed in advance probably encourages people to start new
 transition when the reasonable thing to do would be to stop there
and stabilize.



Quite honestly, we did announce a transition freeze before the big
freeze for Squeeze… and it didn't really worked out. We can hope that
it'll get better for Wheezy, but we are not there yet. We will have a
time-based freeze for Wheezy, let's hope that this will address your
concerns (including those mentioned in the next paragraph).


One thing that I really enjoyed when I was more active in Ubuntu was
 the clearly defined release schedules, split into the time when you
 can break the world, and the time when everybody works towards
stabilizing (long before the final freeze).



I do agree on this. There is one difference though: they don't care
about fixing packages not in main, it's not a release blocker for them
(almost). We do have to fix much more than the subset they care about before
being able to release.

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc102b.7000...@dogguy.org

Re: Bits from the Release Team - Kicking off Wheezy

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.04.2011 15:24, Mehdi Dogguy wrote:
> On 04/30/2011 03:16 PM, Arno Töll wrote:
>> Perhaps that's a not a particular fair demand. See, crucial for
>> Raphaels idea as I read it is "official" support to users using a
>> rolling distribution. For both, user support and bug fixing of
>> course.
>>
> 
> In this particular case, the "official" bit won't change anything for
> developers. It's only a buzz word to attract more users, IMHO.

But an important one, since the whole rolling concept is based on the
fact to attract users.

> It will
> use packages from unstable, as testing does right now. So, if a bug is
> found in a package provided by "rolling", it's very likely to be found
> in sid as well.

Right, maybe I should have been more precise. Read it as: Encourage
maintainers to fix (important) bugs in a (more) timely manner (if
possible). I admit this is the most important objection most of you seem
to have, opposing the idea.

> Who said that? which documentation are you talking about? Whoever told
> you that is wrong.

Just skip through several official FAQs, documentations, guidelines and
so on. All those sources strongly indicate to use nothing but stable if
in doubt. The whole concept of a rolling distributions is to attract
users /not/ being satisfied with the concept stable has to offer,
because of several random reasons you might know like "too old software"
and so on.

On the other hand one should be very careful to suggest people in
official documentation to use something which has not evidently proven
to work over long term. Maybe some compromise would be appropriate here.


- -- 
with kind regards,
Arno Töll
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNvBLjAAoJEMcrUe6dgPNt/9gQALyedErCxKVYaO1XmTiZYEwa
1DIXUxYJzRSjz4J8BwKleJ681/2+26FkIFpIlA89IZlsEybekZ5d47FpBFsF1BHR
MEC8CPRI89ZMhT/u7vWxCt8RIpvyPyQfJx5e5NpZdvYH+LNuk2K4x7tJzfuV8lHm
lkd9GpVH1gjpGTLgWGH4xqf5zEcekwqetQ9nHjfdAxIdfAsNbBgBDSiWSLcNCLa3
+erBeDg9mRI5MpeqKM353PM0XEtHJyeepTO8U0RLJ2FjDkaPHLCAgz2cvELq7GGP
US7vZ7jkQ7XClj44bzYqx1NkXyI8Y6IsngNzbw3QiGv3YzDQA6DpMPiqqS6z0L6o
OqNiEtPduwxp2QaFPTSMF6WR1xv4cTTJKhznj4uMPBAMF9W17a2s7WGU9UCQtjk6
SG/VX9/s+nGjcNFDvLXQJVxB8IVum02IcGKRlUalyvROd1ywrifhdjFmCA8V3NTi
45b3xc7wRYxcQ9MPoAK5eplFJic44vpsFikJ5rUogiSJn9lh5o1wSDtCFWn72uwZ
BHvvIj4IL/RCeYm18ZrvRdLyBsE//NobYL2zhBZTBWlEya4FUTc7FfQluVvh04ip
OoHZSsHleqnxiMDJZxiQIKIOBDf1IVzhmhsjojUZ47adgu4B9qmXGJoQVXtEj5jl
2ZORgD7i6+X1lcru4mmM
=K7Ht
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc12e4.2060...@toell.net

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 03:47 PM, Arno Töll wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1

On 30.04.2011 15:24, Mehdi Dogguy wrote:

On 04/30/2011 03:16 PM, Arno Töll wrote:

Perhaps that's a not a particular fair demand. See, crucial for
Raphaels idea as I read it is "official" support to users using a
rolling distribution. For both, user support and bug fixing of
course.



In this particular case, the "official" bit won't change anything
for developers. It's only a buzz word to attract more users, IMHO.


But an important one, since the whole rolling concept is based on the
fact to attract users.



They can do it. Let me recall you that Backports was not official until
recently and they proven to the project that it was very useful and needed.
Then, it got integrated officially into Debian and was advertised as such.
"rolling" can follow the same route to start as well.


It will use packages from unstable, as testing does right now. So,
if a bug is found in a package provided by "rolling", it's very
likely to be found in sid as well.


Right, maybe I should have been more precise. Read it as: Encourage
maintainers to fix (important) bugs in a (more) timely manner (if
possible). I admit this is the most important objection most of you
seem to have, opposing the idea.



I don't care much about the name, etc… I think that advertising testing
as ready to users, while we don't have an installer for it is the big
problem. The second problem is the "frozen" (temporary) suite. Some
assume that "frozen" is part of "rolling". Some others argue that
"rolling" is just about advertising about a new name for testing.

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc14fb.8080...@dogguy.org

Re: Bits from the Release Team - Kicking off Wheezy

[George Danchev]

On Friday 29 April 2011 11:46:30 Lucas Nussbaum wrote:
> On 29/04/11 at 10:23 +0200, Holger Levsen wrote:
> > 2. In the past there used to be two rather opposites use-cases of
> > testing: some (luckely more than just the release team) see it as a tool
> > to develop stable. Others see it (mostly) as a usable distribution.
> > I'm unconvinced that splitting testing into rolling+testing will benefit
> > both use cases. (And I think this is shared rather widely in this
> > thread.)
> 
> I think that the proposal is to:
> - rename 'testing' to 'rolling' to make it clear that it's usable as a
>   rolling release

It is also possible that a 'rename' brings no more value, but a confusion to 
the users for unpredictable amount of time.

> - add a new 'frozen' suite, used only during freezes, to prepare the
>   next stable release

So, if I need to fix an RC bug during the freeze, I'll upload to unstable, then 
release managers wait for it to enter rolling and cherry-pick it from there; 
or do they cherry-pick directly from unstable, skipping rolling;
or do they cherry-pick from as they find fit in a mixed fashion.

I can see that you struggle to find a solution, which is good, but all these 
additions of levels started to look like a joke, eventually wasting both 
astronomic, human and machine time.

-- 
pub 4096R/0E4BD0AB 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104301724.38169.danc...@spnet.net

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 04:24 PM, George Danchev wrote:

- add a new 'frozen' suite, used only during freezes, to prepare
the next stable release


So, if I need to fix an RC bug during the freeze, I'll upload to
unstable, then release managers wait for it to enter rolling and
cherry-pick it from there; or do they cherry-pick directly from
unstable, skipping rolling; or do they cherry-pick from as they find
fit in a mixed fashion.



Better. Quite rapidly, we won't be able to cherry-pick from rolling
(which is what we used to do up to now). And, the proposal is to ask
maintainers to upload the fixed package to $codename-proposed-updates.

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc1e59.5030...@dogguy.org

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Arno Töll (deb...@toell.net) [110430 15:17]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 30.04.2011 14:36, Andreas Barth wrote:
> > Feel free to use rolling.debian.net, set it up and have success. Like
> > aj did with setting up testing (after frozen has burned IIRC three
> > release managers without an release).
> 
> Perhaps that's a not a particular fair demand. See, crucial for Raphaels
> idea as I read it is "official" support to users using a rolling
> distribution. For both, user support and bug fixing of course.

Actually, it worked quite well for both volatile and backports to
start as a non-official service. As well as building packages in
non-free. And lots of other stuff which was implemented.

Why shouldn't it work for rolling.d.n?

> IRC support channels and all they get is "Sorry, we don't support
> rolling.debian.net, get lost and bother $r_d_n_people"; documentation
> suggests "don't use anything but stable" and maintainer don't care about
> fixing bugs which could improve r.d.n stability.

That's the way it was with volatile and backports, which both have
become official sevices by now.

Why should that be different for rolling.d.n?


> I agree. This does not imply others should sabotage his efforts
> actively.

That's an interessting claim. Please show where someone has sabotaged
rolling.d.n.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430144824.gv15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[George Danchev]

On Saturday 30 April 2011 17:36:09 Mehdi Dogguy wrote:
> On 04/30/2011 04:24 PM, George Danchev wrote:
> >> - add a new 'frozen' suite, used only during freezes, to prepare
> >> the next stable release
> > 
> > So, if I need to fix an RC bug during the freeze, I'll upload to
> > unstable, then release managers wait for it to enter rolling and
> > cherry-pick it from there; or do they cherry-pick directly from
> > unstable, skipping rolling; or do they cherry-pick from as they find
> > fit in a mixed fashion.
> 
> Better. Quite rapidly, we won't be able to cherry-pick from rolling
> (which is what we used to do up to now). And, the proposal is to ask
> maintainers to upload the fixed package to $codename-proposed-updates.

That work flow might easily morph in spagnetti, as chances are high that the 
maintainer has to upload a fix package to $codename-proposed-updates and 
hopefully another one for sid, where the version might be ever newer (odds are 
high for a different fix), in order to keep sid in sync, because stuff from sid 
flows into rolling... and then again the fix in sid will lag behind. We won't 
rename sid as 'stalling' at some point, right :-)

(no need to CC, I'm subscribed, cheers.)

-- 
pub 4096R/0E4BD0AB 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104301753.01587.danc...@spnet.net

Re: Bits from the Release Team - Kicking off Wheezy

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.04.2011 16:48, Andreas Barth wrote:
> Actually, it worked quite well for both volatile and backports to
> start as a non-official service. As well as building packages in
> non-free. And lots of other stuff which was implemented.
> 
> Why shouldn't it work for rolling.d.n?

I didn't say r.d.n should start as official service immediately, I said
one should give interested people the possibility to provide a reliable
service to prove their idea works.

This is a bit different than backports.d.o, which is a pure optional
service extension to traditional repositories. If there is a backport
for a certain package good, if not: no problem neither from a conceptual
perspective.
However for a rolling distribution one would not provide some packages
in addition to those regularly available through repositories, but
provide official maintainer uploads from unstable after a while /and
support them/. At least the latter calls the original maintainer to
account again, even outside of freeze periods and perhaps in a more
timely manner as Sid requires this by people by now.

Don't get me wrong, I don't claim this wouldn't be case by now already
and many maintainers do a great job anyway. My point is that Raphaels
approach needs itself a certain service level in order to provide the
same service level to rolling users itself.
This is, in turn what you call from him in order to accept a potential
rolling branch. How should he though, if people are not willing to help
at least passively which gives him a chance to provide a good service?

> 
>> I agree. This does not imply others should sabotage his efforts
>> actively.
> 
> That's an interessting claim. Please show where someone has sabotaged
> rolling.d.n.
> 

Since it does not exist yet, no one did. I apologize for my words which
have been a bit more rude than necessary. I think I outlined above what
I mean.

- -- 
with kind regards,
Arno Töll
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNvC7AAAoJEMcrUe6dgPNtrFMQAJrs0lk2w2QKjn41t/s0usKb
+Y0+8Xt6CBzEv9gRCKJdK5aKadxDHuDAny9on87sLdQLb6AiHii6/IoDz6PFjH81
PJyGS5U16iEGKPat3x9D6D8cqCjn7J3pBLs5BNEyoLD3Xp9UKKL5OX+4Vv6fub/T
x1SHra+dgg1uuAo+d1I7s5BG0HFOP34mVw7OxPb39C++ZjC/eYrS10ahBKh/YAtS
WttklqSgPQ1oI0/kuUo0zZrbHHwnH1E/q6QDqakqmt7FLkpoxAVHP2kLmExrXGh3
1HiKAzEwz57WQUrexY6ImKPLkawnQEa7Z5mRmem5F/EevqBtNb0gGZ1ZtVkpKZal
4peMcnoBKYzMcmi3c8rO5aeDxxiMg9lXgXPdKVg/NQd+TbVPkNKfZamcyHPbxCFR
z40HNOk4ZoOASmPIxob0bdWr+vZIGa8/wWsYOycJoIXx+jthHXqlHFk5Uxm38vRV
0iK94gH8D14VKD2hrlsKum5H1eG7TRKvotOLpLjyJ/eWlS9xkdka6nrEdf2glfwB
JwgoEsrg7Mq45dPWnKamIx8qd+HoSQ3gUurbGv1AqDfWK9vuj/QGHnkAmrXZ6uwr
Iiycg9CibBX9L0Sj/dlo6p/OxHsP8F/0E/jimFkq0FIbx6Q1qTyNNThrEa0fO0Uv
8TPGx62dtdNZAgn8rmaY
=9e4q
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc2ec0.4030...@toell.net

Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 04/30/2011 05:46 PM, Arno Töll wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1

On 30.04.2011 16:48, Andreas Barth wrote:

Actually, it worked quite well for both volatile and backports to
start as a non-official service. As well as building packages in
non-free. And lots of other stuff which was implemented.

Why shouldn't it work for rolling.d.n?


I didn't say r.d.n should start as official service immediately, I
said one should give interested people the possibility to provide a
reliable service to prove their idea works.

This is a bit different than backports.d.o, which is a pure optional
 service extension to traditional repositories. If there is a
backport for a certain package good, if not: no problem neither from
a conceptual perspective. However for a rolling distribution one
would not provide some packages in addition to those regularly
available through repositories, but provide official maintainer
uploads from unstable after a while /and support them/. At least the
latter calls the original maintainer to account again, even outside
of freeze periods and perhaps in a more timely manner as Sid
requires this by people by now.

Don't get me wrong, I don't claim this wouldn't be case by now
already and many maintainers do a great job anyway. My point is that
Raphaels approach needs itself a certain service level in order to
provide the same service level to rolling users itself. This is, in
turn what you call from him in order to accept a potential rolling
branch. How should he though, if people are not willing to help at
least passively which gives him a chance to provide a good service?



Testing was implemented outside Debian's infrastructure before becoming
official too. I don't think it's different from "rolling", especially
when all the work is already done (migration scripts, etc…)

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbc30ff.8000...@dogguy.org

Re: mozilla.d.n (was: Bits from the Release Team - Kicking off Wheezy)

[Mike Hommey]

On Sat, Apr 30, 2011 at 02:18:06PM +0200, Andreas Barth wrote:
> * Mike Hommey (m...@glandium.org) [110430 13:28]:
> > On Sat, Apr 30, 2011 at 01:06:57PM +0200, Andreas Barth wrote:
> > > * Mike Hommey (m...@glandium.org) [110430 12:16]:
> > > > That being said, it would be really helpful to be able to get buildds
> > > > to build the mozilla.d.n packages...
> > > 
> > > Would it work to build the packages in unstable? If so, why not
> > > uploading them to experimental and re-branding them in mozilla.d.n?
> > 
> > I'm not sure to understand what you are suggesting.
> 
> 
> The question is how could we get the packages built so that we don't
> need to setup yet another buildd suite (or more general, I want to
> avoid setting one suite per package). Of course, ppa would come to
> rescue here, and it's really only a question of "someone would need to
> write the code".
> 
> I would propose the following for now:
> 
> 1. For unstable users, upload the packages to experimental, and
> extract them from there once they are built.
> 2. For testing users, do the same (but only take the packages if they
> have dependencies fullfilable in testing)
> 3. For stable and oldstalbe users, upload the packages to bpo, and
> extract them from there.
> 
> All that can (and should) be scripted of course.

Ah, so that's an hypothetical case, involving minimal changes to the
current buildd system. But it currently isn't possible.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430155720.ga30...@glandium.org

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Arno Töll (deb...@toell.net) [110430 17:46]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 30.04.2011 16:48, Andreas Barth wrote:
> > Actually, it worked quite well for both volatile and backports to
> > start as a non-official service. As well as building packages in
> > non-free. And lots of other stuff which was implemented.
> > 
> > Why shouldn't it work for rolling.d.n?
> 
> I didn't say r.d.n should start as official service immediately, I said
> one should give interested people the possibility to provide a reliable
> service to prove their idea works.
>
> This is a bit different than backports.d.o, which is a pure optional
> service extension to traditional repositories. If there is a backport
> for a certain package good, if not: no problem neither from a conceptual
> perspective.

Eh, sorry, but that's not true. If you upload packages to backports,
someone has to take care about bugs, security issues etc. Just the
same as everywhere else.

But one can't expect that it's enough to say "great idea, but someone
else will do it". If someone wants to setup rolling.d.n, fine. I'm
happy to help setting up britney, release foo, whatever.  But someone
has to take responsibility, and not just make it a fire and forget
thing.

> However for a rolling distribution one would not provide some packages
> in addition to those regularly available through repositories, but
> provide official maintainer uploads from unstable after a while /and
> support them/.

And why can't someone just do it? "Support them" means: "support
them".  Yes, that's an effort. If someone is willing to support that,
fine. Then do it. If not, stop bugging other people to do it.

> At least the latter calls the original maintainer to
> account again, even outside of freeze periods and perhaps in a more
> timely manner as Sid requires this by people by now.

Why? Wouldn't NMUs be allowed to be done? And - just convince the
maintainers that this is time spent well. But also that is work - I
have done that long enough for testing.


Sorry, but this all sounds to me "someone else should do the work".
And that is not how it works.


If someone wants to setup rolling.d.n, do it. If not, then don't. But
that's it.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430182922.gw15...@mails.so.argh.org

Re: mozilla.d.n

[Andreas Barth]

* Mike Hommey (m...@glandium.org) [110430 17:57]:
> On Sat, Apr 30, 2011 at 02:18:06PM +0200, Andreas Barth wrote:
> > * Mike Hommey (m...@glandium.org) [110430 13:28]:
> > > On Sat, Apr 30, 2011 at 01:06:57PM +0200, Andreas Barth wrote:
> > > > * Mike Hommey (m...@glandium.org) [110430 12:16]:
> > > > > That being said, it would be really helpful to be able to get buildds
> > > > > to build the mozilla.d.n packages...
> > > > 
> > > > Would it work to build the packages in unstable? If so, why not
> > > > uploading them to experimental and re-branding them in mozilla.d.n?
> > > 
> > > I'm not sure to understand what you are suggesting.
> > 
> > 
> > The question is how could we get the packages built so that we don't
> > need to setup yet another buildd suite (or more general, I want to
> > avoid setting one suite per package). Of course, ppa would come to
> > rescue here, and it's really only a question of "someone would need to
> > write the code".
> > 
> > I would propose the following for now:
> > 
> > 1. For unstable users, upload the packages to experimental, and
> > extract them from there once they are built.
> > 2. For testing users, do the same (but only take the packages if they
> > have dependencies fullfilable in testing)
> > 3. For stable and oldstalbe users, upload the packages to bpo, and
> > extract them from there.
> > 
> > All that can (and should) be scripted of course.
> 
> Ah, so that's an hypothetical case, involving minimal changes to the
> current buildd system. But it currently isn't possible.

Why not? Or - what is the blocker? (If there is some easily removable,
I'm happy to remove it.)



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430183026.gx15...@mails.so.argh.org

Re: mozilla.d.n

[Mike Hommey]

On Sat, Apr 30, 2011 at 08:30:26PM +0200, Andreas Barth wrote:
> * Mike Hommey (m...@glandium.org) [110430 17:57]:
> > On Sat, Apr 30, 2011 at 02:18:06PM +0200, Andreas Barth wrote:
> > > * Mike Hommey (m...@glandium.org) [110430 13:28]:
> > > > On Sat, Apr 30, 2011 at 01:06:57PM +0200, Andreas Barth wrote:
> > > > > * Mike Hommey (m...@glandium.org) [110430 12:16]:
> > > > > > That being said, it would be really helpful to be able to get 
> > > > > > buildds
> > > > > > to build the mozilla.d.n packages...
> > > > > 
> > > > > Would it work to build the packages in unstable? If so, why not
> > > > > uploading them to experimental and re-branding them in mozilla.d.n?
> > > > 
> > > > I'm not sure to understand what you are suggesting.
> > > 
> > > 
> > > The question is how could we get the packages built so that we don't
> > > need to setup yet another buildd suite (or more general, I want to
> > > avoid setting one suite per package). Of course, ppa would come to
> > > rescue here, and it's really only a question of "someone would need to
> > > write the code".
> > > 
> > > I would propose the following for now:
> > > 
> > > 1. For unstable users, upload the packages to experimental, and
> > > extract them from there once they are built.
> > > 2. For testing users, do the same (but only take the packages if they
> > > have dependencies fullfilable in testing)
> > > 3. For stable and oldstalbe users, upload the packages to bpo, and
> > > extract them from there.
> > > 
> > > All that can (and should) be scripted of course.
> > 
> > Ah, so that's an hypothetical case, involving minimal changes to the
> > current buildd system. But it currently isn't possible.
> 
> Why not? Or - what is the blocker? (If there is some easily removable,
> I'm happy to remove it.)

Currently, if you upload something to unstable, well, you end up with it
in unstable... I don't want that for mozilla.d.n packages.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430183911.ga10...@glandium.org

Re: Bits from the Release Team - Kicking off Wheezy

[Raphael Hertzog]

Hi Andreas,

On Sat, 30 Apr 2011, Andreas Barth wrote:
> Actually, it worked quite well for both volatile and backports to
> start as a non-official service. As well as building packages in
> non-free. And lots of other stuff which was implemented.
> 
> Why shouldn't it work for rolling.d.n?

1/ The current discussion is mainly about not freezing testing. For the
wheezy freeze I could setup rolling.debian.net with a britney migrating
stuff from unstable. And I could ask developers to upload new upstream
versions to unstable.

But then all the concerns that you raised would still be applicable and
the fact that it's done in a .net service doesn't protect the release team
from the bad consequences.

2/ The discussion is also about better supporting testing using t-p-u more
extensively to bring important fixes (or important new upstream versions)
that are blocked in unstable. It would be unreasonable to ask Debian
developers to support testing and rolling.debian.net in parallel.


3/ rolling.debian.net would only be interesting to evaluate the few
suggestions I made concerning the migration rules that we use (and which I
explicitly said that they should not be considered in the current
discussion… but that never works :)). But then I can run a britney and
collect statistics without setting up rolling.debian.net for public
consumption.


For all those reasons, I believe the only sane way to go forward is to
discuss with the release team to identify what needs to happen so that
not freezing testing can become a serious possibility.

To better structure the discussion, and make incremental progress, Sean
and me have decided to draft a DEP on this topic.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430185039.ga25...@rivendell.home.ouaza.com

Re: Bits from the Release Team - Kicking off Wheezy

[Neil McGovern]

On Sat, Apr 30, 2011 at 08:50:39PM +0200, Raphael Hertzog wrote:
> 2/ The discussion is also about better supporting testing using t-p-u more
> extensively to bring important fixes (or important new upstream versions)
> that are blocked in unstable. It would be unreasonable to ask Debian
> developers to support testing and rolling.debian.net in parallel.
> 

Indeed. Personally, I believe it would also be unreasonable to ask DDs,
and indeed the release, security, and FTP teams to support testing and
rolling. Especially before it has been proven to be negligible extra
effort.

> For all those reasons, I believe the only sane way to go forward is to
> discuss with the release team to identify what needs to happen so that
> not freezing testing can become a serious possibility.
> 

For reference, speaking as a RM but not on behalf of the entire release
team, I believe that the amount of work you are seemingly trying to
prescribe on other people means that I cannot support this proposal in
its current form. I understand the desire not to freeze, although I
think we disagree about the importance of having a high quality release.

> To better structure the discussion, and make incremental progress, Sean
> and me have decided to draft a DEP on this topic.
> 

A complete aside: I have yet to see DEPs being anything but a structured
way to bikeshed. However, if you wish to go down this route, feel free.
This does bring me full circle back to the start of my mail - if you
want to push this, that's fine. But please don't try and make extra work
for others.

Thanks,
Neil
-- 
< linuxpoet> rails is a perversion
< mc> someone who use pgsql as calculator shouldnt talk of perversion.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430194824.gi...@feta.halon.org.uk

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Raphael Hertzog (hert...@debian.org) [110430 20:51]:
> Hi Andreas,
> 
> On Sat, 30 Apr 2011, Andreas Barth wrote:
> > Actually, it worked quite well for both volatile and backports to
> > start as a non-official service. As well as building packages in
> > non-free. And lots of other stuff which was implemented.
> > 
> > Why shouldn't it work for rolling.d.n?
> 
> 1/ The current discussion is mainly about not freezing testing. For the
> wheezy freeze I could setup rolling.debian.net with a britney migrating
> stuff from unstable. And I could ask developers to upload new upstream
> versions to unstable.

Why don't you just not freeze rolling.d.n?

Or do you want to override the current release team and force them to
not freeze testing? If the second, you should make clear that you want
to overrule a decision by the delegates.

> 2/ The discussion is also about better supporting testing using t-p-u more
> extensively to bring important fixes (or important new upstream versions)
> that are blocked in unstable. It would be unreasonable to ask Debian
> developers to support testing and rolling.debian.net in parallel.

Well, they could just ... use t-p-u for that. No need to discuss, just
do it.


> 3/ rolling.debian.net would only be interesting to evaluate the few
> suggestions I made concerning the migration rules that we use (and which I
> explicitly said that they should not be considered in the current
> discussion… but that never works :)). But then I can run a britney and
> collect statistics without setting up rolling.debian.net for public
> consumption.

No. It could also continue to run a migration from unstable during the
freeze phases. If it works, good.



> For all those reasons, I believe the only sane way to go forward is to
> discuss with the release team to identify what needs to happen so that
> not freezing testing can become a serious possibility.

Oh, you discuss with the release team? In that case, it might make
sense to send them a mail instead of hoping that someone points out
the discussion to them. At least, that would be the normal polite way
to do things.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430195525.gy15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[sean finney]

Hi Andreas,

On Sat, Apr 30, 2011 at 08:29:22PM +0200, Andreas Barth wrote:
> But one can't expect that it's enough to say "great idea, but someone
> else will do it". If someone wants to setup rolling.d.n, fine. I'm
> happy to help setting up britney, release foo, whatever.  But someone
> has to take responsibility, and not just make it a fire and forget
> thing.

In case I wasn't totally clear, or it got lost in the noise, etc,
in <20110430072644.ga15...@cobija.connexer.com> I tried to (again)
make it clear that I actually am going to chip in on this.  Raphaël has
also said that he'd be able to help up the services (which is good,
because I'm totally unfamiliar with most of them).  I also volunteered
to join up as an assistant/lackey with the release team under the
*current* process, since that would be good for me to get some first-hand
experience, and hey, some extra free labor for you guys :)

I think the goal would be to set something up, show that it works for
all the strange/difficult transitions/corner-casees, demo the whole
process with some "fake" releases, etc.  

And even better, since the whole point is to have a system that works with
an unfrozen testing, we will have a real live unstable/testing that will
be paying no attention to our efforts, so we shoudl get a very good idea of
how fast things would diverge, and how difficult
cross-porting/cherry-picking/etc would be.

> If someone wants to setup rolling.d.n, do it. If not, then don't. But
> that's it.

I think this will happen in some short time.  Gonna put a little more
time/effort into the proposal first though (DEP-10, coming soon to
a dep.debian.net near you).


sean


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430195557.ga17...@cobija.connexer.com

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Steve Langasek]

On Sun, Apr 24, 2011 at 07:14:57PM +0200, Stephen Kitt wrote:
> > So I would be opposed to making such a change in policy for the time being;
> > I think cross-compilers should stick with the traditional cross-compiler
> > directories and stay away from the multiarch directories until we have more
> > practical experience with multiarch under our belts and can make some
> > educated decisions about how we want this to all fit together.

> Would it make any sense then to add an exception for traditional
> cross-compiler directories, or should cross-compiling library packages simply
> continue using lintian overrides?

I don't think such an exception should be codified into Debian policy
either; cross compilers have been doing this since before there was an FHS
and no one has bothered to bless it before now, so I don't think we should
do so when we might finally be near the end of needing these separate
non-FHS directories.

> One last question: without considering multiarch, what is the situation
> regarding headers? Is the proposal in http://bugs.debian.org/542865 still the
> intended approach, or is there another solution?

There is a discussion at
,
 about how to
handle headers.  No bug report or patch filed yet.

-- 
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430200620.ga14...@virgil.dodds.net

Re: Bits from the Release Team - Kicking off Wheezy

[sean finney]

Hi Neil,

On Sat, Apr 30, 2011 at 08:48:24PM +0100, Neil McGovern wrote:
> Indeed. Personally, I believe it would also be unreasonable to ask DDs,
> and indeed the release, security, and FTP teams to support testing and
> rolling. Especially before it has been proven to be negligible extra
> effort.

Indeed.  I'd hope that we could put something together that people would
*want* to adopt.  I totally get that the RM team is skeptical.

> A complete aside: I have yet to see DEPs being anything but a structured
> way to bikeshed. However, if you wish to go down this route, feel free.
> This does bring me full circle back to the start of my mail - if you
> want to push this, that's fine. But please don't try and make extra work
> for others.

While just about any technical discussion on -devel will have its tangents
and its non sequitors, I think we *have* had some good stuff come out of the
DEP's, so I disagree there.  For example, DEP-3 and DEP-5 have (indeed,
after quite a bit of bikeshedding) resulted in some nice pseudo-standards
that are gaining increasing traction/usage.

And even the DEP's that are REJECTED will stand as documentation of
something that someone tried once, and maybe didn't work out for some
reason, and could serve as a basis for ideas later on, which is an
order of magnitude better than an infrequently recurring ML thread
where everyone forgots all the gotchas and details from the last time
it was discussed n months ago.


sean


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430201149.gb17...@cobija.connexer.com

Re: mozilla.d.n

[Philipp Kern]

On 2011-04-30, Mike Hommey  wrote:
>> Why not? Or - what is the blocker? (If there is some easily removable,
>> I'm happy to remove it.)
> Currently, if you upload something to unstable, well, you end up with it
> in unstable... I don't want that for mozilla.d.n packages.

Or maybe to clarify to Andi:  Currently Mike ships multiple versions of
iceweasel on mozilla.d.n (3.6 and 4.0).  Those are not co-installable with
eachother and not with what's currently in the archive.  This means that
whenever you'd use the current suites with something not co-installable
you end up with the newer version being present in that suite.

So a simple "pull from X" won't work.

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniror8b.kn2.tr...@kelgar.0x539.de

Bug#624713: general: linux-2.6.30-2 has no headers package

[sergey]

Package: general
Severity: normal

I install Debian 6 from one of RC2 CD's. Kernel 2.6.32-5 want not
work on my machine. But I was able to install 2.6.30-2 kernel, it works
fine. But now I have a problem with this kernel: it has no appropriate 
headers package. Without headers I can't run VirtualBox.

-- System Information:
Debian Release: 6.0.1
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430203134.4804.55753.report...@fc3.ru

Re: Bug#624713: general: linux-2.6.30-2 has no headers package

[Ben Hutchings]

On Sun, 2011-05-01 at 00:31 +0400, sergey wrote:
> Package: general
> Severity: normal
> 
> I install Debian 6 from one of RC2 CD's. Kernel 2.6.32-5 want not
> work on my machine. But I was able to install 2.6.30-2 kernel, it works
> fine. But now I have a problem with this kernel: it has no appropriate 
> headers package. Without headers I can't run VirtualBox.

We no longer support Linux 2.6.30, and it has many known security flaws
that have been fixed in the versions that we continue to support (2.6.32
in Debian 6.0 and 2.6.26 in Debian 5.0).

Please retry the installation using Debian 6.0.1.  If the current kernel
based on Linux 2.6.32 does not work for you, please report *that* as a
bug.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#624713: marked as done (general: linux-2.6.30-2 has no headers package)

[Debian Bug Tracking System]

Your message dated Sat, 30 Apr 2011 21:40:14 +0100
with message-id <1304196014.2833.57.camel@localhost>
and subject line Re: Bug#624713: general: linux-2.6.30-2 has no headers package
has caused the Debian Bug report #624713,
regarding general: linux-2.6.30-2 has no headers package
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
624713: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624713
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal

I install Debian 6 from one of RC2 CD's. Kernel 2.6.32-5 want not
work on my machine. But I was able to install 2.6.30-2 kernel, it works
fine. But now I have a problem with this kernel: it has no appropriate 
headers package. Without headers I can't run VirtualBox.

-- System Information:
Debian Release: 6.0.1
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--- End Message ---
--- Begin Message ---
On Sun, 2011-05-01 at 00:31 +0400, sergey wrote:
> Package: general
> Severity: normal
> 
> I install Debian 6 from one of RC2 CD's. Kernel 2.6.32-5 want not
> work on my machine. But I was able to install 2.6.30-2 kernel, it works
> fine. But now I have a problem with this kernel: it has no appropriate 
> headers package. Without headers I can't run VirtualBox.

We no longer support Linux 2.6.30, and it has many known security flaws
that have been fixed in the versions that we continue to support (2.6.32
in Debian 6.0 and 2.6.26 in Debian 5.0).

Please retry the installation using Debian 6.0.1.  If the current kernel
based on Linux 2.6.32 does not work for you, please report *that* as a
bug.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part
--- End Message ---

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Steve Langasek]

On Sun, Apr 24, 2011 at 10:46:40PM +0100, Wookey wrote:
> I expect the multiarch paths to replace the 'traditional
> cross-compiling' paths in due course for all target architectures,
> including ones that aren't Debian-suported (i.e currently
> mingw-whatever-you-call-it, avr32, msp430), for both native use and
> cross-compiling. Steve will have to explain to me why we might want to
> use different paths for non-self-hosting arches. It seems to me that
> having one canonical place to look for arch-dependent files is good
> whether you want them for running or for (cross-)building.

It's not that non-self-hosting archs should be treated differently from
self-hosted archs, but that they should be treated the *same* including the
requirement that multiarch directories be reserved for packages of the
corresponding architecture... even if there is no support for such a
corresponding architecture in dpkg or in the archive.  This future-proofs
the packages for the time being so that if at a later date we *do* add these
architectures to the archive as architectures, we don't end up with the
maintainers of all the base libraries having to add lots of "Conflicts:
libc6-msp430 [msp430]" style conflicts to ensure a smooth upgrade.

> But we do need to proceed carefully in order to get this right, and
> the cross-only arches are a little way down our list of issues :-)

Right.  It may be nothing but wishful thinking to say that we might have an
msp430 partial architecture in the archive some time in the future and that
it will DTRT.  But in the meantime I think it's best to take it slow and not
paint ourselves into any corners.

-- 
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430205110.gb14...@virgil.dodds.net

Re: Bits from the Release Team - Kicking off Wheezy

[Lucas Nussbaum]

On 30/04/11 at 17:24 +0300, George Danchev wrote:
> On Friday 29 April 2011 11:46:30 Lucas Nussbaum wrote:
> > On 29/04/11 at 10:23 +0200, Holger Levsen wrote:
> > > 2. In the past there used to be two rather opposites use-cases of
> > > testing: some (luckely more than just the release team) see it as a tool
> > > to develop stable. Others see it (mostly) as a usable distribution.
> > > I'm unconvinced that splitting testing into rolling+testing will benefit
> > > both use cases. (And I think this is shared rather widely in this
> > > thread.)
> > 
> > I think that the proposal is to:
> > - rename 'testing' to 'rolling' to make it clear that it's usable as a
> >   rolling release
> 
> It is also possible that a 'rename' brings no more value, but a confusion to 
> the users for unpredictable amount of time.
> 
> > - add a new 'frozen' suite, used only during freezes, to prepare the
> >   next stable release
> 
> So, if I need to fix an RC bug during the freeze, I'll upload to unstable, 
> then 
> release managers wait for it to enter rolling and cherry-pick it from there; 
> or do they cherry-pick directly from unstable, skipping rolling;
> or do they cherry-pick from as they find fit in a mixed fashion.

Why would it be the release team's responsibility to cherry-pick from
anywhere? It is the maintainer's responsibility to prepare packages that
are suitable for the next stable release. I don't see why this would
change.

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430222710.ga9...@xanadu.blop.info

Re: Bits from the Release Team - Kicking off Wheezy

[Neil McGovern]

On Sun, May 01, 2011 at 12:27:10AM +0200, Lucas Nussbaum wrote:
> Why would it be the release team's responsibility to cherry-pick from
> anywhere? It is the maintainer's responsibility to prepare packages that
> are suitable for the next stable release. I don't see why this would
> change.
> 

Hi Lucas,

I feel that this mail does somewhat identify what may be the core
misunderstanding on what is done in the release team. At the moment,
this is exactly what we do, and I strongly feel one of the reasons that
Debian has a reputation for stable releases.

In an ideal world maintainers would submit bug free packages, but this
simply does not happen. As a maintainer of a package which was removed
from the last stable release, I know only too well the apathy with
support for stable at times, but this does NOT mean we should try and
circumvent it.

The manual checking of packages ensures a level of stability that other
distributions are unable to match (IMO, YMMV etc).


(Feel free to skip the rest of the mail, it is all personal opinion from
now on...)
This is one of the things that makes Debian what it is, and makes me
want to be involved with the project. We don't chase after the latest
and greatest new shiny thing. We don't boast about the number of users
we have, or how many systems we run. We do what is legally *right*,
technically *correct*, and morally *sound*.

If this is ever forgotten, we simply become a Linux distribution, rather
than the Debian project.

Neil
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430225716.gj...@feta.halon.org.uk

Re: Bits from the Release Team - Kicking off Wheezy

[Pierre Habouzit]

On Sat, Apr 30, 2011 at 12:28:06PM +0200, Stefano Zacchiroli wrote:
> Size is just one ingredient. There are plenty of other ways to diminish
> barrier to deploy big changes in Debian: wider commit access rights,
> larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly,
> several Debian derivatives have decide to pursue those other ways and
> one might argue that they have done so learning from Debian experience.)

[...]

Oh yes, you really want to "attract" new contributors ? build debhub.com
(as in github) and force everyone to package stuff in there. Let people
propose patches, packaging new upstreams and so forth using merge
requests (as in github), and there you'll be attractive. We would have
invented "social packaging" (so 2.0-ish), and also lower the difficulty
to contribute patches in a more efficient way than the BTS (sorry but
the BTS *isn't* a tractable way to do heavy lifting, it's only good to
send small unrelated patches).

Also, I read about the idea of bringing PPA to Debian (which IMO is a
good idea, I know lots of people around me — me including for chromium
at the time when it wasn't in Debian yet — using Debian + PPA
repositories, it's useful). Well, PPA can be built atop "forking"
packages.


Sadly this will probably never happen because we're too large to decide
and agree upon a single VCS. And building something like that wouldn't
be successful with 4 very different VCSes (svn, git, hg, bzr). So
probably just a dream.


FWIW I think that "rolling" or "CUT" miss the point entirely. As a
Debian user I use stable on my servers (with a few backports for the 3-4
things I need bleeding edge for). For my desktop I use unstable, and
when that breaks (which is *very* rare, really) I go to snapshots and go
back a few versions. I couldn't care about testing any less. And at
work, every person I know either uses just stable or does the same as
me. I know no testing user around me. Of course I'm not pretending I
know the absolute Truth, but well, I find this whole "users want testing
badly" thing dubious.

No what we want is probably to be attractive to developers, while
keeping our standards about the stable release, which is what really
matters. And to do that, well, what we need is to make working for
Debian easier. Not harder. rolling is making working for Debian harder,
hence is a bad proposal. Harder because it means people will have more
work for a package. Maintainers are (me included) often too lazy to
prepare Stable updates because it's a PITA to have to work on a 1-yo
version of the package. Why would they be more motivated to work on
testing packages?

No we should focus instead on making packaging easier, not adding new
constraints, new goals. Here are a few thoughts on how to do that.

  - enable PPA-like stuff, auto-built (best-effort).

  - link that PPA stuff to the main repository in a way that "merging"
PPA into unstable is just a matter of one single command, or a few.

  - make it easy for users to subscribe to PPAs, meaning you have to
have some kind of directory of PPAs with categorization (quite
stable, very experimental, gnome stuff, mozilla stuff, …whatever any
valuable information for the user IOW).

  - PPA should focus on:
  * co-installability when endurable;
  * documented and working rollback to unstable (IOW downgrading a
package to unstable when co-installability is not possible
should work well enough, idealy using pinning and apt, but a
documented procedure is good enough too).

  - get rid of experimental that would mostly become useless as PPA
would clearly be a superset of the features.

  - make it easy to create new PPA repositories (aka "forks") for every
DD. Of course some attention not to overload buildd resources is
important so maybe "forks" should be restricted to a few
architectures instead of all of them.

  - link anything that is uploaded to this PPA-like stuff tied to a
public VCS with some kind of VCS-agnostic wrapper that allow
maintainers to look at the patches corresponding to a given "forked"
PPA, allowing him to cherry-pick/merge IOW take what he thinks is
worthwhile.

  - ideal build on top of that some kind of publish/notify (merge
requests in github) feature so that the "upstream" maintainer
doesn't have to know about who forks him to be notified when someone
has worked on a patch for his package.

  - last but not least, make it sure that the PPA-like infrastructure
works with software that can be installed elsewhere, not
necessarily on Debian infrastructure, so that non DDs can set-up
their one PPA-like setup and fork Debian PPAs into them and still be
able to submit "merge requests". This would be distributed-PPAs, and
would be git "git" of packaging.

This would drastically lower the bar for many things:
  - contributing to Debian ;
  - propose coherent set of experimental packages (in experimental it's
very

wanna-build / how to sort packages on buildds?

[Andreas Barth]

Hi,

I have a problem I need to solve in perl within wanna-build:

Sometimes we have a few packages we don't want to build on a certain
buildds. Sometimes this is because this package needs lots of ram. Or
it takes quite long and would waste the parallel building a machine
supports. Or whatever else. Of course a package could be in more than
one category.

Now, what I would like to do is to write that down in a central file
with categories.

That is, to mark packages as "builds only with more than one gigabyte
of ram". And to mark buildds as "has 6 cores", "only ... ram" - so
that I don't need to copy entries from buildd to buildd, but just say
"that new machine is the same class as ...", and that's it.

Now my question is just: How to do that efficient? I.e. how would such
a configuration file look like, and how the code to distribute the
package on the most fitting buildd(s)? (I.e. it's better to waste 5
out of 6 cores than to not build a package at all, but a package
needing at least 1g ram can't build on a buildd with only 512mb - but
no package should starve in the end.)

Ideas? Suggestions? Code?



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430233638.gz15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Pierre Habouzit (madco...@madism.org) [110501 01:32]:
> back a few versions. I couldn't care about testing any less. And at
> work, every person I know either uses just stable or does the same as
> me. I know no testing user around me. Of course I'm not pretending I
> know the absolute Truth, but well, I find this whole "users want testing
> badly" thing dubious.

I use testing on some Desktops, stable on others (but with codenames,
so at release I stay with stable, and usually a year after or so I
switch back to testing).



>   - get rid of experimental that would mostly become useless as PPA
> would clearly be a superset of the features.

but a slow merge-out, i.e. once PPA is working well, we can still get
rid of experimental.


>   - make it easy to create new PPA repositories (aka "forks") for every
> DD. Of course some attention not to overload buildd resources is
> important so maybe "forks" should be restricted to a few
> architectures instead of all of them.

We could just prioritize PPA repositories - if there is not enough
buildd power for all of them, only some will get built.


> But really, let's focus on relieving the expensive scarce resource (aka
> manpower, developers, maintainers) instead of adding burden on it for a
> dubious claim that users want it. If you add more burden to the scarce
> resource, instead of grabbing new "users", you'll end up with worse
> quality and actually lose users: it's a lose-lose scenario on the long
> term.

Amen.


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430234223.ga15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Pierre Habouzit]

On Fri, Apr 29, 2011 at 02:21:40PM +0200, Stefano Zacchiroli wrote:
> In general we need to promote the reduction of (potential) bottlenecks
> in Debian rather than the contrary. ... and don't get me wrong: I'm very
> well aware that this specific "bottleneck" is a very good feature to
> have for the preparation of a stable release, given it means more
> scrutiny and ultimately more quality.  But given that "rolling" seems to
> be willing to trade some of that stability off in favor of fresher
> software, it might be warranted to lift it off there.

I think that we should not do any trade off on the quality of
rolling/testing/the-antechamber-of-stable, but instead raise the quality
of unstable so that (which isn't *that* bad, unstable is rarely badly
broken, and I know lots of "stable" releases of linux distributions that
are in worse state than the average of unstable on the same set of
packages…):
  - testing is and remains a release only tool, as the stable staging
area.
  - unstable becomes more suitable for less experienced users.
  - stuff outside from unstable (experimental nowadays) gets more
attention.

I've already written one too long mail about that, but allowing DDs to
spin off some repositories in a PPA-way can be the way. Managing a
Debian mirror plus all the {uploading,building,bts}-infrastructure is a
PITA, but if we make it easy, it'll get used. As in VCSes branching
*and* merging "repositories" should be easy. For now we're not even in
the packing CVS era since branching is a PITA. Let's make it easy, and
then the whole rolling thing will be moot because unstable will be good
enough for our users 98% of the time.

[ And also relaxing our NMU policies would help too but that's yet
  another story: in a few words, we should allow NMUs as soon as there
  is enough acked-by for them… to enforce a minimal level of
  peer-review, so that quality is checked, and relax all the conditions
  to perform NMUs at once ]
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501000619.gb14...@madism.org

Re: [RFC] Changing APT to pre-depend on ${shlibs:Depends}

[Steve Langasek]

On Thu, Apr 28, 2011 at 06:48:22PM +0200, Julian Andres Klode wrote:
> > "We might some day later change the way apt works for upgrades" is not an
> > argument for adding a pre-dependency now.

> But that we do want to prevent a broken APT -- when using the common
> "dpkg -i ...; apt-get install -f" idiom (where ... is APT) -- certainly
> is an argument. 

Yeah.  I don't strongly disagree with this argument, but I also don't find
it particularly persuasive.  apt already treats apt as special, I don't
think it's very consistent to ask dpkg and other front ends to also treat
apt specially (by way of Pre-Depends).

> The counter argument seems to be 
> - we do not protect the user from removing APT with dpkg
> => counter argument: dpkg -i is common, dpkg -R is not
> (see Raphaël's email)
> - there are other package managers
> => counter argument: No other package manager has as few
> dependencies as APT and as high priority.

- it doesn't fit with the usual justifications of Pre-Depends
  (needed in preinst, or package is essential and must be usable
  when unpacked), and it will be pointed to as precedent for other
  non-traditional uses of Pre-Depends, when it's already hard to
  explain to people when Pre-Depends should be used and why?

(Yes, I know that I've just been responsible for a much worse instance of
this in the case of multiarch-support; I'm not thrilled about that either,
but don't see any other way to ensure reliable upgrades to wheezy.)

> So practically spoken, we are at something like +0.5 for the change
> based on the arguments. Based on votes, we're currently at +1.

> -1 jac...@debian.org
> +1 pe...@p12n.org
> +1 hert...@debian.org
> -2 kalnischkies+deb...@gmail.com
> +2 j...@debian.org
>  0 m...@debian.org
> --
> +1 total (maximum 9)

Well, I guess you could count me as a weak -1 here.

-- 
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501000921.ga22...@virgil.dodds.net

Re: Crypto consolidation in debian ?

[Steve Langasek]

On Thu, Apr 28, 2011 at 03:09:48PM +0200, Simon Josefsson wrote:
> Roger Leigh  writes:

> > libgcrypt has some horrendous bugs which upstream refuse to fix,
> > for example the broken behaviour relating to setuid binaries
> > discussed previously here, and the hard coded behaviour which
> > makes it unsuitable for use in general programs.  See
> >
> > "libgcrypt brain dead?"
> > 3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com

> > Until these major issues are fixed, it's simply unusable.

> It appears to be usable by a lot of projects and people, so that seems
> like an exaggeration.  If I have understood Werner correctly, he
> believes that it is the setuid binaries that are broken and should be
> fixed.

As a comaintainer of openldap, which links to gnutls in Debian for license
reasons, I need to vehemently echo Roger here.  sudo most certainly isn't
broken for being setuid, and libgcrypt should definitely not be ripping its
suid privs out from under it, yet this is what happens if using nss_ldap
with an SSL-using LDAP server.

  http://bugs.debian.org/566351
  https://bugs.launchpad.net/bugs/423252

Changing the uid of the calling application is *not* an acceptable side
effect for a library and I can't imagine how anyone could believe that it
is.  Unfortunately that seems to leave nss_ldap caught between an SSL
implementation with a perverse license, and an SSL implementation whose
upstream has perverse ideas about library handling of process state.

-- 
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501012328.gb22...@virgil.dodds.net

Re: Bits from the Release Team - Kicking off Wheezy

[Russ Allbery]

Pierre Habouzit  writes:

> No what we want is probably to be attractive to developers, while
> keeping our standards about the stable release, which is what really
> matters. And to do that, well, what we need is to make working for
> Debian easier. Not harder. rolling is making working for Debian harder,
> hence is a bad proposal. Harder because it means people will have more
> work for a package. Maintainers are (me included) often too lazy to
> prepare Stable updates because it's a PITA to have to work on a 1-yo
> version of the package. Why would they be more motivated to work on
> testing packages?

> No we should focus instead on making packaging easier, not adding new
> constraints, new goals. Here are a few thoughts on how to do that.

[...]

I don't think I'm convinced that rolling would make anything harder, and I
don't want to support that part of Pierre's message, but I did want to say
that the description laid out in this message about how PPAs could work
and on using a unified VCS for that purpose sounds *awesome*, and I would
love to use something like that.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87liyrrqtw@windlord.stanford.edu

Re: Bits from the Release Team - Kicking off Wheezy

[Ludovico Cavedon]

On 04/30/2011 04:32 PM, Pierre Habouzit wrote:
> FWIW I think that "rolling" or "CUT" miss the point entirely. As a
> Debian user I use stable on my servers (with a few backports for the 3-4
> things I need bleeding edge for). For my desktop I use unstable, and
> when that breaks (which is *very* rare, really) I go to snapshots and go
> back a few versions. I couldn't care about testing any less. And at
> work, every person I know either uses just stable or does the same as
> me. I know no testing user around me. Of course I'm not pretending I
> know the absolute Truth, but well, I find this whole "users want testing
> badly" thing dubious.

I do know people who run testing.
Actually I can see two kinds of users who run testing.
-people who want to keep getting software updates, but do not want to
run unstable [1]. They would point to "testing" in their apt
sources.list. These are the users who want "rolling"
-people who would decided to run the next stable release, before it is
actually released, they would point their sources.list to "wheezy" (as
of now). there are the users who will go though "rolling", then
"frozen", then "stable"

[1] I run unstable in my laptop, and it is stable enough for me, but for
a regular user I can see how these 10 days between unstable and testing
can help her to avoid getting in contact with major bugs/issues.

Even though I do not have numbers, I can see both use cases for rolling
and frozen. Ok, frozen might get less users than testing during freeze,
but handling both these 2 use cases could actually attract more users.

Form what I could understand, the main purpose of "rolling" is to avoid
the discontinuity in updates flow that happens in unstable (and of
course in testing), when testing is under freeze. Which is annoying for
users who do not care about stable. Such users (first type above) will
have to go and pick updates from experimental during freeze (with all
the problems Pierre mentioned about experimental).
Similar reasoning applies to developers: those who care about having the
latest version in unstable, will switch to uploading to experimental
rather than unstable.
So I am not sure that arguments like "having testing frozen and avoiding
major updates in unstable help DD and users focus on preparing the next
stable" actually apply...

>   - get rid of experimental that would mostly become useless as PPA
> would clearly be a superset of the features.

I completely agree on this, sounds like a really good idea.

My 2 cents,
Cheers,
Ludovico


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbcfca9.8050...@debian.org

Re: Bits from the Release Team - Kicking off Wheezy

[Mike Hommey]

On Sun, May 01, 2011 at 01:32:19AM +0200, Pierre Habouzit wrote:
> FWIW I think that "rolling" or "CUT" miss the point entirely. As a
> Debian user I use stable on my servers (with a few backports for the 3-4
> things I need bleeding edge for). For my desktop I use unstable, and
> when that breaks (which is *very* rare, really) I go to snapshots and go
> back a few versions. I couldn't care about testing any less. And at
> work, every person I know either uses just stable or does the same as
> me. I know no testing user around me. Of course I'm not pretending I
> know the absolute Truth, but well, I find this whole "users want testing
> badly" thing dubious.

The real problem is not "users want testing badly", but "Debian wants
people to use testing badly". Because what Debian releases is testing.
If nobody uses it, we don't know until it becomes stable that it's
broken in some subtle ways because it's not exactly what everyone else
using unstable is using.

So while I do agree with the rest of your message, I do see a need to
make testing more attractive so that we have a solid user base actually
testing what we are going to release, and stop saying to people that
they shouldn't be using testing (and I've seen that said *a lot*).

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501063855.gb18...@glandium.org

Re: wanna-build / how to sort packages on buildds?

[Tollef Fog Heen]

]] Andreas Barth 

Hi,

| Now my question is just: How to do that efficient? I.e. how would such
| a configuration file look like, and how the code to distribute the
| package on the most fitting buildd(s)? (I.e. it's better to waste 5
| out of 6 cores than to not build a package at all, but a package
| needing at least 1g ram can't build on a buildd with only 512mb - but
| no package should starve in the end.)
| 
| Ideas? Suggestions? Code?

Sounds like a variant of the knapsack problem.

I'd suggest something like:

- Have a mapping for buildds from resources to a value (this can just be
  a perl hash), this defines cores, amount of memory, etc.

- Each package has a minimum requirement for cpu, memory, etc, stored in a
  hash.  Store all the packages in a list.

- Sort the list, either according to a score which is a mix of cpu and
  memory and whatever other factors you want or first along the cpu
  axis, then along the memory axis, etc.  I suspect CPU and memory
  requirements are correlated, but not perfectly.

- Assign packages to buildds on a first-match basis.  That means you get
  the hardest packages done first.  The match has to make sure the
  buildd can actually build the package in question, of course.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3k2c49x@qurzaw.varnish-software.com

Re: Bits from the Release Team - Kicking off Wheezy

[Raphael Hertzog]

On Sat, 30 Apr 2011, Russ Allbery wrote:
> Pierre Habouzit  writes:
> 
> > No what we want is probably to be attractive to developers, while
> > keeping our standards about the stable release, which is what really
> > matters. And to do that, well, what we need is to make working for
> > Debian easier. Not harder. rolling is making working for Debian harder,
> > hence is a bad proposal. Harder because it means people will have more
> > work for a package. Maintainers are (me included) often too lazy to
> > prepare Stable updates because it's a PITA to have to work on a 1-yo
> > version of the package. Why would they be more motivated to work on
> > testing packages?
> 
> > No we should focus instead on making packaging easier, not adding new
> > constraints, new goals. Here are a few thoughts on how to do that.
> 
> [...]
> 
> I don't think I'm convinced that rolling would make anything harder, and I
> don't want to support that part of Pierre's message, but I did want to say
> that the description laid out in this message about how PPAs could work
> and on using a unified VCS for that purpose sounds *awesome*, and I would
> love to use something like that.

+1

I'm in favor of what Pierre has described[1] and it's certainly something
that I would like to see happen. But it's absolutely not in opposition
to CUT/rolling.

The philosophy behind testing is that it should always stay as close as
possible to a releasable state and anything we do to make testing more
usable certainly contributes to this.

Fixing RC bugs in testing and getting new upstream versions that are
ready in testing is not a burden for developers, it's what we're
supposed to do to ensure we can release as quickly as possible.

Cheers,

[1] It's very similar to the "overlay repositories" that I suggested last
year in http://lists.debian.org/debian-release/2010/03/msg00385.html
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501064031.gb25...@rivendell.home.ouaza.com