Recapitulate the current state of Fedora Extras and some ideas to make it better

[Thorsten Leemhuis]

Hi all!

Now that the election is over and the new FESCo is formed I thought it
would be the right moment to recapitulate the current state of Fedora
Extras and lay down some ideas for the near and the long term future
with this mail. It's mainly a mail with a lot of different thoughts and
random ideas just thrown together (mostly unordered) without going to
much into the details and backgrounds. It's no real ToDo-List, but I
hope we (all Extras contributors and FESCo members) can take it (after
an discussion on this list) as a starting point to create a ToDo-List
with priority's what should be realized soon and what can be worked on
later (or ignored completely).

Note: It covers all the things that came to my mind, but I'm probably
forgetting a lot of stuff. If I'm forgetting something that's important
in your opinion just reply to this mail and share your thoughts with the
rest of us. Thanks in advance!

Note2: Some ideas are not mine and stolen from Schedules in the Wiki,
ToDo-List, Mails, Discussions, "Mission Statements" and other places.

== So, where do we stand ? ==

 Well, Extras works IMHO quite well. But not perfect afaics:

 * Packages

  *  We have a lot of packages in it and nearly every day one (or even
more) new comes aboard.

  * Most users seem to be satisfied with the package quality (I at least
didn't hear any major criticism).

  * Most packages get Reviews in time, but there are still a lot of
packages that got stuck in the QA queue for some time (or forever).

  * We have a standard for kmods in Extras, but all kmods are stuck in
the QA queue

  * new contributors can get it with one package. But most interesting
stuff is already packaged. We need other ways for new contributors to
enter and help on Fedora Extras.

  * Why isn't the Fedora Directory Server still not in Extras?

 * FESCo

  * The old FESCo didn't work to well. A lot of members weren't very
active. A lot of stuff was still discussed, but a lot of things didn't
get done. Some things were discussed and agreed on, but not documented
in the wiki.

  * How FESCo works isn't much documented

  * Discussions within FESCo and with the community are working often in
acceptable ways on the lists and on IRC most of the time, but often
nothing happens after the discussion is over and things remain unclear
and undecided.

 * Co-Maintainership

  * This is IMO one of the biggest areas we should work on soon

  * each package should IMHO have at least two maintainers (one of them
should be the "primary maintainer", who has the last word if there are
disagreements how to do things)

 * MIA/AWOL

  * in the works already

  * we need way to detect if maintainers are still around (periodic ping?)

 * SIGS

  * Have a working PPC and x86_64 SIG that help fixing stuff for that
arch in case a packager needs help

  * The games SIG is really doing well; hopefully the SIGs for perl,
mono, python become as effective

 * Quality

  * get a review SIG together that makes sure that each commit on
fedora-commits-list is *roughly* checked for bogus changes (at least I
do some bogus things now and then and I'd be glad if someone would tell me)

  * set up scripts that check existing Spec-Files and packages
automatically for bogus things and new rules/behaviors or common
problems (empty debuginfo, hardcoded rpath, ...)

  * proper Rebuild policy for new releases (or automated rebuilds?) --
or we want to discuss this each time a new release comes up and decide
on a case-by-case basis? Or simply rebuild all of Extras each time all
of Core is rebuild?

  * Do we want to rebuild noarch packages now and then, too? We IMHO at
least should make sure now and then that they still build.

  * can we stick to the "rolling release" scheme when anaconda will
start supporting external repos during install (the rolling release
scheme might break installs (not sure, but I think that is possible))?
And/or do we need Releases of Fedora Extras? E.g. ISOs of FE6 and a
stable repo on the servers and all new version go to a "updates"
directory (similar to core)?

  * a proper orphans policy -- when to remove orphans from the devel branch?

  * automatic QA checks for build packages before pushing

 * MISC

  * we need a Update Policy/Guideline -- a lot of people update packages
to the latest and greatest version in all supported Releases (and even
in Releases that are in maintain mode) at the same time really a good
idea? IMHO, especially as Extras has no updates-testing

  * When to EOL Fedora Extras -- is FE3 sill well maintained and is it
checked by the security team -- if not call it officially EOL now

  * we shouldn't  maintain two orphan lists (e.g. one in the wiki and
one in owners.list)

  * we should have someone that fills the Fedora Weekly reports

  * Better web interface -- "yum search" is really slow and people on
Windows or using other distributions should be able to search for
packages and their contents, too

  * we need to make the x86_64 more multilib aware (i386 packages in the
x86_64 repo)

  * Now that the first election is finished make everything ready for
future elections

  * Send email to pkg owners whenever someone else edits/builds their pkg

  * Sponsors should be able to "subscribe" to the people they sponsored
-- e.g. they should get additional mails when people they sponsored
commit something to cvs, requested a build ...

  * we need a defined and documented policy to get definite answers for
open legal question

  * fedora-devel-list, fedora-extras-list, fedora-maintainers -- these
multiple lists get confusing, some things that are discussed on
fedora-maintainers-list would be better suited for fedora-extras-list
AFICS;

  * the broken deps reports are really nice, but maybe we should merge
them into one per push (currently it's one per dist)

  * the "Broken upgrade paths" mail is also really nice, but it should
also mail the responsible maintainers directly (if it doesn't do
already) and have (a additional?) list sorted by maintainer (looking out
for the names of all your package is probably not fun if you maintain a
lot of packages)?

  * both "broken deps" and the "broken upgrade paths" mails should have
a list how long something is broken already (that way other can notice
"He that isn't fixed after know for 14 days -- I'll send out my ninjas
to get the maintainer fix that shit"

  * Long-Term Fedora Extras contributors should get a small reward now
and then: A Pen, Sticker, T-Shirt, LWN subscription, ...

  * Incompatible package upgrade policy (aka .so name changes)

  * Lower some of the hurdles to contribute to Extras

  * is it time to clarify/simplify the Fedora Packaging guidelines again
to make them easier?

  * Scratch build target?

  * updates-testing repo for Extras?

  * better documentation in the wiki ("How does FESCo work" and Extras
in general)

  * close the gap between Core and Extras as far as possible

  * We IMHO need more fine graded permissions, e.g. ACLs in the CVS,
restricted access to queue builds in the buildsys. This would make is
possible to grant  new contributors or even upstream maintainers access
to commit updates to CVS, but no access to the buildsys; a real Fedora
Maintainer then could check the commits queue the new version for building

  * The wiki was a great place for informations in the beginning of
Fedora Extras and still offers a lot of informations, but a lot of
things are not probably documented. I might be time for a big cleanup.

==

As always: Just my 2 cent.

CU
thl