[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Follow-up on Extended Life Cycle



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]