Re: [Etherboot-developers] latest greatest eboot with IDE boot

[Eric W B. <ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >And could we distinguish between what makes a release canidate and what
> >makes a development release?
> 
> For me a RC is just a snapshot and doesn't have any associated tag in
> CVS. If bugs are found in it, good, we fix them and make another RC. A
> release (development or production) is entered into the Sourceforge
> release page and gets distributed to mirrors. I make announcements to
> Freshmeat and a couple of other places. Marty makes an rom-o-matic
> version. If bugs are found, they go into the patches page and are held
> over for the next release. So a release is a big step.  Hopefully it's
> just the final RC with the version number changed.
> 
> >You delayed initially because there wasn't a multicast client, but I
> >have fixed that and a couple of other things.  I am pretty certain
> >etherboot is over the major hump and headed for another stable
> >release.
> 
> Ok, before we do that I'd like to do regression testing and also to
> check that the new features work. I guess though that for a development
> release the audience is different. Or should be. You will get the odd
> newbie who will ask how come it says gcc not found.
> 
> I'd like to make the release 5.1.2 and then when all the legacy
> implications are understood, release it as 5.2.0.

Sounds like a good plan.

Before 5.2.0 the current big issues still open are:
1) Which nics work with relocation.
2) Which nics work with multicast, support.
3) What to do with the old CAN_BOOT_DISK code.
4) Update the documentation.
5) Automatic generation of the NIC file.

I want to emphasise that I don't think the current code base is unstable.
I am shipping 5.1.x to customers, to get the new functionality.  Rather
there are still some cases where the new functionality does not work
with the old drivers, and needs integration testing and fixing.

To add multicast support it should be about a days work to go through
the Linux kernel find the bit in the driver that needs to be set to accept
all multicast packets, and update all of the drivers.

To be certain of relocation support is harder.  A pure pio driver is fine.
And in many cases a code review will catch it, but we do need someone to 
actually test the driver.  5.2.x looses functionality if all of the drivers
are not relocatable so this is something I would like to aim at having
looked at before 5.2.0 is released.  Which means it would probably be
good to have an development release or at least an rc where people
can test this stuff out and see how well 5.1.x is comming.

Eric