fai bugs against policy - lets get this fixed NOW...

[Henning Sprang]

On 7/10/06, Thomas Lange <lange at informatik.uni-koeln.de> wrote:
> >>>>> On Mon, 10 Jul 2006 03:03:55 +0200, Holger Levsen <debian at layer-acht.org> said:
>
>     > are more than three years known. Thomas, I would really really really be
>     > happy if you fix these simply bugs _before_ the developer
>     > weekend.
> If anyone else think I should fix this _now_, please reply to the bug
> in the BTS or to this mailing list, and tell me your
> oppinion. Currently I only see holger that likes to have this bug
> fixed now and it will help me to decide when to fix this. My plan is
> to fix those bugs at the fai developers meeting in two weeks, but I
> more people like to have it now, I'll do it before.

I have no time to look into each single bug and write a comment to each one.

My general opinion is:
Only things that are likely to change before etch release,  so it
isn't clear now what the "correct" solution must be, and a change
requires a lot of work, should be deferred until the etch fhs version,
or whatever alse needs to be settled, is decided.

Things for which the rules in Debian are set for etch should really be
fixed as soon as possible - if there's a final decision in Debian for
which FHS version to go, then the bug should be handled.
If that decision isn't made yet in Debian, than still we should fix
things that don't change between the different possible FHS versions,
are very long time known, or require not a lot work to change.

>     > am completly unhappy to work on fai with this wrong pathes which have been
>     > there for ages (and two of them only requiere changes of the default
>     > configuration values!! (and the others also only requiere find and replace
>     > skills))
> Even if the bugs and their fixes seems to be very easy, I'm like to do
> theis change very carefully. IMO a lot of people will complain if
> their / (root) partition will be filled up because the nfsroot will
> move to /srv and they only have a small / partition.

That's why we decided that such major changes require the FAI version
to be 3.0. We have a major API/behavior change, and therefore we'll
have a higher Major version number.
That's also when we start to make FAI for etch, not for sarge anymore,
so nobody should use the newer FAI versions in production sarge
systems without even testing.
Just make that clear in the next release announcement.

> I like to
> implement a small test routine, and print a warning message for this.

Nobody should/can use FAI 3.X with sarge anyway. But we can keep a
small helping hint for long time users. It shouldn't be forgotten
though, to remove that with version 4.X later - because if you make
such tests for each change that breaks API between major versions
sou'll end up with a lot of cruft after a while...

>
>     > If you'd fix them before the developer weekend, we could use the weekend to
>     > test the changes and spend energy on useful stuff.
> Shouldn't we test the changes before an upload? Or do you mean "fix
> those bugs, but do not upload yet"?

Just fix them in svn and write a "please test" mail... On the other
hand, the "testing" repository is for testing in the end. so uploading
is also possible, weven if only some

Henning