Hi,
A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it
Cheers and seasons greetings
Marianne / Jehane
On Tue, 2014-12-30 at 14:53 +0100, Marianne Lombard wrote:
Hi,
A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it
This bug seems unnecessary. AFAIK all it takes to create a branch for a package is a willing maintainer who's already a packager, in this case you, to make a SCM request for it in the package review request
https://bugzilla.redhat.com/show_bug.cgi?id=607878
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requ...
Make sure to list yourself as a "owner" of the new branch.
Its perfectly understandable for a primary POC of a package on the Fedora branches to not want to deal with the EPEL packaging.
Regards Yanko
Cheers and seasons greetings
Marianne / Jehane
-- Marianne (Jehane) Lombard Geekfeminist and sysadmin
Hi,
I have written here because the bug was already 5 month old without a reaction and the package don't seem maintened (upstream is 0.43 and fedora is 0.39 ). I have follow your advice and made a request for epel7
Le 30/12/2014 16:09, Yanko Kaneti a écrit :
On Tue, 2014-12-30 at 14:53 +0100, Marianne Lombard wrote:
Hi,
A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it
This bug seems unnecessary. AFAIK all it takes to create a branch for a package is a willing maintainer who's already a packager, in this case you, to make a SCM request for it in the package review request
https://bugzilla.redhat.com/show_bug.cgi?id=607878
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requ...
Make sure to list yourself as a "owner" of the new branch.
Its perfectly understandable for a primary POC of a package on the Fedora branches to not want to deal with the EPEL packaging.
Regards Yanko
Hi,
I have written here because the bug is already 5 month old without a reaction and the package don't seem maintained (upstream latest release is 0.43 and fedora package is 0.39 ). I have follow your advice and made a request for epel7.
Regards
Marianne
PS : please excuse the noise, I'm still a newbie packager
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Dec 2014 17:09:02 +0200 Yanko Kaneti yaneti@declera.com wrote:
On Tue, 2014-12-30 at 14:53 +0100, Marianne Lombard wrote:
Hi,
A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it
This bug seems unnecessary. AFAIK all it takes to create a branch for a package is a willing maintainer who's already a packager, in this case you, to make a SCM request for it in the package review request
Policy does require you to contact the maintainer http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL It is quite inappropriate to not have the courtesy to contact the fedora maintainer first.
https://bugzilla.redhat.com/show_bug.cgi?id=607878
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requ...
Make sure to list yourself as a "owner" of the new branch.
Only do that after contacting the Fedora maintainer
Its perfectly understandable for a primary POC of a package on the Fedora branches to not want to deal with the EPEL packaging.
It is quite understandable and acceptable, but you do need to contact them to check first and not just go and branch a package. branching is not without cost, as things are setup Fedora maintainers will still get bug reports and email. there may also be a very valid reason for not branching a package.
Dennis
On 8 January 2015 at 15:54, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Dec 2014 17:09:02 +0200 Yanko Kaneti yaneti@declera.com wrote:
On Tue, 2014-12-30 at 14:53 +0100, Marianne Lombard wrote:
Hi,
A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it
This bug seems unnecessary. AFAIK all it takes to create a branch for a package is a willing maintainer who's already a packager, in this case you, to make a SCM request for it in the package review request
Policy does require you to contact the maintainer http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL It is quite inappropriate to not have the courtesy to contact the fedora maintainer first.
Or the policy can be revisited if potential maintainers are having problems getting replies from current maintainers.
https://bugzilla.redhat.com/show_bug.cgi?id=607878
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requ...
Make sure to list yourself as a "owner" of the new branch.
Only do that after contacting the Fedora maintainer
Its perfectly understandable for a primary POC of a package on the Fedora branches to not want to deal with the EPEL packaging.
It is quite understandable and acceptable, but you do need to contact them to check first and not just go and branch a package. branching is not without cost, as things are setup Fedora maintainers will still get bug reports and email. there may also be a very valid reason for not branching a package.
I thought the problem was that the maintainer was not responding (eg what the subject line says.) Since the person is not responding.. what is needed next.
On Thu, 2015-01-08 at 16:54 -0600, Dennis Gilmore wrote:
On Tue, 30 Dec 2014 17:09:02 +0200 Yanko Kaneti yaneti@declera.com wrote:
On Tue, 2014-12-30 at 14:53 +0100, Marianne Lombard wrote:
Hi,
A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it
This bug seems unnecessary. AFAIK all it takes to create a branch for a package is a willing maintainer who's already a packager, in this case you, to make a SCM request for it in the package review request
Policy does require you to contact the maintainer http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL It is quite inappropriate to not have the courtesy to contact the fedora maintainer first.
I have't seen that policy, but now that I've read it it seem misguided. My thinking is: - If the Fedora maintainer cared and there was no technical reason the branches would already be there. - Most Fedora maintainers know well enough if there is or isn't any technical reason. - "I am too busy and I'll get to it later" - is no good excuse for blocking people willing to do the work. - "I beleive this package is not suitable for an LTS release, so I'll block it" - is just hubris. - Lets not put red tape for more people to do the work in a place where good sense should be more than enough to prevent conflict.
https://bugzilla.redhat.com/show_bug.cgi?id=607878
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requ...
Make sure to list yourself as a "owner" of the new branch.
Only do that after contacting the Fedora maintainer
Its perfectly understandable for a primary POC of a package on the Fedora branches to not want to deal with the EPEL packaging.
It is quite understandable and acceptable, but you do need to contact them to check first and not just go and branch a package. branching is not without cost, as things are setup Fedora maintainers will still get bug reports and email. there may also be a very valid reason for not branching a package.
From what I've seen the new pkgdb interface makes it very clear who is
responsible for any particular branch.
Regards Yanko
On Fri, 09 Jan 2015 09:40:17 +0200, Yanko Kaneti wrote:
Policy does require you to contact the maintainer http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL It is quite inappropriate to not have the courtesy to contact the fedora maintainer first.
I have't seen that policy, but now that I've read it it seem misguided. My thinking is:
- If the Fedora maintainer cared and there was no technical reason the
branches would already be there.
"Cared"? This is the fundamental problem. Care about what? About making available a package _also_ for EPEL? Or about maintaining it properly and as appropriate for the long life-cycle of the mother product RHEL?
EPEL should not be treated as just another dist target to build for. Don't take it lightly. Don't dump builds into EPEL without considering what may become necessary for future bug-fixes, security-fixes or even back-ports when the build requirements of an upgrade are not met by RHEL.
It is perfectly fine, if someone with special interest in EPEL volunteers as the EPEL package maintainer when the Fedora package maintainer has not created the branches for EPEL before. Be aware of the consequences of offering something for EPEL. It is not easy to make RHEL/EPEL users happy. Those, who are not affected by bugs, don't want version upgrades which may cause regression and new issues. Those, who are affected by bugs, want bug-fixes (which may make version upgrades necessary!). And there are also those, who want always new versions as if it's a drug. Finding existing packages saves them some work, but they don't "care" much, because they build things themselves once the existing packages are out-of-date, and they don't care either whether that may break the dist.
- Most Fedora maintainers know well enough if there is or isn't any
technical reason.
Not sure about that. The type of maintenance which is appropriate for EPEL is underestimated. When you offer something for EPEL, you somehow need to predict whether you will be able to handle security fixes, backports and/or upgrades in the future for a long time.
- "I am too busy and I'll get to it later" - is no good excuse for
blocking people willing to do the work.
True.
Not responding in bugzilla in time is no good excuse either.
- "I beleive this package is not suitable for an LTS release, so I'll
block it" - is just hubris.
True, too. Is there an EPEL project leadership which could review such "decisions"? The opposite, offering something for EPEL only to orphan it some time later, can be considered damaging, too.
- Lets not put red tape for more people to do the work in a place
where good sense should be more than enough to prevent conflict.
Still it's too easy to release packages in the Fedora and EPEL dists and then abandon them without any notification.
On Fri, 2015-01-09 at 11:22 +0100, Michael Schwendt wrote:
On Fri, 09 Jan 2015 09:40:17 +0200, Yanko Kaneti wrote:
Policy does require you to contact the maintainer http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL It is quite inappropriate to not have the courtesy to contact the fedora maintainer first.
I have't seen that policy, but now that I've read it it seem misguided. My thinking is:
- If the Fedora maintainer cared and there was no technical reason
the branches would already be there.
"Cared"? This is the fundamental problem. Care about what? About making available a package _also_ for EPEL? Or about maintaining it properly and as appropriate for the long life-cycle of the mother product RHEL?
EPEL should not be treated as just another dist target to build for. Don't take it lightly. Don't dump builds into EPEL without considering what may become necessary for future bug-fixes, security- fixes or even back-ports when the build requirements of an upgrade are not met by RHEL.
It is perfectly fine, if someone with special interest in EPEL volunteers as the EPEL package maintainer when the Fedora package maintainer has not created the branches for EPEL before. Be aware of the consequences of offering something for EPEL. It is not easy to make RHEL/EPEL users happy. Those, who are not affected by bugs, don't want version upgrades which may cause regression and new issues. Those, who are affected by bugs, want bug-fixes (which may make version upgrades necessary!). And there are also those, who want always new versions as if it's a drug. Finding existing packages saves them some work, but they don't "care" much, because they build things themselves once the existing packages are out-of-date, and they don't care either whether that may break the dist.
Look, I wholeheartedly agree with all of this. This is why I only take care of just 5 epel branches in the 35 packages that I have some say.
- Most Fedora maintainers know well enough if there is or isn't any
technical reason.
Not sure about that. The type of maintenance which is appropriate for EPEL is underestimated. When you offer something for EPEL, you somehow need to predict whether you will be able to handle security fixes, backports and/or upgrades in the future for a long time.
- "I am too busy and I'll get to it later" - is no good excuse for
blocking people willing to do the work.
True.
Not responding in bugzilla in time is no good excuse either.
- "I beleive this package is not suitable for an LTS release, so
I'll block it" - is just hubris.
True, too. Is there an EPEL project leadership which could review such "decisions"? The opposite, offering something for EPEL only to orphan it some time later, can be considered damaging, too.
- Lets not put red tape for more people to do the work in a place
where good sense should be more than enough to prevent conflict.
Still it's too easy to release packages in the Fedora and EPEL dists and then abandon them without any notification.
What I dislike seeing is for potential contributors to be turned away by our inability to trust them to do the right thing, even if we ourselves can't find the time to do it.
On 09/01/15 08:40, Yanko Kaneti wrote:
- "I beleive this package is not suitable for an LTS release, so I'll
block it" - is just hubris.
There are some fast moving packages out there, which are not suitable for long running releases.
Of course, you're welcome to continue to support them after upstream stopped bug fixing and security fixes. Backporting of bug fixes from newer releases included.
Matthias
devel@lists.stg.fedoraproject.org
-
Dennis Gilmore -
Marianne Lombard -
Matthias Runge -
Michael Schwendt -
Stephen John Smoogen -
Yanko Kaneti