Follow-up on Extended Life Cycle

[Paul W. Frields]

On Fri, Jul 17, 2009 at 12:29:51PM +0200, 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.

I haven't seen any responses from other Board members yet, so I'll
just leap into the fray and suffer the first slings and arrows. ;-)

> 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?
[...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.

Dennis may be able to shed some light here.

> - 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;

One reason for these questions is that some specifics are missing in
the feature page that was originally proposed.  Thanks for clarifying
some of those in this email, but I think there may be more details
required for both bodies if they want to make an informed decision.  I
would like to see all the clarifications recorded in the wiki page for
future reference.

[...snip...]
> - 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.

The proposal cites the audience for this proposal as including
desktops for business users.  Therefore it would make sense that the
covered package set must not be limited to something like the critical
path packages, because desktop use involves more than that.  For
example, the Firefox package would undoubtedly be used by these
consumers.

As for the severity issues, I looked at classifications as listed on
http://www.redhat.com/security/updates/classification/ and found my
personal level of comfort, were I an owner of these desktops, to be
coverage for all issues of moderate or higher severity (i.e.,
moderate, important, or critical impact).

[...snip...]
> - 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 would encourage you and Dennis to work together to develop this
data, because it would give us a better idea of the size of the
audience involved, both in absolute and relative terms.

> - 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.

In other words, you would rather have this be opt-out than opt-in.

> Returning to the questions/doubts/concerns in the Board's last meeting;
>
> - What is the Board saying "yes" to?
>
> You would be saying "yes" to an initiative to increase the use and  
> adoption of the Fedora Linux distribution in corporate desktop  
> environments by facilitating the elimination of one of the major  
> downsides of the Fedora Linux distribution, as perceived from a corporate 
> perspective, possibly resulting in greater corporate participation in the 
> Fedora Project -inherently including development, by allowing said 
> corporate environments a little more breathing time to opt-in on desktop 
> system upgrades by means of providing security updates for 6 months after 
> a release's -what we now call- EOL date.
>
> Whether that "yes" includes a full go-ahead or just the willingness to  
> let it develop within the Fedora Project really is up to you.

So you seem to be implying here that by giving these environments more
"breathing time" in which they are not required to upgrade to continue
receiving updates, the resources saved would be diverted to
participation in Fedora.  Is that something that you would want to
measure as part of this initiative?  In other words, is there a
benefit returned to Fedora for this proposal that involves higher
participation?

> - Trademark usage?
>
> I'm not sure what this question entails, but Extended Life Cycle is  
> either going to use the Fedora trademark and the Fedora Infrastructure or 
> it's not going to happen.

If this is opt-out and not opt-in, I don't see how it could be otherwise.

> - Fedora infrastructure?
>
> Again I'm unsure what the question entails exactly, but I think I can  
> answer the same as above.
>
> Also, on this subject, the amount of all updates released for Fedora 10  
> (approx. 6 months old) currently is:
>
> $ du -sh /data/os/archive/fedora/updates/10/
> 113G	/data/os/archive/fedora/updates/10/
>
> and the size for currently available updates for Fedora 10 is:
>
> $ du -sh /data/os/distr/fedora/updates/10/
> 75G	/data/os/distr/fedora/updates/10/
>
> Since this includes bugfix and enhancement updates, and Bodhi shows the  
> following ratio of sec. vs. bug. vs. enh. vs. all for Fedora 10:
>
> https://admin.fedoraproject.org/updates/metrics/?release=F10
>
> I don't really think that we require extremely large chunks of storage.

I think the storage involved on Koji is considerably higher than these
numbers, but I'd yield to the toolies for more information.

> - What is the board responsible for deciding?
>
> You are to decide whether this can continue to develop given the same  
> time schedule as a Feature (regardless of whether this is actually a  
> feature or not), meaning that we should be good to go by Feature Freeze.
>
> - What is FESCo responsible for deciding?
>
> They are the engineering steering committee and so maybe they are  
> responsible for deciding whatever has to do with the engineering side of  
> things;
>
> . minimal security classification level to provide security updates
> for?

Earlier you said you wanted the Board's input on this too, and I think
the Board should have input into how consumer and contributor
expectations are set for something carrying the trademark.

> . policies, procedures and technicalities?
>     - CVS, CVS ACLs icw. PackageDB, koji, mash, bodhi, bugzilla,  
> mirrormanager, ...
> . minimal responsiveness on security issues published,
> . which security issue trackers to track minimally,
> . what happens/should happen if we can't backport a security fix
>   - what kind of version bumps would we be allowed to do?
>   - how to handle the dependency chain for said version bump?

These seem reasonable but I think, given the obviously controversial
nature of theissue, the Board should be able to examine a proposal
with these details fleshed out.

> - 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".

How do you propose *not* guessing about this potential increase?

How do the suggestions I make above for coverage affect the viability
of your proposal?  Will the group of contributors involved handle
moderate and higher impact security issues for all packages that are
part of a potentially pretty sizable set, without requiring additional
resources from package maintainers who are not involved?

I don't think Fedora wants to be the kind of community project that
does not re-evaluate its position over the course of time.  It has
been something like 4 years since the Fedora Legacy project ended, and
if you have a sizable labor pool you can eliminate one of the main
reasons that happened.  However, I think all the people in Fedora who
are not involved want to have a concrete layout for what will happen
to their packages after the end of the primary maintenance period, so
the Board is only asking for what needs to be provided anyway --
whether it's provided straight to the Board or to FESCo.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug