Stephan,

On Thu, 29 Sep 2005, Stephan Wiesand wrote:

> Hi Troy,
> 
> I think that's the right thing to do. 1.2.13 has proven rock solid here on 
> 32-bit, and amd64. In particular, it put an end to instabilities of our 
> dual Opterons running 64-bit SL we observed with 1.2.11.
> 
> Even the server packages meanwhile received a fair bit of testing here 
> (32-bit only, though, and these are filservers only, not db), and we 
> haven't observed any problems.
> 
> In my opinion there's also nothing that needs changing except removing 
> or changing the init info. One thing that could be done is to use the 
> rxdebug check in on_network, because rxdebug since 1.2.13 works on x86_64
> and probably on ia64 as well, although still I can't check that.
> 
> There's still the dispute over dynroot, though. But then, CERN seem to
> be rolling their own anyway (?) and noone else ever seriously complained 
> ;-)
> 
> Cheers,
>  	Stephan
> 
> PS I'm about to build 1.4.0rc5 packages for SL 4.1. Unless someone
>     beats me to it. They're going to release 1.4 soon, and we should
>     probably look at it.
> 
> PPS Are you planning to create a 3.0.6? I'd much appreciate it, but
>      I also figure it's becoming more tedious with every minor release...

That is a good question.  We have thought about this and we clearly have 
to scale back on what releases we do and not do.  There are 3 30x releases 
and 3 4x releases, Jarek does most of the work for the ia64 but that still 
leaves 4 releases for Troy and myself.  But we also have to do the 
Scientific Linux Fermi releases so that now makes 8 releases plus the 
small amount that we do for the 2 ia64 releases.  

So in the 305 and 41 releases Troy added a "bugfix" area in the yum.conf
file.  It is not enabled by default.  But the thought was that if we did
NOT make a full release we would rebuild all the new/updated rpms and put
them in this "bugfix" area that yum/apt could access.  This would enable
users who wanted to upgrade to the "equivalent" of the new update to do so
after enabling this area.  For users that just want to upgrade but do not
want to change yum.conf they could mirror the "errata" tree and move all
the rpms from the "bugfix" area to the "errata/SL/RPMS/" area .  The only
things that would be missing with this idea is that new kernel changes and
new installer changes would not be seen in the installer as the new kernel
and installer would only be in the "bugfix" area. Of course a user could
always make a "site" with the new/updated rpms in it and then they would
have the new kernel as the installer kernel.

So the proposal for 306 is to use this new idea.  Rebuild the new/updated 
rpms and put them in the "bugfix" area where users could have yum/apt 
access to them.  When 42 comes out make a full release out of that.

These could be switched, we just thought that 42 was younger and may need 
those kernel and installer changes more than 306.

Do note that there is some expectation that RHEL 5 will be released late 
2006.

Comments/suggestions please.
  
-Connie Sieh

> 
> 
> On Thu, 29 Sep 2005, Troy Dawson wrote:
> 
> > Howdy,
> > I want a second or third opinion on this.
> > Currently, there are 3 different openafs versions on the S.L. 3.0.x versions.
> > SL 301 - openafs-1.2.10
> > SL 302,3,4 - openafs-1.2.11
> > SL 305 - openafs-1.2.13
> >
> > I believe I said before, that with the next security kernel update, I'd like 
> > to move them all up to the same version.  If I didn't, I meant to.
> >
> > Does this sound like a good idea?  (I still think it does)
> >
> > If it does, I was planning on doing openafs-1.2.13-15.17.SL
> > This is the same openafs as was released in S.L. 3.0.5, but has the init 
> > script fixed to work properly with LSB.
> >
> > Any thoughts?
> >
> > Troy
> >
> >
> 
>