Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras)

[Warren Togami]

Nicolas Mailhot wrote:
> IMHO :
> 
> 1. we should formally create an FE Legacy team. FEL would be composed of
> the Aurora/Centos/FCL/FE people that want to maintain old releases. Some
> poor sucker should be nominated to serve as initial fearless leader
> (surely of all the Aurora/Centos/FC3 users one is ready to take charge?)
> 
> 2. the handover from FE to FEL should be synchronized with the one from
> FC to FCL. It's the only sane solution WRT users, they have other things
> to do than track multiple overlapping Fedora schedules (also from a
> marketing POW its probably saner to advertise to users the move at FCn+1
> time, and let the FCn+1 -> FCn+2T2 be the grace period that was always
> intended)

FE to FEL has no realistic relation to the schedule of FC to FCL.

> 
> 3. we should let FEL define its own policies. Today we don't know the
> number of people interested in FEL and their level of involvement. It's
> useless to dictate rules to a team which is not assembled yet. People
> who want to do it should first go to 1. and create some form of entity
> 

I think it is entirely broken to "hand over" the entire Extras and 
expect some other volunteer to take care of it.  This will create a 
guaranteed failure situation for a community group because the set of 
packages is potentially infinite and the natural problem that security 
is difficult to maintain with only volunteers (even Debian struggles). 
It is a *fantasy* for maintainers to expect they hand over 
responsibility to some theoretical entity and expect it to actually work.

Instead I suggest key changes to existing Fedora projects to better 
facilitate communication and responsibility.  Included in this is having 
formal package update announcements for Extras exactly as we have in 
Core.  We must also create hard machine countable metrics for retiring 
an old volunteer abandoned distribution.  Finally (the most difficult 
problem) we must blend the differences between Core, Extras, and Legacy 
so people don't care what it is called, as long as *somebody* is 
maintaining the packages then it is OK.

These are lofty goals, but I believe we can achieve these ideas if we 
slowly change the project through a series of objectives.  Some examples:

1) Task: All new bug reports in Extras should go to a list
Timeframe: ASAP

This easy change already discussed in FESCO would increase the chances 
of new issues reported against Extras packages to be handled by somebody 
in a timely manner.  There currently isn't agreement whether we should 
have this mail go to the existing fedora-extras-list and further 
overload those subscribers, or create a new extras-bugs-list limited 
only to people interested enough to subscribe.  I am leaning towards the 
latter.

It is clear to me however that this is not a feasible long-term 
solution.  The amount of mail will never stop growing, and it will 
become more and more detrimental over time for any person to attempt to 
read everything.  I think that we should always keep subscribing to a 
bug list as an *option*, however we should move toward the next goal.

2) Task: All Packages in Core and Extras should officially have multiple 
owners in the database
Timeframe: Early FC6 cycle

This key change would be useful for both Core and Extras, because often 
packages would benefit from multiple eyes watching and owning new bug 
reports.  It should also have the ability to say "I maintain only FE4 
and newer." or "I maintain only FE3 of this package."  We can also have 
the ability to subscribe to "categories" of packages where clear 
sub-communities can be identified, like the existing Fedora Perl team.

The idea behind this objective is to compartmentalize the growing 
infeasible bulk of bug mail to the people best suited to deal with it.

3)  Task: Organize formal security status tracking of Fedora Extras 
similarly to how Core is tracked.
Timeframe: FC6 cycle
Who: ??? Yes, security is a hard problem for volunteers for many reasons...

I think the primary responsibility of the security people is to *track* 
security issues in some fashion in some database.  They cannot be 
expected to both track and fix all packages.  Not all package 
maintainers will abandon their older versions of packages, and they 
should have the first opportunity to fix stuff that they own if they are 
identified as vulnerable.  A tracking system would allow the community 
to quickly see what isn't fixed and somebody else can take care of it if 
the original maintainer isn't responding quickly or if the package is 
marked as abandoned.

One huge complication here is how we handle embargoed security issues. 
I have no clue how we would do this currently.

The database would allow *any* Fedora contributor to add stuff to the 
security tracking system, as anybody is really capable of doing this and 
they might as well help.  However the key to success here is for 
somebody to be responsible for it.  This is a difficult problem because 
of the differing motivations between volunteer contributors and 
commercial interests...

4) Task: Formal package update announcements for Extras
Timeframe: After security team is defined and running

These should first go into a database, and from that different media 
feeds can be generated on-demand.  Static web pages, RSS feeds, and 
e-mail are a couple examples.


=== WARNING: PURELY THEORETICAL STUFF BELOW ===

5) Task: Allow direct participation in Core from Fedora community
Timeframe: ???

This is only my personal idea at this point so don't get excited yet.  I 
have some ideas for differential requirements below, but these are only 
off the top of my head and of course we can discuss and improve it.  It 
will be a hard sell because we don't have the infrastructure (CVS, 
buildsystem, etc.) and security mechanisms in place to adequately do 
this yet.  This currently is not possible unless Core moves to an 
entirely different build and source tracking infrastructure than what is 
currently used today.

Don't hold your breath.  This wont happen anytime soon.  If you have 
improvements to contribute to core, especially rawhide, please continue 
to submit Bugzilla reports.  Even if this objective is achieved many 
changes may benefit from discussion and consensus building between 
multiple maintainers so Bugzilla reports would be useful even then too.

Keep in mind that this objective refers entirely to "rawhide" Fedora 
development and current Fedora releases.

Potential Requirements:
1. We may accept contributors who have proven themselves through many 
months of technical skill or leadership in Extras.  This barrier of 
entry is much higher than cvsextras sponsorship requirements.
2. We may accept upstream contributors of individual Core packages if 
they are willing to work with and not conflict with the desires of the 
Core package maintainer.
3. Membership here is on a per-package ACL basis.  Or in some cases 
maybe an entire package group, like perl*.
4. Membership here is ultimately a decision of the individual Core 
package owner, if they want to allow a Fedora community contributor to 
be co-owner of a Core package.


6) Legacy contribution goes directly into older Core
Timeframe: ???

The previous objective enables Legacy to directly contribute and build 
directly into Core, but on an ACL basis only for the releases that Red 
Hat engineering no longer supports.  Same idea as the current Legacy, 
except using similar infrastructure as Core itself.  It could be another 
instance of the Core/Extras buildsystem, or maybe the same, or maybe it 
doesn't matter.  We can figure out the specifics later as the project 
will look entirely different by this time.

Perhaps a database flag and e-mail announcements can clearly note 
somehow that the update came from fully community sources rather than 
Red Hat engineering.  The same could be true of the previous objective.

7) Possibly Abolish "Legacy" name

Maybe the "Legacy" name has a negative connotation.  Instead "Fedora 
Security" could be the organizational entity name, and it doesn't matter 
who did the actual work.  Leaders can emerge to be overseers of "Fedora 
Security" but anybody can do work.  The actual "name" of the project 
doesn't matter so much as what work is actually done, so the Legacy team 
themselves should decide if they really want this objective.

> 4. If in X months no one has stepped to 1. we should recognise the level
> of community support to create a FEL is not here yet, and announce
> loudly no one maintains FE3 anymore. Keep the repo for historical
> reasons but move it to a freezer so non one mistakenly use it on actual
> systems.

I support the idea of retirement if community interest in maintaining it 
is gone.  This is exactly how Legacy currently operates.

Warren Togami
wtogami at redhat.com