FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-04-2011, 03:53 PM
Ansgar Burchardt
 
Default A concrete proposal for rolling implementation

Hi,

Josselin Mouette <joss@debian.org> writes:
> The new “rolling” suite
> -----------------------
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.
>
> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up
> packages from unstable. Typically it would be generated from an override
> file that looks like:
> source-package version
> xserver-xorg-video-ati 1.2.3-4

I don't think this needs to be restricted to a subset of architectures
when you allow "rolling" to pick different versions[1] for each arch.

[1] including none if the required version is not available in unstable

> A concrete example
> ------------------
> Let’s imagine something that might happen soon (although of course we
> will try hard for it not to happen): a new version of nautilus migrates
> to testing, but it was missing a Breaks - it doesn’t work with the
> version of gnome-settings-daemon in testing. The new
> gnome-settings-daemon in unstable works, but it won’t migrate because
> there is a libgnomekbd transition in progress, and gnome-screensaver
> which is part of the transition doesn’t build on s390.
>
> In this case, we can just add libgnomekbd and gnome-settings-daemon to
> the override file. Users of the rolling suite will have the two versions
> of libgnomekbd available, and they can update their systems to a working
> state.

In this case, you could add the newer version to "rolling" for all
architectures except s390. This way all users not using s390 could
already upgrade to the new version.

Ansgar


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: s2saaf2tqba.fsf@bistromathics.mathi.uni-heidelberg.de">http://lists.debian.org/s2saaf2tqba.fsf@bistromathics.mathi.uni-heidelberg.de
 
Old 05-04-2011, 04:03 PM
Josselin Mouette
 
Default A concrete proposal for rolling implementation

Le mercredi 04 mai 2011 * 16:20 +0200, Raphael Hertzog a écrit :
> A full suite can have 2 versions of the same source package and
> can contain both libgnomekbd4 and libgnomekbd7. It's not a problem.

OK, so I officially do not care a shit™.

> > What the britney-like thing could do is bring automatically all
> > dependencies that are actually necessary for the package to be
> > installable. But this could also make things more complicated, since
> > britney tests source packages, not binaries. You might bring a source in
> > rolling only for a runtime that is needed, but the development header
> > being uninstallable is not a problem. Britney would prevent that, while
> > it would still be a good move.
>
> Yes, we could try to improve britney towards this.
>
> But I'm not sure it's a good idea to pick only some binary packages from a
> source package. It happens often enough that the package lack a strict
> dependency that might be required and picking all the binaries from a
> source package limits the risk of upgrading them separately (and thus
> experiencing the bug).

Indeed. The appropriate result to obtain would be something like: “the
list of source packages you need to pull for a given binary package to
be installable”.

> > I’m not entirely sure, but I think it’s better to pick the update from
> > unstable instead of letting in rolling a package that is no longer
> > available somewhere else. It should make upgrades smoother, and it
> > should also be less work for maintainers, since it avoids having another
> > version from which problems can arise.
>
> In that case, those updates should follow the same rules than for testing
> itself. It would be unreasonable to accept the new unstable upload
> immediately.

I don’t think it would be entirely unreasonable, since we’re already in
the case of a specific package we had to pull from unstable, to expect
the maintainer to be careful enough. Don’t forget that we’re talking
about probably a dozen of packages at a given time.
Of course, having a delay before accepting the package seems sensible
too, so it’s not like I really care.

--
Joss


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1304524993.9090.298.camel@pi0307572">http://lists.debian.org/1304524993.9090.298.camel@pi0307572
 
Old 05-04-2011, 04:11 PM
Pierre Habouzit
 
Default A concrete proposal for rolling implementation

On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
> The new “rolling” suite
> -----------------------
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.

This is an excellente proposal which technically can be implemented this
way:

- having a new britney instance, which is chained to the result of the
"testing" britney.

- it is fed with a new hint file composed of "forced" migrations
(those are versionned), feeding the result of the testing britney
with sid.

- result is a new release only made of testing or unstable packages.

If you find the people wanting to make up the rolling team, I think it's
a few hours work to setup (and overhead on the ftp servers would just be
minimal: a new suite and associated Packages files, nothing more).

Doing it this way:
- leverages the same tools as what we have now (britney, dak);

- only uses packages either in unstable or testing, which makes
rolling a glorified Pin-file hence people using rolling don't
diverge from the stable release work and are actually *worthwile*
bug reporters and gives more coverage on testing *excellent*.

- benefits from the release work: e.g. if a package is removed from
testing, since rolling is recreated from that, it inherits that
(nothing prevents the rolling team to force it back for whichever
reason).

- allows to take snapshots of rolling on a semi-regular basis (with
associated d-i releases). E.g. every 3 months or so. Those would be
alphas before the freeze, and betas during the freeze.


I like it a lot, I'm even finding it useful: it looks like it resolves
the rolling issues for people (wrt having something like a 'Usable'
testing), but doesn't really forks testing, only glorified pinning
managed at the project level instead of on each other's machines. But it
doesn't make those users worthless to the release team, quite the
contrary.

It could even turn-up to become a useful release tool.

I just love that proposal. At least something technical that makes
sense, thanks Joss.
--
·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: 20110504161129.GH27602@madism.org">http://lists.debian.org/20110504161129.GH27602@madism.org
 
Old 05-04-2011, 08:12 PM
Lucas Nussbaum
 
Default A concrete proposal for rolling implementation

On 04/05/11 at 14:24 +0200, Josselin Mouette wrote:
> Hi,
>
> during the recent discussions about rolling, a proposal was made in a
> blog comment, and after giving it some quick thoughts, most people I’ve
> talked with seem to think it is a good idea, so it’s time for it to be
> discussed at large.
>
> It starts from the following fact: if you want a testing system that
> works correctly, you usually have to add APT lines for unstable, while
> pinning them to only install specific packages you need to unbreak
> what’s broken in unstable.
>
> The idea is to make this process automatic. Let me elaborate.
>
> The new “rolling” suite
> -----------------------
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.
>
> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up
> packages from unstable. Typically it would be generated from an override
> file that looks like:
> source-package version
> xserver-xorg-video-ati 1.2.3-4
> ...
> The rolling suite would try to have a package that has *at least* this
> version. If it is found in testing, the package is removed from rolling.
> If otherwise it is found in unstable, the package is picked from
> unstable.
>
> This way, when something is broken in testing and cannot be unbroken
> quickly, a maintainer who notices it could add (or make the people in
> charge add) the necessary packages to the override file. If, for a
> reason or another, an important bug fix or a security update doesn’t
> propagate to testing quickly enough, you can now just add it and the
> necessary dependencies to rolling, and people using it aren’t affected.
> Whenever the affected packages finally migrate to testing, the
> discrepancy between rolling and testing automatically disappears.
>
> The reason for the “at least” version rule is that new uploads to
> unstable are supposed to fix the situation in testing anyway. I don’t
> think we should keep in rolling packages that are no longer in unstable.

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.

- Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110504201222.GA31933@xanadu.blop.info">http://lists.debian.org/20110504201222.GA31933@xanadu.blop.info
 
Old 05-04-2011, 08:17 PM
Stefano Zacchiroli
 
Default A concrete proposal for rolling implementation

On Wed, May 04, 2011 at 03:30:40PM +0200, Raphael Hertzog wrote:
> On Wed, 04 May 2011, Josselin Mouette wrote:
> > It starts from the following fact: if you want a testing system that
> > works correctly, you usually have to add APT lines for unstable, while
> > pinning them to only install specific packages you need to unbreak
> > what’s broken in unstable.

Thanks for the proposal, it looks really interesting!
A few comments and some potential help/directions are below.

> It doesn't need to be a pseudo-suite. It's a collection of packages taken
> in testing or unstable, it's not more complicated to make it a full suite.
>
> And PR-wise, it's way better to avoid "testing" appearing in the
> sources.list.

I don't think that the name showing up in sources.list are important for
PR reasons. The "problem" with the current testing marketing (for those
who buy PR arguments) is not the sources.list line, but that the suite
is called that way everywhere and advertised solely as the developer /
internal suite that it is. If we advertise "rolling" with that name (and
proper explanation), what is in sources.list wouldn't really matter.

Still, having a single suite sounds more flexible: we will be able to
control the whole set of rolling packages server side, no matter what is
currently in testing. Not that I can imagine a reason for doing that
now, but having that flexibility sounds good. (And you have already
discussed that it is possible to have.)

> > The rolling suite would only exist for a subset of architectures (we
> > could start with powerpc, i386 and amd64), generated by picking up
>
> Why powerpc? If we really take more than i386/amd64 for rolling, there
> are more users of armel than of powerpc.

Beside the specific choices of architectures, I'm not sure I see which
specific problem architectures bring into the game. For testing proper,
there are some architecture alignment rules that might make transition
more complex. But for rolling as it is being proposed here, it looks
like that with per-architecture overrides we can support whatever
architecture sets we please.

Are there other constraints than manpower for the overrides that I'm
overlooking? (Note: I'm not arguing that we should have rolling for all
archs, I'm just trying to understand if I've overlooked some
constraints.)

> You still need some sort of britney to verify that the package is effectively
> installable in rolling, and to verify you're not breaking installability
> of other packages available in rolling.

If you only need installability test for binaries (and possibly even
satisfaiability of build-depends, which is currently not checked by
britney but used on buildds), edos-distcheck offers that out of the box.
It would most likely be way easier to setup than britney. For some of
the other needs expressed by Joss, we (as in Mancoosi) have most of the
code ready as well, although not necessarily packaged yet. I need to
look at the details of what Joss had in mind, but we have code ready to
answers questions like "which package do I absolutely need to be
installable in that suite?".

If you want to go ahead with patching britney, by all means go ahead, as
it might provide patches useful for the main brintey as well. But if you
want to try some alternatives, we can probably help.

> > What do you think?
> +1 from me. Thank you for the proposal!

Ditto!

Cheers.

--
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
 
Old 05-04-2011, 08:19 PM
Josselin Mouette
 
Default A concrete proposal for rolling implementation

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.

Cheers,
--
.'`. Josselin Mouette
: :' :
`. `'
`-
 
Old 05-04-2011, 08:23 PM
Pierre Habouzit
 
Default A concrete proposal for rolling implementation

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?
--
·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: 20110504202329.GA20853@madism.org">http://lists.debian.org/20110504202329.GA20853@madism.org
 
Old 05-04-2011, 08:25 PM
Stefano Zacchiroli
 
Default A concrete proposal for rolling implementation

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.

Cheers.

--
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
 
Old 05-04-2011, 08:27 PM
Pierre Habouzit
 
Default A concrete proposal for rolling implementation

On Wed, May 04, 2011 at 10:17:03PM +0200, Stefano Zacchiroli wrote:
> If you want to go ahead with patching britney, by all means go ahead, as
> it might provide patches useful for the main brintey as well. But if you
> want to try some alternatives, we can probably help.

I don't think you need to patch britney at all. Just take the last
testing computed as a testing-britney output as a start, have a list of
force-hints to be processed, taken from unstable, and there you go. It's
just a new britney run.

Admitedly there is a small patch to be done, force hints in britney are
strictly versionned, for the rolling case one may want to have looser
way to express force hints (with version ranges e.g.), but that should't
be really hard.
--
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: 20110504202724.GB20853@madism.org">http://lists.debian.org/20110504202724.GB20853@madism.org
 
Old 05-04-2011, 08:48 PM
Carsten Hey
 
Default A concrete proposal for rolling implementation

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

Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110504204846.GA27766@furrball.stateful.de">http://lists.debian.org/20110504204846.GA27766@furrball.stateful.de
 

Thread Tools




All times are GMT. The time now is 09:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org