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

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

Nicolas Mailhot wrote:

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

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.


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

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

Warren Togami
wtogami redhat com

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