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

[Michael Schwendt]

On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote:

>  * 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.

There ought to be a web page with announcements. The history of decisions
made by FESCo.  As a contributor, even if you skim over the summary of a
meeting, after a week you have forgotten what FESCo had agreed on in
previous meetings. Also, the meeting summaries don't really concentrate on
the important bits. There's too much noise in them.
 
>   * How FESCo works isn't much documented

It's not documented at all.  And it will get more complex now that other
committees and project instances spring up like mushrooms.
 
>   * 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.

This paragraph contains a hint: "IRC" - those, who use IRC for real-time
discussions, need to share the results of the communication, using the
relevant mailing-lists.

Participation in simple decisions "on list" has been poor, too, despite
FESCo consisting of 17 members.

>  * Co-Maintainership
> 
>   * This is IMO one of the biggest areas we should work on soon

It is unimportant. Co-maintenance is possible for a long time. It
just needs additional communication between those who team up.

The biggest hindrance in this area probably is the non-working "Cc" field
in owners.list.
 
>   * 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)

Not "each package", but packages with increased maintenance requirements
would benefit from a team of packagers.
 
>  * 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)

Unrealistic. For instance, I see 9817 unread/unfiltered messages in my
fedora-extras-commits folder. And while it may be easy to spot obvious
mistakes, it is less easy to find anything that's missing, especially
during upgrades.

>   * 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?

Well, when Core is rebuilt due to important changes/improvements in GCC,
would it be possible that FESCo is notified about that? Or if somebody
within FESCo learns about such a rebuild, that there will be an official
announcement about what FE packagers should/must do?

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

owners.list is insufficient. Not enough fields for the various state
information and/or comments.

However, a policy could say that every package in owners.list which
belongs to extras-orphan@ must not exist in the repository and must be
disabled in CVS. 
 
>   * we need to make the x86_64 more multilib aware (i386 packages in the
> x86_64 repo)

I've asked about it before, but have not found a wealth of information.
In this area we depend on Core. We cannot invent our "own thing" in the
push script, since Core must contain everything our multilib packages
depend on.

>   * 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 ...

Not necessary for commits. Full name and user name are in the "From"
line in the mail header and in the "Author:" field of the body.

Receiving copies of build server responses would be funny, though.
 
>   * 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;

It's not the confusion that hurts, but the insane amount of cross-posting.
 
>   * the broken deps reports are really nice, but maybe we should merge
> them into one per push (currently it's one per dist)

... and none if no broken deps are found. So fix your broken packages
and reduce the number of reports to one. :)

Four (ore more) dists in one mail would decrease readability too much,
IMO.
 
>   * 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)?

We might start collecting reusable Python code in a module, so it would
become even easier to enhance new and existing scripts with extra
features.
 
>   * is it time to clarify/simplify the Fedora Packaging guidelines again
> to make them easier?

Better don't. You cannot simplify them a lot because there are packages
which are not simple to package/maintain.
 
>   * Scratch build target?
> 
>   * updates-testing repo for Extras?

Both have been discussed multiple times before, and if not integrated
_correctly_ we would end up with multiple build targets and "funny"
side-effects in the build results.