Follow-up on Extended Life Cycle

[Dennis Gilmore]

On Friday 17 July 2009 05:29:51 am Jeroen van Meeuwen wrote:
> Hi,
>
> First of all, my apologies for the long email.
>
> That said, my apologies to Dennis Gilmore for stealing his action item,
> too.
Its ok. 

>  From yesterday's Board Meeting Minutes, it is suggested that the
> following questions need to be answered:
>
> - What is the Board saying "yes" to?
> - Trademark usage?
> - Fedora infrastructure?
> - What is the board responsible for deciding?
> - What is FESCo responsible for deciding?
> - Would ELC's request go against or detract from meeting Fedora's
> objectives?
Id also like to know how this fits in with Fedoras stated goals. i see that it 
benefits freedom,  but to me it conflicts with being first.  its hard to be the 
leader and innovate when you are supporting old releases.

<snip>
> - Infrastructure resources
>
> "A year or more out storage space will become a concern." - We're not a
> year yet, but this is a valid concern and I'm not in a position to
> address it.
>
> - How many builds are anticipated, how will they be distributed, where
> will bugs be tracked, how long is the trial period?
>
> In return to these questions, which to me seem rather random shots in
> the dark and do not seem like they are in any way related to a
> Board-level decision on whether this may or may not continue, as they
> are of a nature for which there are other teams and governance bodies
> that have been delegated the tasks and responsibilities concerning these
> questions, by the Board itself no less;
they are all aimed at working out what resources will be needed. can the board 
justifying others to dedicate the resources to this purpose.

> . How many builds does the Fedora Project anticipate for rawhide, Fedora
> 11, Fedora 10?
>
> . How many security issues do we anticipate in the 6 month period after
> Fedora 12 goes what we now call EOL?
>
> . How many security fixes do we release in a 6 month period of any given
> current Fedora release?
>
> The latter would be the primary indicator for the number of updates
> pushed out in a period of 6 months. How many builds that requires is
> probably a factor 1.X times as much.
how do we limit to security updates? many people may try and push new releases 
to all open releases.  we also will likely need the support of the security 
response team.  there is no reason to limit who can commit fixes,  if a primary 
maintainer wants to do the work they should be free to.  but when a maintainer 
doesn't want to then someone else needs to step up and do it.   but that 
brings up how do people not interested in supporting there packages for 6 
months more let people know?  its not something that's very clear for EPEL, 
which is a separate thing.  It will be much muddier for this.   We will need 
some way to do it. 

>
> - Concerns about granting Fedora resources and space to a project that
> will not use the Fedora brand.
>
> Since this proposal *requires* implementation through the Fedora Project
> proper, this is no longer a valid concern.
>
Requiring implementation through fedora then brings up the question. how do 
you propose that these packages get out?  
Who will sign them? what key? 
who will do the releng? 
will this be a new repo?  how will that get added to the system? 
what is releng's take on this,  if we sign with the release key then we need 
to also have releng push the packages.  what is there take on the impact of 
the time it will take to do pushes  since we would have 3 or 4 releases to 
push at once instead of 2 or 3.   

> - Concerns around the haphazardness of package updates and what
> determines when updates are issued
>
> Like said before, the only thing we'll release for EOS releases is
> security updates. Which security classification(s) that includes and/or
> excludes needs to be determined, and I hope the Board (or FESCo) has an
> opinion on what should be the minimal classification for the Fedora
> Project to feel comfortable with allowing systems to run with just those
> and lower-classified security issues fixed.
Security updates for what?  all packages?  or just some subset.  tracking each 
and every one would take 1-2 full time people at a guess.  I think you will 
find people will expect security updates for all packages.  it needs to be 
catered for.
 
> - If the core issue being raised by this proposal is extending the
> length of time Fedora releases are support, that issue should be
> explored separately
>
> This applies to the previous proposal specifically, but is still valid
> nonetheless. If the Board thinks, rather then allowing a separate SIG to
> extend the life cycle, the Project is better served with extending the
> life cycle per default, then so be it.

I think that If we are going to have some extended support period by default 
that extends the life-cycle of fedora.  How that is implemented is not really 
a board issue as much as saying Fedora releases will now be 19 months or 25 
months or whatever it would end up being.  how it would be implemented is up 
to FESCo.

> - The board is very unclear if there is real user demand or actual use
> that warrants providing resources for this effort.
>
> I too would love to see the number of hits against MirrorManager for
> releases that are currently EOL. I'm willing to collect the raw data if
> necessary (but I have no access and nor should I have), all the way to
> generating a nice management-type of graph with lines decreasing and
> decreasing over time.

I know there are still hits for FC-1 but hits to update the metadata don't 
mean that people would be applying the updates.  sadly some people never 
update there machines and run what they installed until they replace the 
hardware.  

>
> - Encourages the supporters of this proposal to demonstrate the
> technical viability of this proposal by setting up a self-hosted
> instance outside of Fedora and engaging a group of interested people to
> show it can work and generates enough interest and demand. This is how
> things usually start in Fedora. For example, Fedora Extras when it began.
>
> The spirit of this proposal is to do it through the Fedora Project
> properly. In my perception, and given the past experiences with
> proposals and initiatives similar to Extended Life Cycle, a requirement
> for the initiative to succeed is to not require any consumer edge
> changes to the system (configuration) in order to be able to
> continuously receive security updates to the extend of 6 months after EOS.

<snip>



> - Would ELC's request go against or detract from meeting Fedora's
> objectives?
>
> If you take into account the potentially increased participation of
> corporate consumers in the Fedora Project -which we can not simply
> guess-, then in the light of the Fedora Project objectives it becomes
> the traditional "taking a step backwards in order to move forward".

Ill also ask will the effort targeted towards extending fedora's life-cycle 
disappear when the next version of RHEL is released?  is this just because 
RHEL 5 is getting old? 


Personally I think the costs to do this are quite high,  I think that they are 
much higher than you perceive.  Id like to know if the benefits will outweigh 
those costs.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20090723/a661c10e/attachment.sig>