On Tue, 21 Oct 2008 15:54:20 -0600, Stephen John Smoogen wrote: > Now that we are constructive talking.. how can we lower the > bureaucracy and build trust in an environment where its all based on > who knows who and relationships take a long time to build up (I mean > this for any project from the Linux kernel, etc.) Well, that's the interesting part of starting such a project. ;) How many of the "interested developers" will be new people who would register in FAS for the first time? How much information about themselves are they willing to disclose? Inside the Fedora project you need to ask yourself anyway how much you trust fellow contributors? Some are with the project for several years, but you need to rely on the sponsorship process as you don't know everyone (and you don't verify regularly that it's still the same person who uses a fedora account or that the intentions are still good). How many volunteer specialists are available to support some of the huge core packages? Copying and rediff'ing patches only is one thing, porting patches between versions is something completely different. In an older discussion I've suggested a dry-run for such a project. It could start with F8 EOL, albeit a boring period and a lot to do (evaluating vulnerability notifications alone is a lot of work). How patient would contributors stay before they would give up or switch to another dist? If reviewing is needed, the core team of a LTS project could sign off patches submitted by completely new contributors, who haven't been active in Fedora before. It ought not create significant delays in getting something published, as contributors will likely become unsatisfactory soon with productivity issues or find other reasons to leave. There are existing procedures, such as the sponsor- or mentor-model for new people. Existing infrastructure would help, too: pkg cvs commit diffs posted to a mailing-list, for example, which is not a separate list on a server in some other domain. This adds the possibility that some completely unexpected pair of eyes skims over the diffs, rather than just a small number of contributors. More convenient than having to do rpmdiff manually. Source tarballs can be checksum-compared with newer Fedora branches in lookaside cache. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
