On Wednesday, May 04, 2011 04:25:35 PM Stefano Zacchiroli wrote:
> On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
> > What to do during freezes
> > -------------------------
> >
> > If we want to do something different though, there is a simple recipe:
> > allow packages to be picked up from unstable, but also from
> > experimental.
>
> Yes, absolutely. This seems straightforward, elegant, and useful as it
> encourages maintainer to push their changes to the Debian archive and
> make them visible and testable to rolling users, even when unstable is
> de facto closed.

Does this mean Experimental should be renamed Unfrozen?

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201105041658.32267.debian@kitterman.com">http://lists.debian.org/201105041658.32267.debian@kitterman.com

> What to do during freezes
> -------------------------
> I’m not sure we really need to do something different in times of
> freeze. Our time would be better spent by reducing the freeze time and
> making it more predictable; squeeze has been an awesome step in this
> direction.
>
> If we want to do something different though, there is a simple recipe:
> allow packages to be picked up from unstable, but also from
> experimental. Again, no disruption: people can keep on breaking some
> pieces of experimental, but if they want some other pieces to be useful
> for rolling users, they just need to be committed to more carefulness
> and to add them to the override file.

I also find this a very good implementation, although I would like a 'true'
rolling release, without any freezes at all. I'm not sure how much extra work it
implies or how much sense it would make to have an exact clone of testing just
without the freezes.

--

Best regards,
Mit freundlichen Grüßen,

Cristian Henzel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DC1BF92.7050602@b3r3.info">http://lists.debian.org/4DC1BF92.7050602@b3r3.info

Hiya,

On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote:
> On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
> > What to do during freezes
> > -------------------------
> > If we want to do something different though, there is a simple recipe:
> > allow packages to be picked up from unstable, but also from
> > experimental.
>
> Yes, absolutely. This seems straightforward, elegant, and useful as it
> encourages maintainer to push their changes to the Debian archive and
> make them visible and testable to rolling users, even when unstable is
> de facto closed.

It's an excellent idea. Some of the initial feedback that I've gotten
about DEP-10 (in particular some brainstorming on IRC with Carsten Hey)
is pointing at ideas along these lines, and I hope to flush them out
in a bit more detail RSN. But I think it's particularly exciting that
these two ideas (rolling, and dealing with freezes) might not conflict
with each other, and perhaps complement one another.

One issue that would need to be addressed with experimental is that
opening a migration route anywhere out of experimental might come as
an unpleasant surprise to some, since there's a standing expectation
that it's a pseudo-suite where we can put stuff that we don't necessarily
want to try out in unstable. Not an insurmountable problem (either we
change that or introduce yet another psuedo-suite for this purpose),
but worth note anyway.


sean


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110504214045.GA4343@cobija.connexer.com">http://lists.debian.org/20110504214045.GA4343@cobija.connexer.com

On Wed, May 4, 2011 at 6:40 PM, sean finney <seanius@debian.org> wrote:
[...]
> On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote:
>> On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
>> > * What to do during freezes
>> > * -------------------------
>> > If we want to do something different though, there is a simple recipe:
>> > allow packages to be picked up from unstable, but also from
>> > experimental.
>>
[...]
>
> One issue that would need to be addressed with experimental is that
> opening a migration route anywhere out of experimental might come as
> an unpleasant surprise to some, since there's a standing expectation
> that it's a pseudo-suite where we can put stuff that we don't necessarily
> want to try out in unstable. *Not an insurmountable problem (either we
> change that or introduce yet another psuedo-suite for this purpose),
> but worth note anyway.

Indeed. I guess we could specify a flag in this overrides file that
says whether or not it's fine to fetch from experimental (defaulting
to off). That way it would be up to the maintainer to specify that
experimental is good and stable enough for rolling.

I really like this new proposal, nice job.

Regards,


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTin4VNuMS0QbqE1rUvubkeZyrHuLCw@mail.gmail.com ">http://lists.debian.org/BANLkTin4VNuMS0QbqE1rUvubkeZyrHuLCw@mail.gmail.com

