#1756 provenpackager request for junghans
Closed: Invalid 6 years ago Opened 6 years ago by junghans.

I am applying for provenpackager group because I'd like to be able to fix issues related to porting scientific packages to epel7, as I have done recently for the votca-* and gromacs packages.


Sent to sponsors for additional comments.

I support whatever is needed to get the scientific stack in EPEL. junghans is a reasonable guy and nice to work with ;)

Seems there will be enough votes already, but I still would like the request to tell more details. What exactly is meant with "porting packages to epel7"? Modifying Rawhide to add conditionals to spec files? Note that such changes are considered as controversial by many packagers, who prefer a spec file for an EL package to be separate.

EPEL package maintenance is in need of dedicated involvement where volunteers make themselves official package maintainers, bugzilla watchers and POC, especially if bringing more packages to EPEL. That doesn't protected EPEL from people, who turn non-responsive some time in the future, but so far it would be the normal procedure to assign packages to you and get maintainer access to them that way.

Sure, let me explain a bit more. The concrete example, I have in mind is the next version of VOTCA, which will need a more recent hdf5 and hence pull in a whole bunch of version bumps incl. MPI and friends. I am guessing this will take a bit work to get all of them working in EPEL together.

So far, in the process of adding and bumping packages to/in EPEL, I usually email the package maintainers (or now open a pull request on src.fedoraproject.org) to discuss the changes and to get some feedback, leaving them a week or two to respond. (E.g. this is how I became a maintainer for rpms/txt2tags on EPEL7) However, if it is a trivial version bump (no change) or trivial replacement (e.g. %{_pkgdocdir} -> %{_docdir}/%{name}), it would be nice to do it myself if the maintainer is non-responsive or doesn't care about EPEL at all.

Then for the sake of voting, my vote is:

-1

Version bumps in a distribution like EPEL should only be performed by people, who maintain a package officially. If the plan is to upgrade a package in EPEL as needed for new dependencies, acquiring co-maintainer status would be the preferable option. Good communication between existing maintainer(s) and someone, who wants to apply a patch or do an upgrade, is mandatory. You absolutely want to work with other maintainers as a team. There is no thing like a "trivial version bump", because even rebuilding an unchanged package version may lead to breakage because of side-effects, such as rebuilding against changed build requirements. And not even spec file modifications are trivial, if a rebuild is performed.

If a maintainer is non-responsive, start the existing procedure that has been created for non-responsive maintainers. Touching unmaintained packages in a distribution, especially one like EPEL, bears too many risks.

FYI - bumping hdf5 versions in releases is not allowed. The library checks for a difference between the compiled version and linked version and aborts if it's different. I've tried for years to get them to drop this to no avail. First I've heard of the desire to update hdf5 (and I'm the hdf5 maintainer).

(@orion: I should have been more specific, I want szip support (see https://src.fedoraproject.org/rpms/hdf5/pull-request/1), which should be easy to back-port to EPEL7 without an actual version bump.)

So, from needing "a more recent hdf5 and hence pull in a whole bunch of version bumps incl. MPI and friends" you now point at a pull request that's just 5 days old and has been committed to Rawhide quickly and would not need a version bump in EPEL but a patch to backport code support?

You absolutely want to become an active co-maintainer of the EPEL packages you plan to upgrade (or enhance with patches) yourself.

@mschwendt, if you look at the bug referenced in the pull request (#1462443), you will see that the patch was originally proposed and mailed out back in June. Due to a lack of its inclusion (and to make the dependency tree smaller and hence my life easier) , I didn't enable the hdf5 backend in votca-csg when adding it to EPEL7. Thanks to the new src.fedoraproject.org providing pull requests, rpms/hdf5#1 was just another attempt to finally get this feature enabled in hdf5.
Having votca-csg in EPEL7 is already very helpful for many of VOTCA's users, which seem to run RHEL and friends a lot on their cluster, but adding the hdf5 backend with szip compression would be even better. Anyhow, for doing that, together with next version bump of votca-csg, there are still a couple of things (incl. adding libaec itself to EPEL7) left to do.

mailed out back in June.

I've seen the comment in the review request, but such emails are not visible/trackable from the outside, and there is no later comment on whether you've established contact with the maintainers. Have you sent the email in addition to opening a ticket in bugzilla or without doing so?

I truely hope that mailing to the Fedora Project -owner alias addresses is not used as the primary form of communication when trying to contact package maintainers. As much as some people dislike bugzilla, direct email is not superior / not without flaws. The policy for nonresponsive maintainers also strictly requires opening a ticket in bugzilla.

Have you sent the email in addition to opening a ticket in bugzilla or without doing so?

Actually I did:

MIME-Version: 1.0
Received: by 10.74.153.219 with HTTP; Fri, 23 Jun 2017 12:36:24 -0700 (PDT)
X-Originating-IP: [192.12.184.7]
Date: Fri, 23 Jun 2017 13:36:24 -0600
Delivered-To: junghans@votca.org
Message-ID: <CAHG27e5M0kJa7Y8hUYuoCXHE5YFWbwbNxgyQ0kJuZrN8uSSwKQ@mail.gmail.com>
Subject: [PATCH] enable szip support through libaec
From: Christoph Junghans <junghans@votca.org>
To: hdf5-owner@fedoraproject.org

The notes in bugzilla are more for me (and others) to remember what the state is. But email and comments in bugs can easily get overlooked, and hence, the pull requests in src.fedoraproject.org are a nice additional way to contribute.

Actually I did

(sigh) That's not a bugzilla ticket opened against hdf5.

It's been 7 days and I see 4 +1s, but 1 -1... so setting meeting keyword to discuss at the next FESCo meeting.

Metadata Update from @kevin:
- Issue tagged with: meeting

6 years ago

Adding to the meeting agenda for today's (2017-08-18) FESCo meeting at 16:00 UTC. @junghans @mschwendt would be great if you could both join.

I will try my best, but I have a conflicting work meeting.

In the meanwhile, I made some progress by porting libaec to epel7 (see https://src.fedoraproject.org/rpms/libaec/c/d5e64feaddf032f52cd7b96e7d20e0500bf00a1a incl. a small patch, which got upstreamed) and enabling szip in hdf5 on epel7 (see https://src.fedoraproject.org/rpms/hdf5/pull-request/2).

Discussing this outside a time-killing meeting is just fine, IMO.

I don't favor a protectionist approach with regard to packages in the distribution, but suggest people become official maintainers of a package when it comes to doing version upgrades, adding patches and handling problem reports in bugzilla that may be filed as a result. This is alongside the existing policy of who may touch which packages: https://fedoraproject.org/wiki/Provenpackager_policy

Especially if you may need to upgrade/patch such dependencies often, you do want to become an official maintainer instead of doing seemingly random fire'n'forget commits. That would also give you access to the -owner email alias of those packages, for example.
Even from a provenpackager, no patches or changes should be applied without prior communication. And in the case discussed in this ticket, no bugzilla ticket has been opened about the change. Finally, a pull request has been submitted and has been accepted quickly.

About minor "cleanup", adding dist-conditionals to spec files in Rawhide is highly controversial, since not all packagers like EPEL specific stuff in Fedora spec files.

Bringing new packages to EPEL requires packagers to become the official EPEL maintainers. If those new packages depend on something else in EPEL, this is a perfect opportunity for building an official team of maintainers.

We discussed this in the FESCo meeting yesterday.

  • FESCo defers the decision for a week. We'd like to know if it would
    be enough for the requester to be co-maintainer for the packages
    they want to work on or if they have other needs to become a PP.
    (kalev, 16:43:52)

https://meetbot.fedoraproject.org/fedora-meeting/2017-08-18/fesco.2017-08-18-16.00.html

Metadata Update from @maxamillion:
- Issue untagged with: meeting

6 years ago

We discussed this in the FESCo meeting yesterday.

FESCo defers the decision for a week. We'd like to know if it would
be enough for the requester to be co-maintainer for the packages
they want to work on or if they have other needs to become a PP.
(kalev, 16:43:52)

@junghans did you see this question for you?

Since this issue is still waiting on a response regarding co-maintainership, I am not planning to add it to this week's meeting agenda.

@till: Sorry for the late reply, I got swamped with work. As of now, I feel the PR feature of src.fedoraproject.org is all I need to get things moving for EPEL7.

Metadata Update from @junghans:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata