[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: experimental codename



Graham Wilson <graham@debian.org> writes:

> On Mon, Dec 15, 2003 at 02:10:22PM +0100, Arnaud Vandyck wrote:

[...]

>> What I'm trying to explain is that I like the idea of an extra pool
>> with the buildd and bts but no automatic move to another pool. I
>> think, DD and people with chroot can point to this distribution to
>> test things and it could be a buffer for the new packages.
>
> If this would lead to more developers and beta-testers being able to
> use experimental, then I think this would be a good idea. People might
> upload there newer more in-development packages here first, instead of
> to unstable.
>
> Now that I think about it though, this is already possible. You can
> pin all of experimental just as high as unstable in the APT
> preferences file. I think the only difference now between your
> proposal and reality is support from the buildd's (I believe
> experimental has fairly good support in the BTS).

Also, it's not the same url in the sources.list s/unstable/experimental/
it's a bit different and for different arches. What about the arches
`all'? Well, I'm maybe a particular case: powerpc + java ;) but it could
be the same with sparc + perl or else. Where can I have more information
about experimental?

>> We put every new packages in `Scud' and when accepted, after some
>> test by others, we can safer move it to `Sid' with less delay.
>
> Every new package, or every new upload? The former might be alright,
> but the latter would make experimental to unstable what unstable is to
> testing.

The first. As I explain in the begining of my mail, I don't want to
reproduce unstable -> testing because of the non automatic move from
`Scud' to `Sid'.

The main point for me is the buildd and experimental to be a copy *plus*
exception distribution (the plus exception are _the_ experimental
packages).

Hope to be clearer,

Cheers,

-- 
  .''`. 
 : :' :rnaud
 `. `'  
   `-    

Attachment: pgp2v3vHtptUC.pgp
Description: PGP signature


Reply to: