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