Re: plans for discover transition (was: plans for d-i string freeze)
Am Son, den 07.12.2003 schrieb Petter Reinholdtsen um 19:45:
> [Gaudenz Steinlin] wrote:
> > There apparently was some discussion between branden robinson and me
> > which did not get through to the list or at least the list archive
> > due to the break in. Branden proposed the following transition:
>
> Hm, wish I had found this email earlier today. Then I would have
> hijacked discover 1.
>
> > Well, here's what I'd personally like: :)
> >
> > 1) Get a good feedback cycle going between Progeny and debian-boot
> > regarding discover2's suitability for debian-installer. The goal
> > here is "feature-complete", not "bug-free".
>
> Agreed. Of course, it have to work in the common case, meaning it
> must be able to detect at least something. :)
> We can try to detect everything in the next release. :)
>
> > 2) Hand off maintenance off Discover 1.x to the d-i team. You guys are
> > already the de facto maintainers of Discover 1.x and everyone who
> > reads the changelogs knows that.
>
> Gaudenz, do you want to take it?
David Nusinow was interested in it. If he still wants to take it I'm
fine with that. I'm not particularly interested in maintaining a package
that will be obsoleted soon, but if nobody is interested in it I will
take it.
>
> > 3) Rename the current discover source package to discover-old or
> > discover1; drop the libdiscover-dev package from it; rename the
> > discover package to discover-old or discover1, and have it
> > Conflict: discover.
>
> I prefere discover1 over discover-old.
me too.
>
> Looking at the control file for discover 1, I see the following
> packages:
>
> discover (rename to discover1, provides discover, conflict
> with discover?)
> libdiscover1 (keep)
> libdiscover-dev (rename to libdiscover1-dev, provides libdiscover-dev,
> conflict with libdiscover-dev?)
> libdiscover1-pic (keep)
> discover-udeb (rename to discover1-udeb, provides discover-udeb, no
> need for conflict with discover-udeb, as anna
> ignore conflicts info)
>
> I added a suggested transition plan. This way we would control which
> discover version we use in the package lists in the build/ directory.
> Does this agree with what you had in mind?
>
> > 4) Thanks to 1), we will upload discover 2.0 to Debian unstable.
>
> Sounds good to me.
Thinking a bit more about it. I ask myself if it would be better to
upload the new discover as discover2 and to keep discover as the name
for discover 1.5 at the moment.
The advantage of this would be that current users of discover would not
notice the transition while we are improving the packaging of discover2.
(I expect the first packages to contain some bugs, thats life :-( )
What do you think of it? Do you have experience with similar
transitions?
>
> > Following to discussions I had with pere, we would like to release
> > d-i with discover2 and drop discover1 before release. During this
> > transition both versions of discover should be available (no hard
> > transition on which everything breaks).
>
> I want a soft transition, with the option for each builder of d-i
> floppies to decide which version to use. When version 2 is found to
> be working properly, we can drop verison 1.
>
> > IMO if we want to release sarge with discover2 for d-i we have to
> > release beta2 with discover2 (after that it's too late for this
> > change!)
>
> I agree with Joey, we should try to have everything ready just after
> beta2 is released. The first task to finish is the discover 1
> takeover, fixing the build problems and other bugs. Then, do a new
> upload with new package names just after beta 2 is released.
If we are going to rename the current discover to discover1 I suggest to
do it ASAP but ship beta2 with discover1. This way we would not have to
wait with an upload of discover2 until after the release of beta2.
>
gaudenz
> > I'm not sure if we should wait on progeny providing them any longer
> > as we have been waiting for months now. OTOH progeny has made
> > available their subversion archive recently and it seems that they
> > are working on it.
>
> We should work independenly of progeny, but keep them informed about
> the progress. If Progeny suddenly start to assist us in the remaining
> tasks, we should reconsider this.
>
> > This way we are not constrained by the work of progeny but are also
> > not hijacking their package too much.
> >
> > What do you think about this?
>
> Good plan. Just execute it. :)
>
Reply to: