EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

["Jóhann B. Guðmundsson"]

On 07/22/2013 04:08 PM, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/22/2013 11:58 AM, "Jóhann B. Guðmundsson" wrote:
>> Our Fedora infrastructure team should be using Fedora it's an
>> disgrace to the community for them not doing so.
>>
> That's something else that this policy could potentially addresses,
> frankly. The reason our infrastructure team doesn't use Fedora is
> because upgrading critical infrastructure every six months is simply
> infeasible. If we adopt this plan where we have a fairly solid core,
> then we could build essentially a Fedora Infra SIG that could then
> have a custom server build for maintaining the build infrastructure
> and hosting pieces. Right now, Fedora is not the right platform for
> that, but maybe we could identify that as one of the goals of this
> project. Would you be interested in participating in that SIG and help
> design it?

Ofcourse

>> Just keep that documentation out of our wiki ( or in epel's own
>> under epels own domain or lock tide within red hat docs )  since
>> that has nothing to do with Fedora and having it there only
>> confuses Fedora packagers
>>
> There are arguments to be made for keeping EPEL's documentation
> separate, sure. But the simple fact is that in most cases, they differ
> by less than 1% and it's more economical to keep them both up to date
> if they're just the same page with effectively an #ifdef.
>
> As for cruft in the spec files, why not bring a proposal to the FPC to
> update the packaging guidelines stating that Fedora spec files must
> not contain RHEL/EPEL macros? Then the git branches would be
> maintained separately and the spec files might be more easily read.

Because I have reach the conclusion that bringing anything up with FPC 
is just waste of everyone's time

 From their decision making ( which often to me make no sense ) to the 
time it takes for them to approve and implementing changes to the 
packaging guidelines ( even from "concrete" proposals ) are absurd and 
more often then not takes longer time than to actually implement the 
requested change on affected components which makes it impossible to try 
to schedule ones free time to make those changes even scheduling to make 
those changing within our development cycle.

A far more efficient approach is to adapt an ack/nack/patch approach on 
the packing community mailinglist and dissolve FPC.

JBG