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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
