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@xxxxxxxxxx
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
