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