Re: A new Priority level, ???backports??? ? (Re: unstable/testing/[pending/frozen/]stable)

[Andreas Tille]

On Fri, Oct 08, 2010 at 10:58:24AM +0900, Charles Plessy wrote:
> I was acually meditating on Joerg's answer for the past two weeks, wondering
> that if my some of my packages are bullshit, I should look for another place 
> to
> distribute them instead of letting them be a burden for everybody.

I did not read any answer in the sense that some packages are a burden.
IMHO only those packages are a burden which are hanging around ages with
RC bugs or low popcon packages who are not maintained actively (and thus
might contain RC bugs but nobody notices).
 
> None of the packages I maintain can be described as being a integral part of 
> an
> ???operating system???. None of them is essential to Debian.

We have a category "essential" but I do not think that this category
maps to what you mean with essential.  It is hard to define what
building blocks are essentially for building an "universal operating
system" and thus we will probably run circles in deciding whether a
package is essential / needed / nice to have / whatever.  IMHO, the most
important thing is that a package is properly maintained.

> Would a Debian PPA or
> a private repository be a better place for them?  Personally, I do not think
> so.

I don't think so neither.  In the sense of my paragraph above you can
not find a clear borderline what belongs to Debian and what not.

> I have embraced the ???Debian Pure Blend??? concept, which is to do our work 
> in
> Debian, not as a supplement to Debian.

IMHO (for sure ;-)) this is a reasonable concept.

> Now that Debian has an official
> backports suite, I think that it can change the way we distribute our final
> products: packages that have demonstrated their quality by migrating and
> staying in Testing.

I do not really see in how far the existence of the official backports
suite should change the look onto Debian stable in general.  I have
understood backports as an additional service to the existing stable and
not as a reason to drop packages from stable.
 
> > This whole thing does not make sense at all. Priority is the wrong knob.
> 
> [???]

!!!

> The package priorities establish concentric subnetworks of our binary
> dependancy graph.

Yes.

> I think that it is an interesting property that is under-used.

I do not think so.

> Having a priority lower than extra would allow packages to coexist
> in Testing without interfering with Stable. They would have the same aims in
> terms of quality ??? that is the responsibility of the maintainer.

But why?  I do not see a reason to have packages inside Debian which do
not "deserve" to end up in stable.  Debian stable is THE PRODUCT we are
releasing, it is the goal we are working towards.  There are people
relying on this product and I do not see any reason to exclude a set of
packages from stable.
 
> However, the lower-priority package would not pretend at the same durability,
> which is two to four years if we take the freeze and the Oldstable support in
> account. In two years, some packages that are currently in Squeeze will still
> be fine for most users, while for others, users interest for such an old
> version can be very low.

IMHO this paragraph just proves that the priority scale and the aging of
programs scale are orthogonal and priority is just the wrong knob.
There are people who are needing the latest postgresql,
open(libre?)office, firefox (for whatever reason) but none of these
packages would even go into the category extra.  On the other end of
your arguing we have some scientific software which is not maintained
upstream any more, has low popcon but has some use for a certain amount
of users anyway and thus is maintained by Debian Med/Science team.  From
a priority point of view they could qualify for "below extra".  However,
these packages are completely wrong in  backports because they are just
not updated by upstream any more.

So priority and actuality of a package are just different dimensions.

> For this, the maintainer sometimes can do little,
> apart from giving up packaging software from young projects.

Why?  Having an old version in stable and having a more up to date
version in backports is the solution, isn't it?
 
> Although it is not a problem to release these packages in Stable, I think that
> ??? in the case of some packages I maintain in the Debian Med team ??? we 
> would
> send a clearer message by distributing them to our Stable users only as
> backports.  Without compromising on the quality.

If I would try to wear my users hat I would definitely not understand
your message.  It's rather confusing than clear from my point of view.
 
Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
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/20101008072452.gb19...@an3as.eu

Re: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Charles Plessy]

Hi all,

I was acually meditating on Joerg's answer for the past two weeks, wondering
that if my some of my packages are bullshit, I should look for another place to
distribute them instead of letting them be a burden for everybody.

Since he sent his anwer again, I will reply again. Let's hope it dissipates
misunderstandings.

