Re: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux