Follow-up on Extended Life Cycle

[Jeroen van Meeuwen]

Hi,

First of all, my apologies for the long email.

That said, my apologies to Dennis Gilmore for stealing his action item, too.

 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?

It is also suggested that the current proposal does not add sufficient 
reason -in comparison to a previous discussion on a proposal apparently 
perceived to be quite similar- to revisit this topic.

The meeting minutes being referred to are:

* https://fedoraproject.org/wiki/Meeting:Board_meeting_2008-11-11
* https://fedoraproject.org/wiki/Meeting:Board_meeting_2009-07-16

Let's re-iterate the concerns from 2008-11-11 first, since they are 
being referred to as still current in yesterday's meeting;

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

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

Given the statistics in Bodhi for current releases, one could (arguably) 
say that the approximate amount of security updates in 6 months for 1 
given release is somewhere around ~250 maybe -if everything released for 
Fedora current releases has been properly tagged.

For the bug tracking question, it seems obvious to me BZ would be used 
-if technically feasible.

- It is unclear who the technical leader and implementer will be.

That'd be me.

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

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

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

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

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

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.

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

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

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

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

Thank you,

Looking forward to continue the conversation in constructive ways,

Kind regards,

Jeroen van Meeuwen
-kanarip