None of the packages I maintain can be described as being a integral part of an
‘operating system’. None of them is essential to Debian.  Would a Debian PPA or
a private repository be a better place for them?  Personally, I do not think
so. I have embraced the ‘Debian Pure Blend’ concept, which is to do our work in
Debian, not as a supplement to Debian. Now that Debian has an official
backports suite, I think that it can change the way we distribute our final
products: packages that have demonstrated their quality by migrating and
staying in Testing.

Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit :
> Le Thu, Sep 23, 2010 at 12:38:16AM +0900, Charles Plessy a écrit :
> > the addition of new suites has the disadvantage of dispersing our userbase.
> > Here is a proposition that conserves the current flow of package migration 
> > for
> > packages released in Stable, and that makes Testing the meeting point for 
> > all
> > the packages. 
> 
> > We could introduce a new priority level, ‘backports’, with the following
> > features:
> 
> This whole thing does not make sense at all. Priority is the wrong knob.

[…]

> So what backports "priority" actually says is "my package is such a
> bullshit that I don't want it ever released, but I am fine with putting
> burden on the people keeping backports running instead". I think we have
> a way already dealing with this: Don't upload them.

The package priorities establish concentric subnetworks of our binary
dependancy graph. I think that it is an interesting property that is
under-used. Having a priority lower than extra would allow packages to coexist
in Testing without interfering with Stable. They would have the same aims in
terms of quality – that is the responsibility of the maintainer.

However, the lower-priority package would not pretend at the same durability,
which is two to four years if we take the freeze and the Oldstable support in
account. In two years, some packages that are currently in Squeeze will still
be fine for most users, while for others, users interest for such an old
version can be very low. For this, the maintainer sometimes can do little,
apart from giving up packaging software from young projects.

Although it is not a problem to release these packages in Stable, I think that
— in the case of some packages I maintain in the Debian Med team — we would
send a clearer message by distributing them to our Stable users only as
backports.  Without compromising on the quality.

This, more than the particular implementation (based on priorities or not) is
what I am proposing.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20101008015824.gb15...@merveille.plessy.net

Re: A new Priority level, ‘backports’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Russ Allbery]

Marc Haber  writes:

> The ftp team has a history of strongly discouraging uploads that they
> don't feel like accepting (such as a package that would download
> eicar.com from the internet and place it in a defined place where other
> packages might find and use it) and of killing of packages on grounds
> that "nobody sane would use them", such as clamav-data, which force-died
> in the course of volatile moving under the ftp team's reign.

I completely support the FTP team's refusal to accept completely
automatically generated and automatically signed (unattended) packages in
the archive.

-- 
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/87wrqcxcv2@windlord.stanford.edu

Re: unstable/testing/[pending/frozen/]stable

[Raphael Hertzog]

Hi,

On Wed, 22 Sep 2010, Yaroslav Halchenko wrote:
> hm... did you mean
> http://lwn.net/Articles/406301/
> "A constantly usable testing distribution for Debian"?

Yes.

> if indeed, taken on the reasoning that "testing" is a bad name and "rolling" 
> is
> better, then it goes similar to what I saw behind 'constatly present'
> testing up to replacing rolling -> testing ->[removal of packages] -> frozen

Well, summarizing the whole with a few arrows is difficult but note that
the current rolling proposal is more like this:

Outside of freeze:
--
unstable → testing → rolling
   ↑
targetted uploads

During freeze:
--
t-p-u→ testing  
 ↗ (not automatic)
unstable → rolling
 ↑
 targetted uploads

> now about 'pending': following description confused me quite a bit:
> 
> ... during a freeze, testing is no longer automatically updated, which
> makes it inappropriate to feed the rolling distribution. That's why rolling
> would be reconfigured to grab updates from unstable (but using the same rules
> as testing).
> 
> But unstable remains to serve as the entry point to feed frozen testing as
> well, so with absent other entry-point (pending in my scenario) there is a
> conflict -- I can't upload 1 version which I intend to get to frozen testing
> and another one to get into rolling (experimental obviously can't serve as
> such).  or it all would go through an addendum (*-proposed-updates)?

That entry point aleady exists and is called testing-proposed-updates
indeed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

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/20100923092730.gb28...@rivendell.home.ouaza.com

Re: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Julien Cristau]

On Thu, Sep 23, 2010 at 17:12:49 +0900, Charles Plessy wrote:

> Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit :
> > 
> > So what backports "priority" actually says is "my package is such a
> > bullshit that I don't want it ever released, but I am fine with putting
> > burden on the people keeping backports running instead". I think we have
> > a way already dealing with this: Don't upload them.
> 
> These packages are not that bad, since the FTP team accepted them…
> 
As far as I can tell the FTP team bases its accept/reject decisions on
whether it's legal for us to distribute a package (and whether it's
suitable for the component it was uploaded to in terms of the dfsg), not
whether it's a good idea to put that package in the distribution.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Charles Plessy]

Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit :
> 
> So what backports "priority" actually says is "my package is such a
> bullshit that I don't want it ever released, but I am fine with putting
> burden on the people keeping backports running instead". I think we have
> a way already dealing with this: Don't upload them.

These packages are not that bad, since the FTP team accepted them…

Cheers,

-- 
Charles


-- 
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/20100923081249.gc14...@merveille.plessy.net

Re: A new Priority level, ‘backports’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Joerg Jaspert]

> the addition of new suites has the disadvantage of dispersing our userbase.
> Here is a proposition that conserves the current flow of package migration for
> packages released in Stable, and that makes Testing the meeting point for all
> the packages. 

> We could introduce a new priority level, ‘backports’, with the following
> features:

This whole thing does not make sense at all. Priority is the wrong knob.

>  This priority level would be lower than ‘extra’. Higher levels would not be
>  allowed to depend nor build-depend on packages of priority ‘backports’. 
> Source
>  packages would not be allowed to contain a mixture binary packages containing
>  ‘backports’ level and higher priorities.

>  These packages would not be released in Stable, but would be uploaded to
>  Unstable and migrate in Testing as usual, with the exception that they would
>  not be affected by a freeze. They could be removed by default from Testing in
>  case they block a transition.

>  As the name indicates, the packages which prove their stability in Testing
>  (and only them, as in the current backports rules) would be backported in
>  backports.debian.org. The backports would be prepared by the maintainers
>  themselves (this would open a way to the use of the BTS) and would be the 
> final
>  distribution medium for Stable users.

So what backports "priority" actually says is "my package is such a
bullshit that I don't want it ever released, but I am fine with putting
burden on the people keeping backports running instead". I think we have
a way already dealing with this: Don't upload them.


-- 
bye, Joerg
'To Start Press Any Key'. Where's the ANY key? 


--
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/87vd5xszdd@gkar.ganneff.de

Re: unstable/testing/[pending/frozen/]stable

[Yaroslav Halchenko]

On Wed, 22 Sep 2010, Raphael Hertzog wrote:
> Anyway, I'd like to ask you all to hold off the discussion for a few hours
> until everybody can read the summary of the CUT discussions and have a
> clearer ideas of the proposals and the implications.
hm... did you mean
http://lwn.net/Articles/406301/
"A constantly usable testing distribution for Debian"
[LWN subscriber-only content]
?

if indeed, taken on the reasoning that "testing" is a bad name and "rolling" is
better, then it goes similar to what I saw behind 'constatly present'
testing up to replacing rolling -> testing ->[removal of packages] -> frozen

now about 'pending': following description confused me quite a bit:

... during a freeze, testing is no longer automatically updated, which
makes it inappropriate to feed the rolling distribution. That's why rolling
would be reconfigured to grab updates from unstable (but using the same rules
as testing).

But unstable remains to serve as the entry point to feed frozen testing as
well, so with absent other entry-point (pending in my scenario) there is a
conflict -- I can't upload 1 version which I intend to get to frozen testing
and another one to get into rolling (experimental obviously can't serve as
such).  or it all would go through an addendum (*-proposed-updates)?

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



-- 
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/20100923022237.gw12...@onerussian.com

Re: unstable/testing/[pending/frozen/]stable

[Philipp Kern]

On 2010-09-22, Bruce Sass  wrote:
> I've heard that Testing cycles between good/installable and 
> bad/un-installable--do those good times correspond to times when it 
> would be possible to freeze a set of packages?

You're wrong.  That's FUD you've read.

Cheers
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/slrni9ko8v.nl.tr...@kelgar.0x539.de

Re: unstable/testing/[pending/frozen/]stable

[Bruce Sass]

On September 22, 2010 01:35:14 am Mehdi Dogguy wrote:
> On 09/22/2010 08:47 AM, Mike Hommey wrote:
> > On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote:
> >>> Then unstable/testing would roll further as usual
> >>
> >> How does a major, disruptive, transition get done?
> >
> > I think his proposal boils down to this: we *always* have unstable
> > and testing to upload whatever we want and handle transitions when
> > we like. Then, parallel to unstable/testing, there would be the
> > pending/frozen suites to work on the release. Saying it a bit
> > differently, we would *also* already be working on release+1 while
> > release is being frozen. I kind of like the idea.
> >
> > To give an example with package names, I would already upload
> > iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse
> > dependencies until they are fixed to use xulrunner 1.9.2, while
> > keeping updates for iceweasel 3.5 in pending/frozen. It would also
> > allow me to push iceweasel 4.0 betas to experimental, where they
> > would be better suited than their current location, where they are
> > not even built on non x86/x86-64.
>
> It means that the Release Team will have to handle transitions in
> unstable, migrations to testing, as well as the ongoing freeze in
> "frozen". I don't think we have enough manpower for that. And, during
> a freeze, we need each one to concentrate on fixing things (while
> there is still experimental to test things). If we add a
> play-forever-suite, we will loose some manpower without any doubt and
> it will make releases harder to acheive, imho.
>
> Besides, how de we merge things after a release? unstable would be
> something quite different from released frozen. Some bugfixes might
> have been applied only for frozen or pending, some other package will
> have new versions in unstable (and their rev-deps rebuilt)… I think
> it could be a nightmare to manage, imho.

Unstable and Testing appear to quickly diverge from a new release's 
versions, becoming "something quite different from released", in a 
matter of days or few weeks. The only difference in this regard if 
a "frozen" existed would be that they could diverge sooner...  wouldn't 
that be a headstart on the next Stable?

What if packages only became "frozen" when the set of dependency 
relationships they are involved in is consistent (enough?) In this 
scenario there would be no (only minor?) transitions happening in 
Frozen, and consequently no (little?) need to merge dependency related 
bugfixes (the only "some" of consequence, afaict) into Unstable or 
Testing packages. Simply having that as a goal may encourage more or 
more prompt work on packages in Testing.

I've heard that Testing cycles between good/installable and 
bad/un-installable--do those good times correspond to times when it 
would be possible to freeze a set of packages? i.e., is there already 
an indicator that can be used to trigger a mostly automatic action 
which over time would result in Frozen becoming a release candidate?


anyways, here's a somewhat philosophical thought on the matter...

Currently Debian can only "see" the past (Stable) and present 
(Unstable/Testing). Creating an always-consistent-"frozen" category of 
packages would let Debian "see" the past (Stable), present (Frozen), 
and future (Unstable/Testing).


- Bruce


--
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/201009221117.16849.bms...@shaw.ca

A new Priority level, ‘bac kports’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Charles Plessy]

Dear Yaroslav and everybody,


the addition of new suites has the disadvantage of dispersing our userbase.
Here is a proposition that conserves the current flow of package migration for
packages released in Stable, and that makes Testing the meeting point for all
the packages. 


We could introduce a new priority level, ‘backports’, with the following
features:

 This priority level would be lower than ‘extra’. Higher levels would not be
 allowed to depend nor build-depend on packages of priority ‘backports’. Source
 packages would not be allowed to contain a mixture binary packages containing
 ‘backports’ level and higher priorities.

 These packages would not be released in Stable, but would be uploaded to
 Unstable and migrate in Testing as usual, with the exception that they would
 not be affected by a freeze. They could be removed by default from Testing in
 case they block a transition.

 As the name indicates, the packages which prove their stability in Testing
 (and only them, as in the current backports rules) would be backported in
 backports.debian.org. The backports would be prepared by the maintainers
 themselves (this would open a way to the use of the BTS) and would be the final
 distribution medium for Stable users.


The system I propose is intended to keep fruitful interactions between higher
turnover packages and stable releases:

 - It would keep Unstable and Testing as a central point for our users who would
   like an early access to new software, therefore preserving a high number of
   testers for the packages of higher quality, which are aimed at Stable. (In
   contrary for instance to distribution outside of Debian or in the 
experimental
   suite.)

 - Since immediatly after the release the backports are trivial, it would
   motivate the interest of the maintainers of ‘Priority: backports’ packages
   for Stable and its release process, to ensure frequent windows of easy
   backporting.

 - By removing from testing – on a voluntary basis – a lot of packages for
   which there is no stable upstream release, or which are still in active
   development, it would reduce the load on regular operations.


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/20100922153816.ga28...@merveille.plessy.net

Re: Debian ppa (was Re: unstable/testing/[pending/frozen/]stable)

[Julien Cristau]

On Wed, Sep 22, 2010 at 16:24:44 +0200, Holger Levsen wrote:

> Hi,
> 
> On Mittwoch, 22. September 2010, Mike Hommey wrote:
> > PS: for my personal needs, some way to get random packages autobuilt
> > would already be helpful (call that ppa if you want).
> 
> I seem to recall, ftpmaster was planning something like that. Or wanted to?
> If so, what the status? If not, shall we start it? I think so.
> 
HE proposed something like this (on the buildd side) for gsoc, there
were no takers, iirc.

Cheers,
Julien


signature.asc
Description: Digital signature

Debian ppa (was Re: unstable/testing/[pending/frozen/]stable)

[Holger Levsen]

Hi,

On Mittwoch, 22. September 2010, Mike Hommey wrote:
> PS: for my personal needs, some way to get random packages autobuilt
> would already be helpful (call that ppa if you want).

I seem to recall, ftpmaster was planning something like that. Or wanted to?
If so, what the status? If not, shall we start it? I think so.


cheers,
Holger



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

Re: unstable/testing/[pending/frozen/]stable

[Mehdi Dogguy]

On 22/09/2010 15:01, Raphael Hertzog wrote:
> 
> I think that if you concentrate on preparing the next release like you
>  do, volunteers that are not interested in the stable release (except 
> for their own package) will show up and deal with migrations to 
> rolling.
> 

It won't happen but I'd be happy to be proven wrong though.

> It's always the same story, you can't force people to care about
> stable simply by not having a "play-forever-suite".

We are not trying to force people, but rather trying to give them a bit of
responsibility during the release process. « Releasing is a shared
responsibility, not only release team's »…

> And we do have people working on derivative distributions that rely on 
> testing's constant freshness, maybe some of them would be interested
> to help as well.
> 

Nice plan! Please let me know what it happens.

> 
> Anyway, I'd like to ask you all to hold off the discussion for a few 
> hours until everybody can read the summary of the CUT discussions and 
> have a clearer ideas of the proposals and the implications.
> 

Ack.

> Cheers,

-- 
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/4c9a0f00.70...@dogguy.org

Re: unstable/testing/[pending/frozen/]stable

[Raphael Hertzog]

Hi all,

On Tue, 21 Sep 2010, Yaroslav Halchenko wrote:
> CUT discussions at debconf10 and recent news of the birth of Linux Mint

discussions on CUT have continued after debconf on the CUT mailing. I
wrote a summary of the discussion that will be published in Linux Weekly
News before tomorrow.

Hopefully this summary will then lead to a constructive discussion on the
way forward.

http://cut.debian.net/
http://lists.alioth.debian.org/pipermail/cut-team/

> [experimental/]unstable(sid)/testing(e.g squeeze)/stable
> 
> *constantly* present and functioning all the time the same way.

You're not alone wishing that. I also would like Debian to provide a
rolling distribution that never stops to roll. :-)

> NB I am having some deja vu that 'frozen' used to be used explicitly
>in the archive... is that so?

Yes. frozen was a snapshot of unstable at time of freeze, and people could
upload to frozen directly afterwards to fix remaining RC bugs.

> But I cannot be first thinking about that, and I bet there were good
> reasons why such approach was not taken -- could anyone enlighten/point
> me to the shortcomings?

I'm not sure it was an explicit choice at that time. We just had to adjust
the way we dealt with freeze once testing was introduced. Getting fixes
from unstable is easier/safer for everybody compared to
testing-proposed-updates so release managers asked people to not upload
packages which could not migrate to testing and many do. It also means
unstable is less interesting during freeze. Also having the package in
unstable for some time ensures that it doesn't break horribly, something
that you don't have with testing-proposed-updates.

There is room for improvements here I think.

On Wed, 22 Sep 2010, Mehdi Dogguy wrote:
> It means that the Release Team will have to handle transitions in
> unstable, migrations to testing, as well as the ongoing freeze in
> "frozen". I don't think we have enough manpower for that. And, during a
> freeze, we need each one to concentrate on fixing things (while there is
> still experimental to test things). If we add a play-forever-suite, we
> will loose some manpower without any doubt and it will make releases
> harder to acheive, imho.

I think that if you concentrate on preparing the next release like you do,
volunteers that are not interested in the stable release (except for their
own package) will show up and deal with migrations to rolling.

It's always the same story, you can't force people to care about stable
simply by not having a "play-forever-suite". And we do have people working
on derivative distributions that rely on testing's constant freshness,
maybe some of them would be interested to help as well.


Anyway, I'd like to ask you all to hold off the discussion for a few hours
until everybody can read the summary of the CUT discussions and have a
clearer ideas of the proposals and the implications.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

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/20100922130147.gh4...@rivendell.home.ouaza.com

Re: unstable/testing/[pending/frozen/]stable

[Bernd Zeimetz]

On 09/22/2010 02:52 AM, Yaroslav Halchenko wrote:
[...]
> [experimental/]unstable(sid)/testing(e.g squeeze)/stable
> 
> *constantly* present and functioning all the time the same way.
> 
> Then upon freeze we just copy the state of
>   unstable -> pending
>   testing(squeeze) -> frozen(squeeze, e.g together with a codename)
> and link new codename (e.g. wheezy) against testing.


while I like the idea to support distributions like MINT which pull from
testing, I doubt it would be useful for Dbeian. Even if we would have the
manpower in the release team to handle it, I'd expect that a lot of developers
would concentrate on throwing new stuff into unstable instead of fixing bugs to
be able to release soon. The proper way to fix the issue is to release faster by
fixing all remaining issues faster :)
-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4c99bc6b.6020...@bzed.de

Re: unstable/testing/[pending/frozen/]stable

[Simon Richter]

Hi,

On Tue, Sep 21, 2010 at 08:52:09PM -0400, Yaroslav Halchenko wrote:

> NB I am having some deja vu that 'frozen' used to be used explicitly
>in the archive... is that so?

Indeed. That was before testing was introduced.

> Then unstable/testing would roll further as usual, and pending->frozen
> according to the freeze schedule.  This would enable CUTs, fulfill
> the ideas behind LMDE to have something rolling without hickups, and
> users of 'testing' (and unstable) would enjoy testing/unstable the way
> they usually do.

The introduction of testing has had positive and negative effects. While
it is generally a good thing that packages are tested for some time and
required to be consistent with respect to other packages to even be
considered for a release, it has also led to a situation where releases
are mostly ignored by some maintainers, who just continue to upload new
packages and live with the consequence that some snapshot goes into
stable.

I'm not sure whether explicitly telling people that it is okay to upload
new versions to unstable while a release is being prepared is a good
thing in that context.

   Simon


-- 
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/20100922080333.ga2...@richter

Re: unstable/testing/[pending/frozen/]stable

[Mike Hommey]

On Wed, Sep 22, 2010 at 08:26:22AM +0100, Neil Williams wrote:
> On Wed, 22 Sep 2010 08:47:31 +0200
> Mike Hommey  wrote:
> 
> > On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote:
> > > > Then unstable/testing would roll further as usual
> > > 
> > > How does a major, disruptive, transition get done?
> > 
> > I think his proposal boils down to this: we *always* have unstable and
> > testing to upload whatever we want and handle transitions when we like.
> > Then, parallel to unstable/testing, there would be the pending/frozen
> > suites to work on the release.
> > Saying it a bit differently, we would *also* already be working on
> > release+1 while release is being frozen. I kind of like the idea.
> 
> Splitting the user base / testing base isn't necessarily a good idea.
> In other words, it might work for heavily utilised packages but it
> would cause a lot of complexity in bug triage. How is the maintainer
> meant to test the version in unstable if he's running the frozen
> version or vice-versa?

How is the maintainer meant to test the version in stable if he's
running the unstable version of vice-versa?
and s/stable/testing/.

Anyways, yes, it might work for heavily utilised packages, but on the
other hand, they are exactly the kind of packages where it would make
sense.

> > To give an example with package names, I would already upload iceweasel
> > 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies
> > until they are fixed to use xulrunner 1.9.2, while keeping updates for
> > iceweasel 3.5 in pending/frozen. It would also allow me to push
> > iceweasel 4.0 betas to experimental, where they would be better suited
> > than their current location, where they are not even built on non
> > x86/x86-64.
> 
> With something like iceweasel, is there frankly any point in building
> experimental versions on architectures which can barely handle the
> stable releases?

There frankly is one: that of catching bugs early. For example, I
already know iceweasel 4.0 betas are broken on several of our
architectures. If I hadn't tried to build it once, I wouldn't have
realized until I uploaded 4.0 final, at which point it's even harder to
get fixes upstream, which means yet more patches applied to our package.
For instance, being able to work on 4.0 since its early days helped
getting the number of patches from 100+ on 3.5 and 3.6 down to around 50.

> How many users are there using iceweasel not on x86/x86-64?

Do you realize the iceweasel package is not about iceweasel alone? Check
the number of build-rdeps and rdeps on libmozjs, and xulrunner.

And who knows what future netbooks may bring more users for mips or arm,
for instance?

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/20100922074654.ga19...@glandium.org

Re: unstable/testing/[pending/frozen/]stable

[Neil Williams]

On Wed, 22 Sep 2010 07:31:45 +0100
Neil Williams  wrote:

> So when and where are library transitions meant to occur? Transitions
> are always disruptive, always cause some packages to be non-functional
> or non-installable. There has to be somewhere (unstable) where libfoo2
> can be uploaded with libfoo2-dev so that all packages which depend on
> libfoo1 can start the migration to the new API. As the migration
> starts, there is a period (which in the case of GTK1->2 took several
> years) where many packages in unstable are uninstallable or FTBFS or
> just horribly buggy.

(note: this only gets worse with libfoo-dev_2 replacing libfoo-dev_1
but that does not mean that libfoo-dev should be disallowed or
deprecated.)
 
> > But I cannot be first thinking about that, and I bet there were good
> > reasons why such approach was not taken -- could anyone
> > enlighten/point me to the shortcomings?
> 
> In a word, transitions.

Personally, I've always considered it *more* important for Debian to
stabilise code than to always have the newest code. Stable beats new
every time. I run a mix of Debian machines, some for Debian development
which run unstable, some for Emdebian development which run testing and
some for upstream development which run stable. That is quite enough
work, thanks, I really, really don't want to have to add another
variant of unstable and/or testing to suit the needs of people who
prioritise buggy bleeding edge code over stable tools. The core system
(i.e. everything I'm not currently debugging) must be stable and
reliable if I'm going to get my work done.

Do people really want a version of unstable that always has the latest
broken version of iceweasel or some horrible partial transition to
python3 or the bleeding edge version of Xorg built directly from VCS
and which constantly crashes??

Having *everything* new and bleeding edge means that no bugs ever get
identified because you cannot tell which bit is bust or the bug you
want to fix is blocked by a bug in the X server or the python
interpreter or a buggy version of libgcc1 or something.

The platform (whatever packages are deemed part of the platform for any
one developer) *must* be stable if the code is to improve. Therefore,
individual developers need a stable platform onto which can be added
their own buggy code - not as packages from Debian but as checkouts
from whichever VCS is in use.

Predictability and reliability are key components of a usable
development platform. Without those, there is no chance of fixing
intermittent or corner case bugs.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpUYK2tSFX6o.pgp
Description: PGP signature

Re: unstable/testing/[pending/frozen/]stable

[Mehdi Dogguy]

On 09/22/2010 08:47 AM, Mike Hommey wrote:
> On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote:
>>> Then unstable/testing would roll further as usual
>> 
>> How does a major, disruptive, transition get done?
> 
> I think his proposal boils down to this: we *always* have unstable 
> and testing to upload whatever we want and handle transitions when we
> like. Then, parallel to unstable/testing, there would be the 
> pending/frozen suites to work on the release. Saying it a bit 
> differently, we would *also* already be working on release+1 while 
> release is being frozen. I kind of like the idea.
> 
> To give an example with package names, I would already upload 
> iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse 
> dependencies until they are fixed to use xulrunner 1.9.2, while 
> keeping updates for iceweasel 3.5 in pending/frozen. It would also 
> allow me to push iceweasel 4.0 betas to experimental, where they 
> would be better suited than their current location, where they are 
> not even built on non x86/x86-64.
> 

It means that the Release Team will have to handle transitions in
unstable, migrations to testing, as well as the ongoing freeze in
"frozen". I don't think we have enough manpower for that. And, during a
freeze, we need each one to concentrate on fixing things (while there is
still experimental to test things). If we add a play-forever-suite, we
will loose some manpower without any doubt and it will make releases
harder to acheive, imho.

Besides, how de we merge things after a release? unstable would be
something quite different from released frozen. Some bugfixes might have
been applied only for frozen or pending, some other package will have
new versions in unstable (and their rev-deps rebuilt)… I think it could
be a nightmare to manage, imho.

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/4c99b1b2.5040...@dogguy.org

Re: unstable/testing/[pending/frozen/]stable

[Neil Williams]

On Wed, 22 Sep 2010 08:47:31 +0200
Mike Hommey  wrote:

> On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote:
> > > Then unstable/testing would roll further as usual
> > 
> > How does a major, disruptive, transition get done?
> 
> I think his proposal boils down to this: we *always* have unstable and
> testing to upload whatever we want and handle transitions when we like.
> Then, parallel to unstable/testing, there would be the pending/frozen
> suites to work on the release.
> Saying it a bit differently, we would *also* already be working on
> release+1 while release is being frozen. I kind of like the idea.

Splitting the user base / testing base isn't necessarily a good idea.
In other words, it might work for heavily utilised packages but it
would cause a lot of complexity in bug triage. How is the maintainer
meant to test the version in unstable if he's running the frozen
version or vice-versa?

> To give an example with package names, I would already upload iceweasel
> 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies
> until they are fixed to use xulrunner 1.9.2, while keeping updates for
> iceweasel 3.5 in pending/frozen. It would also allow me to push
> iceweasel 4.0 betas to experimental, where they would be better suited
> than their current location, where they are not even built on non
> x86/x86-64.

With something like iceweasel, is there frankly any point in building
experimental versions on architectures which can barely handle the
stable releases? How many users are there using iceweasel not on
x86/x86-64?
 
> This could be more work, but I understand that for people who want to
> do it, the testing freeze time is frustrating.

New versions break stuff - there has to be a way of stabilising
bleeding-edge code and that should not be in a quiet backwater with no
users.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgprWd0xrIva2.pgp
Description: PGP signature

Re: unstable/testing/[pending/frozen/]stable

[Mike Hommey]

On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote:
> > Then unstable/testing would roll further as usual
> 
> How does a major, disruptive, transition get done?

I think his proposal boils down to this: we *always* have unstable and
testing to upload whatever we want and handle transitions when we like.
Then, parallel to unstable/testing, there would be the pending/frozen
suites to work on the release.
Saying it a bit differently, we would *also* already be working on
release+1 while release is being frozen. I kind of like the idea.

To give an example with package names, I would already upload iceweasel
3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies
until they are fixed to use xulrunner 1.9.2, while keeping updates for
iceweasel 3.5 in pending/frozen. It would also allow me to push
iceweasel 4.0 betas to experimental, where they would be better suited
than their current location, where they are not even built on non
x86/x86-64.

This could be more work, but I understand that for people who want to
do it, the testing freeze time is frustrating.

Mike

PS: for my personal needs, some way to get random packages autobuilt
would already be helpful (call that ppa if you want).


-- 
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/20100922064731.ga16...@glandium.org

Re: unstable/testing/[pending/frozen/]stable

[Neil Williams]

On Tue, 21 Sep 2010 20:52:09 -0400
Yaroslav Halchenko  wrote:

> Hi All,
> 
> CUT discussions at debconf10 and recent news of the birth of Linux
> Mint Debian Edition (LMDE) [1] show how valuable and unique  Debian's
> rolling distribution (testing) is.  But every freeze in the
> preparation to upcoming stable release in effect, eliminates
> 'testing' (and actually unstable... 

I don't see what that is meant to mean. Testing and unstable are
constantly present and functional during a freeze. What happens is that
the pace of new (disruptive) uploads and migrations is manually
limited. i.e. the stability and functionality of testing and unstable
*rise* during a release freeze simply because new transitions are not
started - in unstable or testing.

Unstable needs to be managed during a freeze because it is the
destination of uploads which fix RC bugs in testing. If there was a new
migration/transition in unstable affecting this package, the new upload
cannot migrate (and cannot fix the bug). Testing-proposed-updates isn't
an excuse for making a mess of unstable during a freeze.

> since experimental is not a
> complete distribution and we can't force users to use something with
> that name ;) ) until new stable sees the world. I wondered, why don't
> we have
> 
> [experimental/]unstable(sid)/testing(e.g squeeze)/stable
> 
> *constantly* present and functioning all the time the same way.

So when and where are library transitions meant to occur? Transitions
are always disruptive, always cause some packages to be non-functional
or non-installable. There has to be somewhere (unstable) where libfoo2
can be uploaded with libfoo2-dev so that all packages which depend on
libfoo1 can start the migration to the new API. As the migration
starts, there is a period (which in the case of GTK1->2 took several
years) where many packages in unstable are uninstallable or FTBFS or
just horribly buggy.

> Then upon freeze we just copy the state of
>   unstable -> pending
>   testing(squeeze) -> frozen(squeeze, e.g together with a codename)
> and link new codename (e.g. wheezy) against testing.

unstable is not compatible with *-proposed-updates - nor is having
*-proposed-updates an excuse for starting new transitions in unstable
during a freeze.

> Then unstable/testing would roll further as usual

How does a major, disruptive, transition get done?

>, and pending->frozen
> according to the freeze schedule.  This would enable CUTs, fulfill
> the ideas behind LMDE to have something rolling without hickups, and
> users of 'testing' (and unstable) would enjoy testing/unstable the way
> they usually do.
> 
> I understand that it would require more work, but I think benefits
> would overweight the burden.
> 
> But I cannot be first thinking about that, and I bet there were good
> reasons why such approach was not taken -- could anyone
> enlighten/point me to the shortcomings?

In a word, transitions.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgp2oooMpquY1.pgp
Description: PGP signature