Matthias Saou wrote:
I got the impression that the discussions which started ended with very few interventions from Red Hat's side, and "let's just reuse fedora.us" from the people contributing to fedora.us's side. Without more elements from Red Hat as to where the main direction is headed, I don't think current discussions can get to an acceptable (i.e. interesting) signal/noise level, and I take this very thread as a witness ;-)
Matthias
There are a two possible reasons why Red Hat developers have generally not gotten involved with our standards discussions.
1) Some have stated that they truly feel strict documented standards that fedora.us finds important simply DO NOT MATTER. They rather continue doing things the old way: Few strict standards and basically do whatever seems to work. This thankfully is a minority position.
2) Others who might care are simply too busy tackling DIFFICULT real development problems, like selinux or Gnome 2.6.
What we must all realize, especially Red Hat developers, is that we MUST discuss the standards that we will use for FC2 now. We must be prepared early during the beta period. And it DOES matter. We must have packaging guidelines, processes and policies documented unlike relying on the time consuming self-learing process, if we are ever to make this a truly open collaborative community project.
If Red Hat is not involved in these standards discussions, what I fear will happen is the community will create process & policy documents. Then later when those standards matter (FC2), Red Hat totally ignores it because they don't take us seriously, and they were not involved in those discussions. I see us heading in this direction and yet another not-so-openly-developed FC release unless things change now.
Regarding "let's just reuse fedora.us", I have long advocated doing so because fedora.us WORKS TODAY, and nobody else has submitted anything else remotely near a full comprehensive alternative proposal.
Building upon the current fedora.us, our discussions here will IMPROVE upon exising fedora.us policies & procedures in order to be prepared for FC2 and the Fedora Extras merge. Among the proposed changes in policies & procedures are:
* Package Naming will be altered with the overall goal of simplifying the fedora.us naming conventions without introducing new packaging problems. ** Remove the leading "0.fdr." from %{release} tags. ** Fully numeric disstags have been favored by RH and fedora.us leadership in past discussions, but this requires more discussion. ** reptag will not be necessary for Fedora Core and Fedora Extras, since FC and FE will be the authoritative repositories. All other repositories build around the FC+FE base. ** reptag will be necessary for all other repositories. The current proposal is attaching it at the end of %{release}.
* Changes to the QA process to allow smoother publication of packages without sacrificing quality and safety. * Better documentation explaining development processes, so new developers can get onboard more easily without wasting much time of existing developers. * Better documentation explaining the developer & tester trust gaining process. * All packaging conventions are to be compiled into a single better formatted package, with links to deeper information about individual packaging requirements. * Probably a lot more, but I can't think too well at 3:41AM...
I am now heading toward personally working on the following two: ---------------------------------------------------------------- * CVS with trust and legal forms requirements. ACLs allow users to have commit access to only certain packages of the repository, allowing the package maintainers to be community members. * Public build system available to trusted developers. Trusted developers can act as conduits for newer developers while they are in the process of gaining trust. All source code for the public build system will be fully Open Source and available for others to replicate for their own tesitng purposes, or 3rd party repository development.
Warren