On Thu, Dec 18, 2003 at 06:18:28PM +0100, Gaudenz Steinlin wrote: > [please keep cc'ing debian-boot, discover-workers and David Nusinow] No need to cc me, I'm subscribed to -boot, thanks :-) > 1. Alternative: > This is basically branden's proposal, see this mail[1] for more details > a) rename discover to discover1 > b) upload discover 2 as discover (with all the debs and udebs) > c) drop discover1 when discover (2) provides all the features we need > and works well This seems to be the most disruptive plan to me, which is probably not the best thing, especially if progeny wants to discover2 in to unstable to start wider testing before Sarge releases (I'm not sure what their timetable is). > 2. Alternative: > This is the oposite of 1): > a) upload discover 2 as discover2 (with all the udebs and debs) > b) drop discover (1.5) when discover2 provides all the features we need > and works well > c) rename discover2 to discover I'd be perfectly happy with this, since it entails the least amount of work on my part ;-) > 3. Alternative: > This is a variant of the 2. alternative which allows the d-i team to > move to discover 2 while not affecting normal discover users. Step a) > could also be done by the d-i team independently of progeny. > a) upload discover2 packages as discover2 with only the udebs > b) upload discover2 as discover (with all the debs and udebs) when > discover2 provides all the features we need and works well This seems like a good comprimise on all counts to me. I'd prefer this myself, especially since it allows the more relaxed and careful testing of the new package. This requires the lion's share of the work to be done by the discover2 maintainers though, and it's up to them. Isolating discover2 in the installer for its initial testing strikes me as being very wise, since unstable is in heavy daily use, while most people will just use the sarge release of d-i for day to day installs. > I personally prefer Alternative 2 or 3 (especially if progeny does not > upload discover2 packages until the end of the year), but I'm open for > suggestions and can live with every of the three variants. AOL > One other possibility I see is the introduction of a dummy package > discover to ease the transition. But I'm not sure if won't make things > more complicated as necessary. The only benefit I see in this is that it doesn't involve any waiting on the ftpmasters. Since this has shown to have been a bit of problem lately, the idea has some merit. I'd rather do things as cleanly as possible though, even at the cost of waiting a bit, so I'd say just go with package renaming. - David Nusinow
Attachment:
signature.asc
Description: Digital signature