On Mon, Oct 30, 2006 at 01:46:24PM +1000, Anthony Towns wrote:
> Wouter? Michael?
Sorry. Ack, on all this. It sounds like the best thing to do.
Now all I need is to make some time to figure out how all this is
supposed to work, and I can jump in.
--
Home is where you have to wash the dishes.
> On Sat, Oct 28, 2006 at 11:34:24AM +1000, Anthony Towns wrote:
> > No, I just like to know what we're trying to achieve before starting to
> > do anything.
> >
> > Okay, so the idea is:
> >
> > (a) move m68k from etch to testing-m68k
Ack.
> > (b) automatically promote m68k packages from uns
On Sat, Oct 28, 2006 at 11:34:24AM +1000, Anthony Towns wrote:
> No, I just like to know what we're trying to achieve before starting to
> do anything.
>
> Okay, so the idea is:
>
> (a) move m68k from etch to testing-m68k
>
> (b) automatically promote m68k packages from unstable to testing-m
Anthony Towns writes:
> Okay, so the idea is:
>
> (a) move m68k from etch to testing-m68k
>
> (b) automatically promote m68k packages from unstable to testing-m68k
> when the same version gets promoted into etch.
Which, since no special britney run is done, makes it absolutely and
exac
On Sat, Oct 28, 2006 at 11:34:24AM +1000, Anthony Towns wrote:
> (d) over time, improve the promotion rules for testing-m68k to be
> a proper m68k-only britney run with appropriate criteria for
> m68k (for example, counting debian-68k@lists.debian.org:m68k-rc
> usertagged bugs a
On Saturday 28 October 2006 03:34, Anthony Towns wrote:
> (a) move m68k from etch to testing-m68k
>
> (b) automatically promote m68k packages from unstable to testing-m68k
> when the same version gets promoted into etch.
(b1) Get the installer to support the testing-m68k and possibly als
On Fri, Oct 27, 2006 at 05:55:13PM +0200, Michael Schmitz wrote:
> > testing-m68k == having something that updates from unstable at its own
> > pace for m68k only. That might mean lagging behind the real testing if
> > there are toolchain problems, eg. If you wanted it to, it could mean
> > advanci
On Fri, Oct 27, 2006 at 05:55:13PM +0200, Michael Schmitz wrote:
> On Fri, 27 Oct 2006, Anthony Towns wrote:
> > > Isn't it going to be so that we'd be able to do our own
> > > arch-specific NMUs in both cases? Or is it in both cases going to be a
> > > matter of deciding which package will be part
On Fri, 27 Oct 2006, Anthony Towns wrote:
> On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
> > Um, I think I've missed something. What'd be the functional difference
> > between the two?
>
> testing-m68k == having something that updates from unstable at its own
> pace for m68k onl
Anthony Towns writes:
> On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
>> Um, I think I've missed something. What'd be the functional difference
>> between the two?
>
> testing-m68k == having something that updates from unstable at its own
> pace for m68k only. That might mean
On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
> Um, I think I've missed something. What'd be the functional difference
> between the two?
testing-m68k == having something that updates from unstable at its own
pace for m68k only. That might mean lagging behind the real testing i
Anthony Towns writes:
> On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote:
>> On Fri, 27 Oct 2006, Anthony Towns wrote:
>> > Personally, I think m68k would be better served by having a testing-m68k
>> > and taking occassional snapshots which serve as the supported stable-m68k
>> > rele
Hi,
On Fri, 27 Oct 2006, Anthony Towns wrote:
> On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote:
> > On Fri, 27 Oct 2006, Anthony Towns wrote:
> > > Personally, I think m68k would be better served by having a testing-m68k
> > > and taking occassional snapshots which serve as the supp
On Fri, Oct 27, 2006 at 06:38:55PM +1000, Anthony Towns wrote:
> On Fri, Oct 20, 2006 at 08:21:15PM -0500, Stephen R Marenka wrote:
> > >(c) not bother with an etch-equivalent release for m68k
> > I'm not sure about this. I'd sure like to have some form of stable, even
> > if we only do base an
On Fri, Oct 27, 2006 at 09:43:44PM +1000, Anthony Towns wrote:
> > The only problem right now is our backlog and we'll hopefully
> > see soon how quickly it can be reduced via distcc.
> FWIW, that would be a lot more convincing if it had happened a year ago
> when it was last suggested...
> http:
On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote:
> On Fri, 27 Oct 2006, Anthony Towns wrote:
> > Personally, I think m68k would be better served by having a testing-m68k
> > and taking occassional snapshots which serve as the supported stable-m68k
> > release, rather than worrying abou
Hi,
On Fri, 27 Oct 2006, Anthony Towns wrote:
> Personally, I think m68k would be better served by having a testing-m68k
> and taking occassional snapshots which serve as the supported stable-m68k
> release, rather than worrying about something equivalent to etch itself.
Why should we do this? A
On Fri, Oct 20, 2006 at 08:21:15PM -0500, Stephen R Marenka wrote:
> >(c) not bother with an etch-equivalent release for m68k
> I'm not sure about this. I'd sure like to have some form of stable, even
> if we only do base and security-support base-type packages. I'd hate to
> have to maintain
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Sat, Oct 21, 2006 at 06:58:21AM +1000, Anthony Towns wrote:
>> Hey all,
>>
>> So, from the other thread, seems like the idea for m68k is:
>>
>>(a) keep building unstable as per usual
A per architecture tracking of arch:all package would be ni
> * Wouter Verhelst ([EMAIL PROTECTED]) [061023 20:58]:
> > On Sat, Oct 21, 2006 at 06:58:21AM +1000, Anthony Towns wrote:
> > > I'd suggest it'd probably be ideal to have either two or three people
> > > doing it -- you have to already be a DD though. It might also be
> > > worthwhile to join the
* Wouter Verhelst ([EMAIL PROTECTED]) [061023 20:58]:
> On Sat, Oct 21, 2006 at 06:58:21AM +1000, Anthony Towns wrote:
> > I'd suggest it'd probably be ideal to have either two or three people
> > doing it -- you have to already be a DD though. It might also be
> > worthwhile to join the RM team as
On Sat, Oct 21, 2006 at 06:58:21AM +1000, Anthony Towns wrote:
> Hey all,
>
> So, from the other thread, seems like the idea for m68k is:
>
>(a) keep building unstable as per usual
>
>(b) maintain a separate testing-like suite for m68k based on (and
>thus probably trailing) the r
> So, from the other thread, seems like the idea for m68k is:
>
>(a) keep building unstable as per usual
ack ...
>
>(b) maintain a separate testing-like suite for m68k based on (and
>thus probably trailing) the real testing, maintained by m68k
>porters, that is installable
On Sat, Oct 21, 2006 at 06:58:21AM +1000, Anthony Towns wrote:
> Hey all,
>
> So, from the other thread, seems like the idea for m68k is:
>
>(a) keep building unstable as per usual
ack
>(b) maintain a separate testing-like suite for m68k based on (and
>thus probably trailing) th
Hey all,
So, from the other thread, seems like the idea for m68k is:
(a) keep building unstable as per usual
(b) maintain a separate testing-like suite for m68k based on (and
thus probably trailing) the real testing, maintained by m68k
porters, that is installable (using d-i
25 matches
Mail list logo
