Pierre Habouzit <madcoder@madism.org> writes:

> On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote:
>> Pierre Habouzit <madcoder@madism.org> writes:
>>
>> > 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?
>>
>> Say you have just uploaded a new upstream release to unstable and then
>> someone reports a RC bug against testing. Pushing this untested version
>> into rolling isn't the right thing.
>>
>> Would a t-p-u upload get added to rolling quickly too in those cases?
>> What if testing is frozen?
>
> I'd say let's see with the reality if it works or not. It's clear that
> rolling will have RC bugs. The question is "will it be bearable or not".
> I think so. with "what if" discussions we'll go nowhere, that's why I'd
> be in favor of a small experiment with the smallest amount of work to be
> done (my "just use a britney to chose between unstable and testing and
> nothing more" proposal), and see how well/bad that performs.

Hell, why britney? Just set up a reprepro that updates from unstable
with a filter to only pull the handfull of packages rolling should have
in addition / instead of testing. Then you add

deb http://ftp.debian.org/debian testing main
deb http://rolling.debian.net/debian rolling main

and you are ready to test. I actually would really like to see that
tested. If you find someone to host it I can clobber you together the
filter and config for reprepro.


I don't think the problem will be in creating the actual archive. Not to
start testing the idea. If it uses reprepro or a trivial britney reuse
or someone eventually writes a more complex DAK extention won't be the
problem at the start.

The problem will be in building the support team and procedures and
mechanisms to tune the filter. To decide what goes into rolling and what
not. Up to deciding how (if?) individual DDs should be able to mark
their packages to go in.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tyd8yd56.fsf@frosties.localnet">http://lists.debian.org/87tyd8yd56.fsf@frosties.localnet

On Fri, May 06, 2011 at 12:51:33AM +0200, Goswin von Brederlow wrote:
> Pierre Habouzit <madcoder@madism.org> writes:
>
> > On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote:
> >> Pierre Habouzit <madcoder@madism.org> writes:
> >>
> >> > 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?
> >>
> >> Say you have just uploaded a new upstream release to unstable and then
> >> someone reports a RC bug against testing. Pushing this untested version
> >> into rolling isn't the right thing.
> >>
> >> Would a t-p-u upload get added to rolling quickly too in those cases?
> >> What if testing is frozen?
> >
> > I'd say let's see with the reality if it works or not. It's clear that
> > rolling will have RC bugs. The question is "will it be bearable or not"..
> > I think so. with "what if" discussions we'll go nowhere, that's why I'd
> > be in favor of a small experiment with the smallest amount of work to be
> > done (my "just use a britney to chose between unstable and testing and
> > nothing more" proposal), and see how well/bad that performs.
>
> Hell, why britney?

To compute something that is actually installable and maximizes the
installability count doh!
--
·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: 20110505225350.GB636@madism.org">http://lists.debian.org/20110505225350.GB636@madism.org

On Thu, May 05, 2011 at 07:48:45PM +0200, Carsten Hey wrote:
> * Pierre Habouzit [2011-05-05 07:46 +0200]:
> > On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote:
> > > 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.).
>
> So rolling would principally also be frozen during testing's freeze,
> this is not what the name seems to imply.
>
> Unlike variants where rolling would really roll, this one does not
> require an additional pseudo-suite in Debian [1] and could be
> implemented on rolling.debian.net without convincing the release team
> and ftpmaster first.

There have been several DDs on -devel@ epressing concerns about the fact
that having something unfreezed during the freeze would divert the
attention from the release and many people don't want it to happen
(including me).

OTOH if Debian is more tested before the freeze thanks to rolling, it
can help to reduce the freeze length…
--
·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: 20110505230603.GC636@madism.org">http://lists.debian.org/20110505230603.GC636@madism.org

On Fri, May 06, 2011 at 00:36:23 (CEST), Russ Allbery wrote:

> Steve Langasek <vorlon@debian.org> writes:
>> On Thu, May 05, 2011 at 10:39:29AM -0700, Russ Allbery wrote:
>
>>> Yes, during the freeze I ran into trouble with OpenAFS because I had
>>> too many different streams that I wanted to test at the same time. I
>>> was using experimental for the upcoming 1.6 release, which I really
>>> wanted to have available in Debian for people to test but which is a
>>> huge technological change, and there were also new stable 1.4 releases
>>> that (in a rolling model) should have gone into unstable and then into
>>> rolling. But I was holding unstable free to handle point fixes for
>>> testing.
>
>> We do have testing-proposed-updates as a mechanism for getting updates
>> into testing when unstable contains packages not suitable for release.
>> Under these circumstances, wouldn't it have been better to upload the
>> new 1.4 releases to unstable and use testing-proposed-updates for any
>> critical issues that came up? Maybe we've simply become too
>> conservative about keeping the unstable->testing path unblocked, when we
>> should be relying more on t-p-u (which AFAICS, is more reliable now than
>> it was when I was RM)?
>
> I considered it, but I'm really worried about t-p-u not getting enough
> testing. Maybe enough people are now using proposed-updates during freeze
> testing that it's not an issue. The stuff going into stable is what needs
> to be tested the most heavily; I wasn't as worried about the new 1.4
> releases, since they were going to have plenty of time to be tested
> anyway.

This anectode makes me wonder if t-p-u (or some suitable alias) should
be enabled by default.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tyd8z4qn.fsf@faui44a.informatik.uni-erlangen.de">http://lists.debian.org/87tyd8z4qn.fsf@faui44a.informatik.uni-erlangen.de

2011/5/5 Raphael Hertzog <hertzog@debian.org>:
> On Thu, 05 May 2011, Stefano Zacchiroli wrote:
>> Also, having the unstable-next suite you've mention would tight more the
>> deployment of rolling to other project mechanisms, while the rest of the
>> proposal enjoyed much more decoupling.
>
> There's no reason why this unstable-next would be a requirement to start
> rolling. It's just a suggestion of how to handle package updates during
> the freeze.

I've been disappointed at first to read that so many approve this
"rolling" implementation that in fact is just "c-u-t", constantly
usable testing [1]! Outside of the freeze period it doesn't really
matter and one can say rolling==cut.

However, some key points added later with 'unstable-next' really
completes the missing piece to call it "rolling"! During the freeze
"unstable" is in a de facto freeze, but packages not suited for the
next stable release in preparation could be uploaded to
'unstable-next'. The 'unstable-next' suite could be used for several
purposes:
1) some packages could be picked from it for 'unstable' -> "testing"
2) all packages from "unstable-next" are a candidate for "rolling"
3) after the final stable release all packages could be moved directly
from 'unstable-next' to 'unstable'.

Although #3 might not be practical without other infrastructure
changes, but was the core of this discussion in debian-devel.
"rolling" has only derived from not freezing "unstable", but the
initial proposal was to be able to never freeze unstable. It is my
believe that by using the freeze time to upload packages as usual will
help to prepare the next release by extending the pre-freeze
development from 1.5 years to 2 years.

To conclude, "unstable-next" suite (or some other name [2]) is a
requirement for "rolling" [3].

Thanks

[1] although the CUT team might have a different view for 'cut', I
don't know what's the current direction
[2] but not "experimental"
[3] I agree with Raphael that is not a requirement to *start* "rolling"


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

On May 9, 2011 08:48:25 am Teodor MICU wrote:
> To conclude, "unstable-next" suite (or some other name [2]) is a
> requirement for "rolling" [3].
>
> Thanks
>
> [2] but not "experimental"

...unless the nature of experimental is changed, and its current function
replaced with PPA's?

- Bruce


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

Hi Teodor/Bruce,

On Mon, May 09, 2011 at 05:48:25PM +0300, Teodor MICU wrote:
> I've been disappointed at first to read that so many approve this
> "rolling" implementation that in fact is just "c-u-t", constantly
> usable testing [1]! Outside of the freeze period it doesn't really
> matter and one can say rolling==cut.

On Mon, May 09, 2011 at 11:36:04AM -0600, Bruce Sass wrote:
> On May 9, 2011 08:48:25 am Teodor MICU wrote:
> > To conclude, "unstable-next" suite (or some other name [2]) is a
> > requirement for "rolling" [3].
>
> ...unless the nature of experimental is changed, and its current function
> replaced with PPA's?

DEP-10 is focused entirely on how we can avoid and/or circumvent the
freeze process (for things not concerning the next stable release),
which is helpful by itself but also a key part of a working rolling
release, I'd say.

I'm trying to cover most of the ideas discussed in the previous mega-thread
for how this could be done, including both of the "unstable-updates" and
the "PPA's" approach, and maybe a couple more. I'm still putting meat
onto the document but in the next couple days I'll bring it back on list
for a more thorough discussion. So please keep any ideas you have about
either of these approaches readily available


sean


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