On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote:
> * Pierre Habouzit [2011-05-04 22:23 +0200]:
> > On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote:
> > > Le mercredi 04 mai 2011 Ã* 22:12 +0200, Lucas Nussbaum a écrit :
> > > > While I like the idea in general, I think that it should also be
> > > > possible to upload packages directly to rolling (through
> > > > rolling-proposed-updates). It will be useful in cases where neither the
> > > > package in testing, not the package in unstable, can be used to fix a
> > > > problem in rolling.
> > >
> > > Adding this possibility is opening Pandora’s box. Once you allow this,
> > > people start using packages that are neither in unstable nor in testing,
> > > and they don’t help us working on our packages at all. This also adds an
> > > extra burden on maintainers who want to use this feature.
> > >
> > > Could you please give a concrete example of where this would be needed?
> > > I think all existing cases should be covered by uploading directly to
> > > either t-p-u or unstable.
> >
> > Agreed, the entry point for rolling is clearly just unstable + a force
> > hint. Why would you need to upload something to rolling that you
> > couldn't make enter through unstable?
>
> If more new upstream versions are uploaded to unstable (because they are
> targeted at rolling), it raises the number of RC bugs needing to migrate
> to testing through t-p-u. How would you ensure that they get enough
> testing before entering testing?

That's the point, you don't target rolling, your goal is still to make
stuff migrate into testing, rolling is just the extra few packages
testing needs to fix the most important breakages that happen (e.g. your
PAM example, or large migrations where dependencies across libraries are
too loose and break testing, Joss said it happens to gnome quite a lot
e.g.).

IOW to target rolling you target testing, IOW you help doing stable
stuff, isn't that nice?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110505054655.GA26389@madism.org">http://lists.debian.org/20110505054655.GA26389@madism.org

On Thu, May 05, 2011 at 12:05:22AM +0300, Cristian Henzel wrote:
> > What to do during freezes
> > -------------------------
> > I’m not sure we really need to do something different in times of
> > freeze. Our time would be better spent by reducing the freeze time and
> > making it more predictable; squeeze has been an awesome step in this
> > direction.
> >
> > If we want to do something different though, there is a simple recipe:
> > allow packages to be picked up from unstable, but also from
> > experimental. Again, no disruption: people can keep on breaking some
> > pieces of experimental, but if they want some other pieces to be useful
> > for rolling users, they just need to be committed to more carefulness
> > and to add them to the override file.
>
> I also find this a very good implementation, although I would like a 'true'
> rolling release, without any freezes at all. I'm not sure how much extra work it
> implies or how much sense it would make to have an exact clone of testing just
> without the freezes.

Not a lot, I don't expect it larger than having to place a dozen hints
usually, up to a small hundred during the peaks (100 is less than 1% of
our source packages).

Maintaining something like that isn't hard, it's already what the RM
Team does to follow testing migrations, and if rolling is generated
after testing is, the Rolling Team will benefit from the RT work so it's
just an incremental effort. Nothing wasted.

(And not wanting to finger point but I've read at least a certain RT
Member saying that he would even consider help a Rolling Team as he's
already doing that pinning on his workstation…)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110505055010.GB26389@madism.org">http://lists.debian.org/20110505055010.GB26389@madism.org

On 04/05/11 at 22:19 +0200, Josselin Mouette wrote:
> Le mercredi 04 mai 2011 Ã* 22:12 +0200, Lucas Nussbaum a écrit :
> > While I like the idea in general, I think that it should also be
> > possible to upload packages directly to rolling (through
> > rolling-proposed-updates). It will be useful in cases where neither the
> > package in testing, not the package in unstable, can be used to fix a
> > problem in rolling.
>
> Adding this possibility is opening Pandora’s box. Once you allow this,
> people start using packages that are neither in unstable nor in testing,
> and they don’t help us working on our packages at all. This also adds an
> extra burden on maintainers who want to use this feature.
>
> Could you please give a concrete example of where this would be needed?
> I think all existing cases should be covered by uploading directly to
> either t-p-u or unstable.

Use case:
During freeze, there's a library transition in unstable, and a new
upstream version in unstable. You want to get the new upstream version
into rolling (not testing), but you can't because it would pull the
whole transition.
So you need a way to upload the new upstream version linked against the
libraries in rolling.

- Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110505062334.GA3055@xanadu.blop.info">http://lists.debian.org/20110505062334.GA3055@xanadu.blop.info

On 05/05/2011 08:50 AM, Pierre Habouzit wrote:
> On Thu, May 05, 2011 at 12:05:22AM +0300, Cristian Henzel wrote:
>>> What to do during freezes
>>> -------------------------
>>> I’m not sure we really need to do something different in times of
>>> freeze. Our time would be better spent by reducing the freeze time and
>>> making it more predictable; squeeze has been an awesome step in this
>>> direction.
>>>
>>> If we want to do something different though, there is a simple recipe:
>>> allow packages to be picked up from unstable, but also from
>>> experimental. Again, no disruption: people can keep on breaking some
>>> pieces of experimental, but if they want some other pieces to be useful
>>> for rolling users, they just need to be committed to more carefulness
>>> and to add them to the override file.
>>
>> I also find this a very good implementation, although I would like a 'true'
>> rolling release, without any freezes at all. I'm not sure how much extra work it
>> implies or how much sense it would make to have an exact clone of testing just
>> without the freezes.
>
> Not a lot, I don't expect it larger than having to place a dozen hints
> usually, up to a small hundred during the peaks (100 is less than 1% of
> our source packages).
>
> Maintaining something like that isn't hard, it's already what the RM
> Team does to follow testing migrations, and if rolling is generated
> after testing is, the Rolling Team will benefit from the RT work so it's
> just an incremental effort. Nothing wasted.
>
> (And not wanting to finger point but I've read at least a certain RT
> Member saying that he would even consider help a Rolling Team as he's
> already doing that pinning on his workstation…)

I just thought that most DDs would have more important stuff to do during
freezes than cherry-picking packages from unstable to rolling, thus a clone of
testing minus the freezes, if done right, might mean a lot less work in that regard.

--
Best regards,
Mit freundlichen Grüßen,

Cristian Henzel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DC247A6.7050708@b3r3.info">http://lists.debian.org/4DC247A6.7050708@b3r3.info

Hi,

On Wed, 04 May 2011, sean finney wrote:
> It's an excellent idea. Some of the initial feedback that I've gotten
> about DEP-10 (in particular some brainstorming on IRC with Carsten Hey)
> is pointing at ideas along these lines, and I hope to flush them out
> in a bit more detail RSN. But I think it's particularly exciting that
> these two ideas (rolling, and dealing with freezes) might not conflict
> with each other, and perhaps complement one another.
>
> One issue that would need to be addressed with experimental is that
> opening a migration route anywhere out of experimental might come as
> an unpleasant surprise to some, since there's a standing expectation
> that it's a pseudo-suite where we can put stuff that we don't necessarily
> want to try out in unstable. Not an insurmountable problem (either we
> change that or introduce yet another psuedo-suite for this purpose),
> but worth note anyway.

Yeah, experimental is not really the good place. We really want in
rolling only packages where we have the assurance that they will land
in unstable the day after the release (so automatically and not with
a manual source upload).

So I'd favor some sort of unstable overlay that is not experimental.
It could be called "unstable-next" and could be auto-generated from
uploads targetting unstable that introduce a new upstream version.
That way by default unstable doesn't move forward with new upstream
version and can always be used to upload bugfixes targetting testing.

Auto-building in unstable-next would be like experimental, i.e. it
would be built in unstable so that it's still possible to pick
packages there in the rare case where a new upstream version is
desired late in the release cycle.

I like where this is going!

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110505064610.GD30317@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110505064610.GD30317@rivendell.home.ouaza.com

Le jeudi 05 mai 2011 Ã* 08:23 +0200, Lucas Nussbaum a écrit :
> > Could you please give a concrete example of where this would be needed?
> > I think all existing cases should be covered by uploading directly to
> > either t-p-u or unstable.
>
> Use case:
> During freeze, there's a library transition in unstable, and a new
> upstream version in unstable. You want to get the new upstream version
> into rolling (not testing), but you can't because it would pull the
> whole transition.

You don’t need to pull the whole transition, that’s the point of my
proposal. You just need to put the library being transitioned and your
package.

> So you need a way to upload the new upstream version linked against the
> libraries in rolling.

Alternatively, if testing is so broken you need that new upstream
version and it can build against the testing libraries, you can use
testing-proposed-updates - in all cases, for both testing and rolling, a
targeted fix being preferable.

--
.'`. Josselin Mouette
: :' :
`. `'
`-