Hello,
I am about to import most of my packages in EPEL. Some are in other repos (dag, dries). For the packages I have looked at (acpitool, gnochm), there is no specific need for coordination (no different name, split...). I can contact the people maintaining the packages in other repos, but do youhave an idea on what should be coordinated? One thing I see is the release. It seems to me that the repos should play nice and avoid updating over other repo packages. So maybe we could have rules like avoid upgrading dag repo by making sure that the release in epel is lower? Any idea about this issue, and any idea about other area where coordination is needed?
What is the status of the agreement betwen repos?
-- Pat
Patrice Dumas wrote:
Hello,
I am about to import most of my packages in EPEL. Some are in other repos (dag, dries). For the packages I have looked at (acpitool, gnochm), there is no specific need for coordination (no different name, split...). I can contact the people maintaining the packages in other repos, but do youhave an idea on what should be coordinated? One thing I see is the release. It seems to me that the repos should play nice and avoid updating over other repo packages. So maybe we could have rules like avoid upgrading dag repo by making sure that the release in epel is lower? Any idea about this issue, and any idea about other area where coordination is needed?
What is the status of the agreement betwen repos?
Please see the mailing list history, there is already a great deal of discussion on this topic. There are quite a few repos out there (dag is just one of them).
-Mike
On Sun, Aug 05, 2007 at 12:23:34PM -0500, Mike McGrath wrote:
Patrice Dumas wrote:
Hello,
Please see the mailing list history, there is already a great deal of discussion on this topic. There are quite a few repos out there (dag is just one of them).
I remember reading the posts, but I don't remember anything practical being said, especially that responds to my questions. I used dag as a fictitious example.
Another question (quite unrelated), is there a place where the repos are listed?
-- Pat
Patrice Dumas wrote:
I remember reading the posts, but I don't remember anything practical being said, especially that responds to my questions. I used dag as a fictitious example.
I don't think anything was decided upon along those lines you were asking for. Tim wrote up a draft for a high level agreement and I made some changes he seemed to be unhappy with.
http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
You can find the original draft in a previous revision. I haven't had time to followup through FESCo or other repository maintainers yet though Rex Dieter did add a acknowledgment. If they find this or the previous draft useful, we can push through this. If other repository maintainers are watching the discussions, do provide some feedback.
Another question (quite unrelated), is there a place where the repos are listed?
We generally avoid pointing to third party repositories to avoid any potential legal risks. EPEL FAQ mentions centos.karan.org (in a positive way) since it is a simple rebuild of Fedora Extras and would only contain patent encumbered Free and open source software just like Fedora.
Rahul
On So August 5 2007, Patrice Dumas wrote:
Another question (quite unrelated), is there a place where the repos are listed?
Some repos are listed in the CentOS wiki:
http://wiki.centos.org/Repositories
Regards, Till
On 05.08.2007 19:10, Patrice Dumas wrote:
I am about to import most of my packages in EPEL. Some are in other repos (dag, dries). For the packages I have looked at (acpitool, gnochm), there is no specific need for coordination (no different name, split...). I can contact the people maintaining the packages in other repos, but do youhave an idea on what should be coordinated?
In such a case where names, spits are similar and as long as there are no reports from users about broken deps it can't hurt to contact the maintainers of other repos to exchange patches, discuss bugs or stuff like that if there is a need to.
One thing I see is the release. It seems to me that the repos should play nice and avoid updating over other repo packages. So maybe we could have rules like avoid upgrading dag repo by making sure that the release in epel is lower?
I don't think that's possible. Different repos follow different ideas and different update strategies -- such rules would be problematic and hindering for everyone afaics.
[...]
CU knurd
On Mon, Aug 06, 2007 at 05:55:02PM +0200, Thorsten Leemhuis wrote:
On 05.08.2007 19:10, Patrice Dumas wrote:
I am about to import most of my packages in EPEL. Some are in other repos (dag, dries). For the packages I have looked at (acpitool, gnochm), there is no specific need for coordination (no different name, split...). I can contact the people maintaining the packages in other repos, but do youhave an idea on what should be coordinated?
In such a case where names, spits are similar and as long as there are no reports from users about broken deps it can't hurt to contact the maintainers of other repos to exchange patches, discuss bugs or stuff like that if there is a need to.
Ok, that I could do, but currently there are no such needs. Names and split are the same, no specific bugs or the like, so there is nothing specific to discuss with other repos except for coordination. I could just say, 'hey I will maintain that package in EPEL', but is it really coordination?
in http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration there is:
* Contributors need to make an effort to check if there are packages in third party repositories that would conflict with any new packages submitted to the official repository and if so establish contact with the maintainers of packages in other third party repositories.
So it seems that the contact is asked for for contributors who want to coordinate with other repos, but I don't understand what it practically means in term of coordination. Once again if it is just 'hey I will maintain that package in EPEL', this just seems to be a waste of time if there is nothing more to propose to other repos for collaboration.
(Of course when there are technical issues, it always pays to speak with other repo maintainers, but that's a completly different issue).
One thing I see is the release. It seems to me that the repos should play nice and avoid updating over other repo packages. So maybe we could have rules like avoid upgrading dag repo by making sure that the release in epel is lower?
I don't think that's possible. Different repos follow different ideas and different update strategies -- such rules would be problematic and hindering for everyone afaics.
If repos upgrades each other is it still possible to speak about coordination/colaboration?
As I stated several times before, EPEL can either try to collaborate with other repos or try to absorb them, I personally don't mind that much. But this should be consistently done. If there is no policy for collaboration, we shouldn't say that we are collaborating.
-- Pat
Patrice Dumas wrote:
in http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration there is:
- Contributors need to make an effort to check if there are packages in third party repositories that would conflict with any new packages submitted to the official repository and if so establish contact with the maintainers of packages in other third party repositories.
That document was just a suggestion. Despite my efforts, there doesn't seem to be any particularly strong enthusiasm to make it something that is formally signed up to by anyone. I see that KDE-RedHat have indicated their interest which is cool, but it's not been ratified by anyone at the RHEL end, and the doc could do with reverting to a former version which is "neutral" and actually makes sense for everyone to sign up to (vs just EPEL)
That's not to say it mightn't form the base of some "good practice" guidelines though, I suppose...
Tim
I wrote:
That document was just a suggestion. Despite my efforts, there doesn't seem to be any particularly strong enthusiasm to make it something that is formally signed up to by anyone. I see that KDE-RedHat have indicated their interest which is cool, but it's not been ratified by anyone at the RHEL end, and the doc could do with reverting to a former version
^^^^ EPEL
Tim
epel-devel@lists.fedoraproject.org
-
Mike McGrath -
Patrice Dumas -
Rahul Sundaram -
Thorsten Leemhuis -
Till Maas -
Tim Jackson