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
Attachment:
signature.asc
Description: Digital signature