Important Announcement: Please read https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html and https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00009.html for information.

Development/Schedule/IdeasContainer

From FedoraProject

< Development | Schedule

Jump to: navigation, search

1 Fedora Development Ideas Container

Fedora Development Ideas Container

There are often great ideas posted on the lists and in IRC how to improve Fedora. But often they are forgotten because nobody really works on implementing those. We collect them here so they don't get forgotten:

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.

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 and what we need it for isn't much documented;

How FESCo interacts with the packaging comitee 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. We should make sure that all things on the schedule have a owner; we should make sure that things that might be nice don't get forgotten if no one has time to work on them yet.

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); Callum Lerwick: This seems like a good purpose for SIGs. The SIG can act as a collective maintainer/co-maintainer for packages in their areas of interest.

the CC list remains broken; see https://bugzilla.redhat.com/198109

MIA/AWOL

in the works already

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

EOL

we probably should EOL FE3 -- it seems the security team doesn't track it

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)

use rpmlint and 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, ...); c4chris: I'd like rpmlint run each time a package is built and the output diffed to a reference rpmlint output for that package. Differences would fail the build. [even more: I'd like a similar test procedure to the Provides of the package (i.e., diff all the things currently provided by the package vs. the things it provided in the previous published version, and build fails if there are differences). I'd like a similar test procedure for all the warnings (especially compiler warnings) produced during package building.]

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

check for multilib conflicts https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00432.html

automaticall check for file conflicts and unowned directory

Recently, some packages hasn't been branched due to no proper review. So maybe we have to define how the review should look like to be proper. [1]

Miscellaneous

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. Rahul suggest that it would be quite useful to document every single difference between core and extras somewhere so that we can tackle this as we move along.

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.

nim-nim suggested we might need a full-time dedicated documentation team.

We should also make sure that all extras contributors have access to the wiki

do the FE builders use the reduced package set yet?

the buildsys needs proper support for kmods

Our builders currently don't use Fedora Legacy when building for Extras packages that are in maintain mode (FC3, FC4 soon)

Incompatible package upgrade policy: Seems like we need tools and/or a policy that will allows packagers to 1. notify others when the packager breaks something that others depend on; 2. notify the packager when he's about to break somwthing that others depend on. Warren is working on a proposal. See also problems like this . Find someone that drives this forward after the FESCo election

Fedora Extras metrics -- ElliotLee worked on it in the past but got distracted. From the old schedule: "Some new metrics: "What's the longest time that a package has been stalled in an FE- state?" and "how many packages are in various FE- states over time?" Also around for a long time already. We have the pacakge reports from c4chris these days -- do they cover everything we're interested in? The remaining parts should be merged"