Fedora Extras

[Warren Togami]

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