#1231 Provenpackager request: averi
Closed None Opened 10 years ago by averi.

Hi,

I'm currently interested in applying for the provenpackager group mainly for not having to bother people with very minor changes I have to apply on the good bunch of perl packages I maintain on both EPEL and Fedora when I need a rebuild or a little change that affects one of the packages I maintain. Patrick Uiterwijk and Kevin Fenzi are my current sponsors for the following request.

I'm currently maintainting a total of 51 packages. [1]

[1] https://admin.fedoraproject.org/pkgdb/users/packages/averi


+1 from me. Averi has always been a good packager and would make a good provenpackager.

+1 from me as well. I second Kevin on this.

+1 from me, Averi's package ownership shows experience in the package category he intends to apply his provenpackager status to.

Ralf, would you mind clarifying your rationale? The only thing I see there is a package that failed to build because it was missing dependencies in the buildroot.

@corsepiu: one of the packages I maintain requires perl-Plack to build and given I have no access to that package, I did request the EL7 branch and tried a test build given my mock EPEL7 chroot is missing a lot of dependencies while koji is up-to-date with the latest packages introduced.

That way, if the build fails like in this case, I just check the log and request the missing dependencies and build them.

Maybe what Ralf's implying is that the Koji build for EPEL 7 should have been a scratch build rather than a real build. IMHO it's generally better to do local mock builds or at least scratch builds when testing dependencies so it's clearer to everyone about what your intentions are.

I am wondering about the statement "my mock EPEL7 chroot is missing a lot of dependencies". Why is that?

@ktdreyer: I've been test-building on EPEL 7 with mock since the very first day EL7 was opened for packages inclusion and the result (in terms of missing dependencies) was different between the mock build and the koji build. It might well be it was a temporary issue but since then I found building directly on koji the best way for the test-builds to take the very latest packages included.

While I agree going with a scratch build can also do the job when testing dependencies, I definitely don't see the point in censoring the use of normal builds for testing dependencies, if the package fails to build a log is generated and provided and the package is obviously not included into the relevant target suite. Again, going for a "normal" build doesn't take in any harm nor is defined as a "bad" practice on the packaging documentation.

The wiki page at [1] says "Sometimes it is useful to be able to build a package against the buildroot but without actually including it in the release", but if the package FTBFS the package is not included at all into the target release, thus doing a "normal" build and see it failing is the equiv of doing a scratch build given the final result is the package not being included at all into the target release.

Again, I don't see any issue with this practice even in terms of resources used on the server-side. Both "normal" and "scratch" builds happen through koji, so even arguing that doing a "normal" build could waste some of the resources that could be used for more important builds don't make sense.

[1] http://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds

@averi: My point is that using scratch builds clarifies your intentions to the other people in Fedora. When you kick off a normal build and it fails, other people will see it and not know whether it's was innocent experiment or a more serious mistake. When it's a stable branch like EPEL, it's all the more confusing.

Using a scratch build adds the contextual clue that it was a test.

Don't worry, I'm not voting against you, and it looks like you'll get enough votes to make it :) I'm just trying to explain how communication could be even better.

@ktdreyer: I see your point and agree that this should be avoided on a "stable" branch, EPEL 7 is currently a beta branch that gets rebuilt when a new build actually succeeds, so no epel-testing update request, 14 days for the epel-testing branch to become mature and eventual push to epel-stable. As stated by Dennis at [1] the EPEL 7 branch is currently working as rawhide does, thus its nature of 'testing' branch.

But again I definitely see what's your point and will start doing scratch builds even for non-stable branches as you suggest to avoid any misunderstanding between contributors.

[1] https://lists.fedoraproject.org/pipermail/devel/2014-January/193749.html

Since there is one negative vote, moving to a meeting item.

At today's FESCo meeting we voted:

  • averi approved as a provenpackager (+1:7, 0:1, -1:0) (abadger1999,
    19:13:31)

Congratulations, I've added you to provenpackager. Go forth and use your powers for good.

Login to comment on this ticket.

Metadata