Release farkage potential

Does anyone have a clue as to what upstream are likely to be
doing w.r.t the 
sub-release in a release situation ? As in, will there be a
5.0.1 and 5.1.0  ?

-- 
Karanbir Singh : http://www.karan.org/ :
2522219icq
_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 9/5/07, Karanbir Singh <mail-listskaran.org> wrote:
>
> Does anyone have a clue as to what upstream are likely
to be doing w.r.t the
> sub-release in a release situation ? As in, will there
be a 5.0.1 and 5.1.0  ?
>

As far as I understand it.. yes there will be a 5.0.1 and a
5.1.0.

The 5.0.1 release should only be security errata and will be
built
against the 5.0.0 glibc and libraries.

The 5.1.0 release will be product upgrades and security
errata. New
security errata for the 5.1.x tree will be built against the
5.1.0
updated glibc/kernel/etc. The API's shouldnt change but I am
guessing
there might be some ABI issues.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a
good deed
in a naughty world. = Shakespeare. "The Merchant of
Venice"
_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Stephen John Smoogen wrote:
> As far as I understand it.. yes there will be a 5.0.1
and a 5.1.0.

not clear if you meant that there are going to be 5.0.1
iso's as well ?

> The 5.0.1 release should only be security errata and
will be built
> against the 5.0.0 glibc and libraries.

Thats going to be quite interesting, since it might imply a
completely new 
release. Lets see how it all pans out - if there are any
real plans or redhat 
endorsed docs that someone can point us at, that would be
great.

btw, does someone want to have a go at drafting up a policy
we could use on the 
mirror.centos.org network and on external mirrors so as to
minimise drivespace 
usage and still be able to offer the same user experience as
upstream ? I know 
that between Johnny, Lance and I we did do some prep work
for this - and a lot 
of options exist. But it would be good to get some fresh
ideas on board and see 
if we can work something out that works for most people.


-- 
Karanbir Singh : http://www.karan.org/ :
2522219icq
_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 9/5/07, Karanbir Singh <mail-listskaran.org> wrote:
> Stephen John Smoogen wrote:
> > As far as I understand it.. yes there will be a
5.0.1 and a 5.1.0.
>
> not clear if you meant that there are going to be 5.0.1
iso's as well ?
>

I do not know. I was under the impression that there would
not be new
isos for 5.0.1 but that could be the ASS U ME of the sales
person 3-6
months ago.

> > The 5.0.1 release should only be security errata
and will be built
> > against the 5.0.0 glibc and libraries.
>
> Thats going to be quite interesting, since it might
imply a completely new
> release. Lets see how it all pans out - if there are
any real plans or redhat
> endorsed docs that someone can point us at, that would
be great.
>

I have nothing but what I got from asking questions of the
TAM et al a
while back. I do not know if all of 5.1 would be rebuilt or
just the
parts that get technology updates.

> btw, does someone want to have a go at drafting up a
policy we could use on the
> mirror.centos.org network and on external mirrors so as
to minimise drivespace
> usage and still be able to offer the same user
experience as upstream ? I know
> that between Johnny, Lance and I we did do some prep
work for this - and a lot
> of options exist. But it would be good to get some
fresh ideas on board and see
> if we can work something out that works for most
people.
>

I was wondering if we should see about stealing the new Dell
built one
for Fedora?


-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a
good deed
in a naughty world. = Shakespeare. "The Merchant of
Venice"
_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 9/5/07, Karanbir Singh <mail-listskaran.org> wrote:
> Stephen John Smoogen wrote:
> > I was wondering if we should see about stealing
the new Dell built one
> > for Fedora?
>
> I dont know what that is 
>

Matt Domsch wrote a whole set of infrastructure tools for
Fedora to
push out updates to mirrors. I think it is what causes the
fedora-enchilada to show up on various mirrors these days.

http://fedoraproject.org/wiki/Infrastructure/Mirroring


I can see the one downside to the system is:

Fedora Account System

    * You must have an account in the Fedora Account System.
(More
info also at Infrastructure/AccountSystem.) You are not
required to
sign the Contributors License Agreement to merely mirror
Fedora
content, but you must do so if you wish to contribute to
other aspects
of Fedora.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a
good deed
in a naughty world. = Shakespeare. "The Merchant of
Venice"
_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Jeroen van Meeuwen wrote:
> Karanbir Singh wrote:
>> we dont need anything of this nature, we have
something in place that 
>> seems to be working mostly. What I meant by mirror
management is how the 
>> stuff looks when its on the mirror
>> pushing out each tree, as it is, for upto 3
sub-release deep is just plain 
>> stupid. So if anyone has ideas on how we can do
this in a sane manner, 
>> please do speak up 
>
> mirrormanager though adds a number of features like
using preferred 
> netblocks, country mirrors, etc. In addition someone
could add his local 
> mirror for private use which, for large corporations
may be useful.

Which still doesn't solve the space problem on mirrors. 

Ralph

_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Fri, 2007-09-07 at 00:36 +0100, Karanbir Singh wrote:
> Stephen John Smoogen wrote:
> > Matt Domsch wrote a whole set of infrastructure
tools for Fedora to
> > push out updates to mirrors. I think it is what
causes the
> > fedora-enchilada to show up on various mirrors
these days.
> > 
> > http://fedoraproject.org/wiki/Infrastructure/Mirroring

> > 
> 
> we dont need anything of this nature, we have something
in place that seems to 
> be working mostly. What I meant by mirror management is
how the stuff looks when 
> its on the mirror
> 
> pushing out each tree, as it is, for upto 3 sub-release
deep is just plain 
> stupid.

Don't pull any punches now.  

Seems it could get to more than 3 sub-releases, unless the
upstream
policy is to limit it to the last 3.  Witness 3.9 and 4.5.

>  So if anyone has ideas on how we can do this in a sane
manner, please do 
> speak up 

Well, how about backing up to the basic assumptions before
suggesting
solutions.  Just because the upstream with their much
greater (paid)
resources seem to be going to a M.N release scheme, is
CentOS
constrained to follow precisely in their footsteps?  What's
wrong with
keeping the current scheme of following the latest release
and
continuing to have M as a pointer to the latest M.N tree? 
If someone
REALLY needs the minor release[es] with associated updates,
they can go
to the upstream for support; however, I suspect that would
be a
relatively rare case.  If the demand is there down the road,
can always
re-evaluate the policy.

So, am I sane?

Phil


_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel