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

[Thorsten Leemhuis]

Michael Schwendt schrieb:
> 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. 

I think the FESCo meeting summaries should have a section annoucements.

But I oppose a web page with a decision history. Decisions should be
documented at a proper place where they belong (for exmplae the
dead.package mechanism should be documented on the extras-cvs-faq page.
Or in a maintainer guide). They need to be documented there in any case
an maintaining two places is ridiculous IMHO.

Note: Yes, for some decisions there might be no proper place. Creating a
 special page for them might be a good idea.
>[...]
>>   * 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.

Agreed.

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

Agreed.

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

I think that will improve with the new FESCo members (and that was a
reason for the Election).

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

It is important to work on...

> Co-maintenance is possible for a long time.

..because it's not used.

> [...]
> The biggest hindrance in this area probably is the non-working "Cc" field
> in owners.list.

Agreed. And per-dist maintainers are also not possible

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

In my option: each package. Everyone is offline now and then or even on
holiday for two or three weeks. A backup for those times would be good IMHO.

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

Maybe.

> For instance, I see 9817 unread/unfiltered messages in my
> fedora-extras-commits folder. And while it may be easy to spot obvious
> mistakes,

I think it is and that's all I want because

> it is less easy to find anything that's missing, especially
> during upgrades.

that is to hard job.

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

f13 announced the last mass-rebuilds on fedora-maintainers. And jeremy
is in FESCo, I'm sure he'll poke us.

> Or if somebody
> within FESCo learns about such a rebuild, that there will be an official
> announcement about what FE packagers should/must do?

I'm not sure I understand you correctly. It for sure will be announced
when FESCo agrees on a mass-rebuild.

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

I love e-mail communication. Did I write anywhere the owners.list is the
proper solution? No!

> Not enough fields for the various state
> information and/or comments.

The package database is in the planing stages; please make sure it has
all the fields you think that might be needed.

> However, a policy could say that every package in owners.list which
> belongs to extras-orphan@ must not exist in the

devel

> repository

I think we agreed on that during the mass rebuild for FC5.

> and must be
> disabled in CVS. 

Sounds like a good idea.

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

Yes.

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

I'd like to have them for commits.

> Full name and user name are in the "From"
> line in the mail header and in the "Author:" field of the body.

Username might change and thus break local filters. Local filter can be
forgotten. Or set up wrongly.

Also non-sponsors might be interested in this feature as well.

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

Both AFAICS.

I'd prefer if fedora-maintainers would be more like an moderated,
non-discussion announce-list to inform all the maintainers about
important things. Discussion on the other two lists.

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

I disagree, but that's personal style.


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

I tend to agree.

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

Yes. But that's not a rason to not have them on this list.

Cu
thl