Re: woody, boot-floppies, and debian-installer projected readiness
Adam Di Carlo wrote:
>
> [I'm re-sending this due to the subject line damage -- this is a very
> important issue.]
>
> Talking to the release manager, Anthony Towns, in IRC, I learned it is
> his current plan to freeze woody early in January 2001.
>
> I think this is a laudable goal, but unfortunately I think that means
> we need to retain the boot-floppies for woody.
>
> I just don't see how we could have a working and functional
> debian-installer in 12 weeks. 24 to 36 weeks seems more like it (even
> being somewhat optimistic).
>
I think one of the problems for the potato floppies as far as adding new
features was the extended time we were either preparing for a feature
freese or actually in the freese. It must have been over 6 months.
12 weeks may be optimistic, but if its going to be frozen for 6 months,
then we could have a new installer in that timeframe, of course planning
development schedules based on anticipating long freese time is probably
foolhardy.
Joey recently mentioned a 2 month plan to get something basic working,
so i dont think we should give up yet.
> This is seriously bad news for me personally because I was hoping that
> we could wash our hands of the boot-floppies -- and that I in
> particular could wash my hands of bf maintenance and move on to more
> work on the SGML/XML toolchain and Debian documentation.
>
> However, this seems increasingly unlikely.
>
> What does this mean? It means I'm going to branch in CVS for potato
> maintenance in early November so that we can go into woody freeze with
> working boot-floppies. I know we need a new busybox and I would
> rather get that in sooner rather than later (but for Woody only, not
> Potato). Erik, I wouldn't mind your opinion on whether we can use
> your busybox pkg or instead should just bite the bullet and update
> CVS.
>
> There are other serious issues needing to be worked out, such as
> better RAID integration, Reiserfs, lilo vs grub, and possibly more
> automation.
>
If we are going to keep maintaining the existing potato-installer i dont
think it makes sense to spend a lot of time implementing new features
for it, more just keep its existing functionality working.
It does come down to manpower though, if people want to work on the old
installer that will most likely be replaced then thats fine, but they
should be aware of the longer term plan to replace it.
I guess its hard for newcomes to work on the new installer because its
really just an idea, with some of basic tools it will depend on still
not available.
Glenn
Reply to: