Proposal: Repository Community Collaboration Statement
by Tim Jackson
I have a feeling I might regret this, but if nobody tries....
I have written up below a proposed simple statement of collaboration
which ideally a number of interested parties in different repositories
(EPEL, Fedora, RPMforge, AT etc.) could sign up to.
At this stage I'm interested mostly in whether people like the broad
principle, rather than picking apart specific wording as I'd rather this
didn't descend into a discussion about semantics or politics. Basically:
is this something that people feel could form the basis of something
they'd be willing to sign up to? Or should we all just go back to
arguing about repotags?
---------------------------------------------------------------------
Repository Community Collaboration Statement
---------------------------------------------------------------------
This is a statement signed by a number of groups which produce add-on
RPM packages for the following operating systems:
- Fedora Linux
- Red Hat Enterprise Linux and compatible derivatives
This statement is not binding and does not by itself compel anyone to do
anything. Any signatory may withdraw at any time. However the
signatories have agreed to the principles contained within it and commit
to working together for mutual benefit.
1. Statement of goals
The signatories have as a high level objective the development of
packages for the targeted operating systems which are technically sound,
robust and give an excellent user experience. Whilst acknowledging that
"mixing repositories" will always be somewhat unpredictable due to
differing goals and standards amongst signatories, the signatories aim
to promote informed choice amongst users by avoiding unnecessary user
inconvenience when switching between competing packages.
2. Acknowledgement of independence
Each signatory is independent and fully entitled to operate in a
self-sustaining way which does not depend on other signatories. This
includes all senses but notably infrastructure and policy. This
Agreement does not override the signatories' own policies, though it is
expected that signatories will normally make reference to this Agreement
in their own policies.
3. Acknowledgement of peer status
For the purpose of this Agreement, the signatories agree to act as peers
and no signatory is considered superior.
4. Main agreements
The signatories agree therefore to promote the following standards
amongst their contributors:
a)to make reasonable efforts to research existing packages (if any)from
other signatories before starting to package a certain item of
software from scratch
b)to make reasonable ongoing efforts to keep competing packages as
similar as possible, particularly in the sense of RPM dependencies and
file locations, such that upgrades or migrations between different
repositories are not unecessarily difficult for users
c)to avoid wherever possible publishing packages which are egregiously
incompatible with packages from other signatories, without sound
technical reasons
d)to attempt to collaborate constructively at an intellectual level with
other signatories and their contributors where reasonably possible,
particularly where a contributor feels there are specific technical
deficiencies in existing signatories' packaging; the signatories
acknowledge that it is better to discuss these differences in an open
and respectful fashion and try to reach a consensus solution, rather
than creating incompatible packages.
SIGNATORIES:
[list]
-----------------------------------------------------------------------
Tim
16 years, 11 months
Collaboration
by Johnny Hughes
=====================================================================
Main Entry: col·lab·o·rate
Pronunciation: k&-'la-b&-"rAt
Etymology: Late Latin collaboratus, past participle of collaborare to
labor together, from Latin com- + laborare to labor
1 : to work jointly with others or together especially in an
intellectual endeavor
2 : to cooperate with an agency or instrumentality with which one is not
immediately connected
=====================================================================
Question1:
If RPMforge has a perfectly working ClamAV for EL5, and if we are
collaborating, why would EPEL build ClamAV?
Question2:
If ATRPMS has a perfectly working nx/freenx for EL5, and if we are
collaborating, why would EPEL build nx / freenx?
=====================================================================
Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not
just a 3rd Party Repo. There can be no misinterpreting that, it is just
plain fact.
If we were collaborating, EPEL would build things not already in
RPMforge or ATRPMS or CentOS Extras. We are not collaborating, we are
consolidating under the rule of the EPEL team.
So if that happens and if EPEL is maintaining 8000 packages with the
help of the Dag, Dries, Alex, Rex, the CentOS Devels .. then how long
till this bright idea:
Hmmm ... This EPEL thing is going so good, what about a collaborative
Fedora EL to consolidate all the rebuilds?
It is only a matter of time until that happens, as far as I can see.
Now, if EPEL is really interested in collaboration, and not domination,
then some assigning of master packages to RPMForge and/or ATRPMS ... and
using existing RPMForge and ATRPMs binary packages in the mock build
repo definitions would go a long way toward quieting the domination
speculation.
All I see, frankly, is this:
EPEL is "THE" 3rd Party repo for Red Hat based EL ... join us, play by
our rules, and submit all your packages here. Integration ... sure, the
other guys can join us and play by our rules or not. Collaboration ...
sure, the other guys can stop what they are doing and join us and play
by our rules or not.
Why does that make me even the slightest bit nervous ... I mean, Red Hat
would never ever pull the plug on supporting Fedora EPEL (Or the
mythical Fedora EL, if it happened and put CentOS out of business),
would they? Of course they would if it enhanced their business model.
Anyone here ever heard of Red Hat 9?
I am not ready to hitch CentOS to this model to see it be made
irrelevant by the next progression in this process ... so what
assurances are there that the master plan is not to totally dominate the
community Red Hat based EL market (a position that CentOS currently
holds based on the extremely hard work of about 20 people, the donations
of hundreds of ISPs and Mirror Providers, etc.).
Getting tied back in to same process/entity that fragmented this market
in the first place does not seem very logical to me.
Thanks,
Johnny Hughes
17 years
Fedora EPEL Package Build Report 2007-04-29
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 14
NEW ghex-2.8.2-4.el5
NEW gweled-0.7-8.el5
perl-Net-LibIDN-0.09-2.el5
NEW php-pear-DB-DataObject-FormBuilder-1.0.0-0.4.RC7.el5
NEW php-pear-DB-QueryTool-1.1.0-1.el5
NEW php-pear-File-1.2.2-1.el5
NEW php-pear-HTML-Common-1.2.3-3.el5
NEW php-pear-HTML-QuickForm-3.2.7-3.el5
NEW php-pear-HTML-Table-1.7.5-1.el5
NEW php-pear-Net-URL-1.0.14-1.el5
NEW pop-before-smtp-1.41-2.el5
NEW python-crypto-2.0.1-4.el5
NEW revelation-0.4.11-2.el5
NEW uw-imap-2006g-2.el5
Packages built and released for Fedora EPEL 4: 4
NEW gweled-0.7-8.el4
perl-Net-LibIDN-0.09-2.el4
NEW scim-1.4.4-2.el4
NEW scim-tables-0.5.6-1.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years
Relationship to existing 3rd party repos/CentOS/SL?
by Axel Thimm
Hi,
the voting/decision on repotags was labeled as being 99% a political
one, and no one objected against that old statement. Does the outcome
of EPEL not carrying repotags mean that there is no interest in
cooperation with 3rd party repos?
I'm not after answers on pseudo-technical details, so consider the
above question as rhetorical, instead let me rephrase completely
outside the scope of repotags:
What is EPEL's intended relation to the existing third party repos?
* Will it jump in the game ignoring that 3rd party repos exist and
let Darwinism prevail?
* Will it try to work together with these repos? If yes, in what
concrete way?
* Does EPEL consider itself at the same level as these repos, or does
it place itself higher, pushing any compatibility issues to the
workload of these repos?
The Fedora/3rd party rift created several years ago is still in the
healing process, I think everyone agrees in retrospect that it wasn't
neccessary and we'd be better off not to allow it to happen in the
first place.
But I see the danger of this history pattern to repeat itself, and
standing with one feet in a 3rd party repo and another in EPEL I'm in
conflict with myself right now, so I'd like us to clarify this.
--
Axel.Thimm at ATrpms.net
17 years
rsync access to EPEL?
by Orion Poplawski
Any rsync access to EPEL yet?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
17 years
Fedora EPEL Package Build Report 2007-04-25
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 11
denyhosts-2.6-4.el5
NEW ncftp-3.2.0-3.el5
NEW php-pear-DB-DataObject-1.8.5-2.el5
NEW php-pear-MDB2-2.4.0-1.el5
NEW php-pear-MDB2-Driver-mysql-1.4.0-1.el5
NEW php-pear-Validate-0.7.0-1.el5
NEW php-pear-Validate-Finance-CreditCard-0.5.2-1.el5
NEW php-pear-XML-Beautifier-1.1-2.el5
NEW php-pear-XML-RSS-0.9.10-3.el5
rrdtool-1.2.19-2.el5
NEW spr-05.01.00-3.el5
Packages built and released for Fedora EPEL 4: 5
NEW SIBsim4-0.15-1.el4
denyhosts-2.6-4.el4
NEW ncftp-3.2.0-3.el4
rrdtool-1.2.19-2.el4
NEW spr-05.01.00-3.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years
Topics for todays EPEL SIG meeting
by Thorsten Leemhuis
Hi all!
Here are the IMHO main topics the SIG Meeting probably should look at in
todays meeting (17:00 UTC, #fedora-meeting on freenode):
/topic EPEL Meeting -- mass rebuild for RHEL5
/topic EPEL Meeting -- chairmen
/topic EPEL Meeting -- shortcut for branching -- dgilmore?
/topic EPEL Meeting -- Communication plan for enterprise
customers/ISVs/IHVs -- stahnma, quaid
Looks like I'll miss todays meeting as I have to join something work
related -- that's scheduled one hour earlier than the EPEL SIG Meeting,
and will probably take until after it ends. No keyboards or computers
nearby. Sorry.
Nevertheless, here are some things from my side:
- mass rebuild for RHEL5 -> somebody should check how much stuff got
rebuilded; we should decide what to do with the rest of the arch
packages. My vote: add a ".1" to release, commit, tag, build after a
additional wait period of 48 hours; I really want to get this of the table.
- chairmen -> I'm willing to to that job for the next months. Most of
you know how I worked in FESCo, which as such is my reference ;-) My
main goal is to get EPEL really speed up now.
- "shortcut for branching -- dgilmore?" -> Now that we have RHEL5 on the
builders and the rebuild is done soon I really want to give a "start
now" signal to Fedora contributors that are waiting for it (there are
some that do). But I fear questions like "do I have to go through
bugzilla for all of my X packages to ask for EPEL branches?" or "what to
do with packages that were reviewed in the early days (e.g. before we we
used bugzilla)". We should find a solution for those questions and
document them somewhere before we give the "start now" signal. But we
need a CVS admin for that that tells us how this shortcut could looks
like. dgilmore?
CU
thl
17 years
What I want in a chair
by Mike McGrath
As discussed in the last EPEL meeting we decided it was best to have a
chairperson to help EPEL get off the ground over the next 6 months.
Here's what I'm looking for in a chairperson
1) Somone who can convey a consistent EPEL message to the public,
especially when it is officially launched
2) Must be able to balance what's best for EPEL, the larger community,
3rd party repo's and the users when their needs conflict.
3) Someone who is close to the EPEL community and can put EPEL community
needs above their own
4) This person must be accountable (if they go all crazy we can always
ask the board to remove them)
5) Primarily a facilitator, when decisions cannot be made, the community
is split or opinions are not-obvious, this person can call for a vote or
simply make the decision on their own.
The idea here is that this person will be here for 6 months which, in
Fedora time, is not very long. I have no fears about what this person
will do because A) they will be accountable and B) It's just for 6
months. If we don't like what they've done we can remove them at that
time or, more likely, pick a different governance model. I don't think
EPEL is mature enough to need an extremely formal government which IMHO
is perfect for a chairperson. They can listen to what's up and people
can go to the chair with concerns they care about.
The question now is where does this leave the SIG? Same place, we meet,
we discuss, we ultimately do the work. It's the spirit of this
agreement that's important and I think in practice we'll find this a
very easy / beneficial situation.
-Mike
17 years
