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
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
