Re: HEADS-UP: starting to commit linuxolator (SoC 2006) changes...

Quoting Suleiman Souhlal <ssouhlal_at_FreeBSD.org> (Tue, 15 Aug 2006 14:53:56 +0200):

I'm doing post-commit checks now (everything is commited and I'm doing
a kernel build now)...

> Alexander Leidinger wrote:
> 
> > I already started... and I don't want to commit some parts (the linker
> > stuff which allows to use the module on amd64).
>  >
> > It is also not used by default, as long as we have 2.4.2 for the linux
> > version, no new functions will be used by glibc. So there is no change
> > in behavior after the commits. I tested with acroread (which has issues
> > when run with a 2.6.16 compat.linux.osrelease version, where the new
> > functions are used by glibc).
>  >
> > So this gives us:
> >  - coverity reports for the code *before the end of the SoC*
> 
> Why the rush? I'm sure Roman will be around even when the SoC is over.

Yes, but first he will take a vacation, and then he will not be
available as much as he is now. And maybe Coverity will detect a bug
which we search currently but can't find (don't know how likely this
is, but it is at least possible).

> Also, I'm not asking you to wait a month, just a couple of days until 
> more people have had a chance to look at the changes.

I thought about this before deciding to commit it. Most of the code was
available in P4. Those people with real interest already had a chance
to look at it, or they didn't had time to do so. If they didn't had
time to have a look at it, who knows if they have time to do it now?
There's always someone who says "oh... if you waited 2 days longer...".

That's not the only reason. Tomorrow my holiday is over and I have to
catch up at work. Today I have plenty of time to commit urgent issues
(e.g., tinderbox breakage). And at the upcomming WE I may not have
enough time to do what I do today.

Additionally, the work is a little bit stalled currently, we need more
testers of the new code. There are a lot of people out there which want
to test, but don't know how to patch or fear to do something wrong when
they patch. With the approach I've taken, they just need to run a
sysctl (compat.linux.osrelease=2.6.16) and they can test. All which
don't want to test just don't need to care about it.

> It's a bit unreasonable to say "here's a patch, please look at it" and 
> commit it less than a day later.

Yes, it was a little bit fast...

> >  - no change in behavior in the default case, since the new calls
> >    aren't used by glibs as long as... see following entry
> >  - easy testing possibility (sysctl compat.linux.osrelease=2.6.16,
> >    defaults to 2.4.2)
> >  - more eyes on the code
> 
> Those are not valid reasons to commit unreviewed and potentially wrong
> changes.

Uhm... how many percent of code committed to current is reviewed before
it is commited? How many percent of the code I committed is not
reviewed and how much is this related to the amount of unreviewed code
committed in a busy week?

I'm running a kernel with this changes here and since I didn't enabled
the new code with the sysctl, I don't see any difference in the
behavior of the linuxolator. The potentially wrong code isn't active.
It's like loading the linprocfs module but not using it.

Bye,
Alexander.

-- 
   Calvin: Can you make a living playing silly games?  His Dad: Actually, you
can be among the most overpaid people on the planet.
http://www.Leidinger.net  Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild _at_ FreeBSD.org  : PGP ID = 72077137