On Wed, Oct 18, 2006 at 12:59:20PM +0200, Michael Schmitz wrote: > Regarding a solution for m68k beyond etch - I'd prefer to keep m68k > snapshots on a basis like you mentioned: > * have m68k be in unstable, and have it have its own "testing-like" > suite of some description > + keeps the arch alive > - some work to keep m68k-testing in sync with real testing needed > - doesn't have real releases > - may not have security support > So, if someone could give me a brief intro as to how testing migration of > packages works, and what would be needed to modify britney, I'd welcome > it. The idea, presumably, would be to have a separate britney instance just for m68k. That would mean that testing itself wouldn't be held back by any m68k problems, but would also mean that m68k wouldn't necessarily be held back by non-m68k problems -- eg, if something doesn't build on sparc, it could be updated for testing-m68k but not testing proper. The problem comes for things like transitions and so forth, where britney can't work out that it's okay to upgrade foo as long as libfoo and libbar are upgraded at the same time -- that often needs someone to follow the britney output and manually note down the things that work. Sometimes for large transitions you can't do it completely smoothly and something will need to break -- and a human needs to choose which is the least bad thing to have break, so britney will need some help there too. One way of doing that is just to mimic what the release team currently do. Another option is to have the m68k testing stuff be based on the real release hints -- so that once something has gone into testing proper, it could be forced into testing-m68k despite what gets broken, somehow. Note that without a stable release, you'll need to maintain some way to deal with people who want to install on m68k -- you can't just rely on them installing stable and upgrading to testing. Cheers, aj
Attachment:
signature.asc
Description: Digital signature