Re: plans for discover transition (was: plans for d-i string freeze)
[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?
> 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.
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.
> 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.
> 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: