Package Change Request

I would note the following points in my own defense here:

• The Fedora Perl Community is very open about permitting other people to work on perl packages in Fedora.
• I added these requests because I needed these perl modules to be built for active Fedora targets so that I could add a new, dependent, perl module to upgrade another one of my perl modules.
• These perl package review requests were all done without branching for ANY active Fedora branches (just rawhide), which I feel is inappropriate behavior for a package maintainer unless there is a technical reason preventing the maintainer from releasing a new package on that active Fedora branch. In fact, I thought that this lack of branching was the mistake of a new packager rather than conscious abandonment, which is why I requested branches with identical ownership, instead of simply taking ownership for myself.
• There were no technical reasons preventing these perl modules from being maintained in active Fedora branches. I did straight rebuilds with no modifications.
• The owners were all CC'd on the bugzilla ticket and received notification of the branching request and approvals.
• There is no policy stating that newly reviewed packages may not be released into stable branches, or even any policy discouraging this, which makes the original behavior of the packager to release these packages into rawhide only very confusing.

I'd note for clarification that technically as a member of Rel-Eng, I could have processed my own requests here, but I was not acting in that capacity in these cases (3 total).

I'm not sure I understand the big deal here...

If spot had asked you to branch and maintain these packages for the other releases, what would your answer have been?

if you did not want to maintain those packages for those releases, would you have been ok with spot owning them?

...cannot even be sure which branches their packages exist and which they are responsible for...

Wouldn't you know this from multiple places?

The big deal is rel-eng processed request from person who is not in ACL role for the package. This way anybody can change packages in package database.

The What I would if spot had question is irrelevant.

ok, FWIW, I would be fine with a check on scm requests that they come from someone with the acls for the affected package.

I am a little leary of this. there are definitely cases where it wouldbe time consuming to require that all requests must come from an acl holder. just as one example, when someone leaves red hat, it is common for their manager or their manager via spot to let us know that package ownership should change. with this rule we'd either need to wait out the non-responsive maintainer time period or write a red hat specific exception.

in the specific case of adding branches, I wonder what we are protecting against. we have been trying (sometimes with less success than others) to get package maintainers to think less about owning a package and more about being part of a team that builds fedora together. I think trying to lock down who can make acl requests too much might be a step away from this goal.

if we have very few solid problems with the current openness it might be better to stick with an ask forgiveness instead of permission policy.

Perl SIG has each year problem with obviously dead packages which cannot be blocked by SIG because only maintainer can do it. Half year unresponsive maintainer process for Fedora releasing each half year is unfeasible. Does it mean rules do not apply to spot?

I think the problem is unresponsive process does not work. Not ACLs.

In general I'm not against weakening ACL institute, but then responsibility must come with power. In this case spot had to test, merge, and build the packages in the new branches. Not only create branches and hoping somebody else finishes the work.

However we have ACLs now, so we should use them now.

I will add most of the people the process the git request queue are not actually part of releng.

I'm curious who is responsible for git request queue. If neither releng nor fesco, then who?

Members of the cvsadmin group, there are currently 13 members, but it's mostly myself and tibbs that process the queue these days, unless I'm mistaken.

I don't think that this is a good thing. There are a few packages that I maintain in EPEL, and someone else maintains them in Fedora proper. Generally, I'll ask the maintainer if they would care if I maintain them in EPEL, but that communication happens generally via private email, we come an agreement, I make an SCM request, and voila. things get done.

Instituting a policy like this would require more bureaucracy on the part of the maintainer in Fedora, who generally doesn't want to be involved in EPEL.

imho, requiring a documented blessing from pkg maintainers is a "good thing(tm)", just not sure if there's any good and practical way to implement it and agree with jstanley's concerns about adding undue bureaucracy burdens.

Replying to [comment:11 rdieter]:

imho, requiring a documented blessing from pkg maintainers is a "good thing(tm)", just not sure if there's any good and practical way to implement it and agree with jstanley's concerns about adding undue bureaucracy burdens.

The maintainer should get bugmail if someone submits a new SCM request in the review bug, right? If so, just have people wait for an Ack comment to the new SCM request.

Replying to [comment:10 jstanley]:

There are a few packages that I maintain in EPEL, and someone else maintains them in Fedora proper. Generally, I'll ask the maintainer if they would care if I maintain them in EPEL, but that communication happens generally via private email, we come an agreement, I make an SCM request, and voila. things get done.

That's different case. In your scenario I do not demand master branch owner permission because the requested branch will not affect master owner.

To be more explicit: There is problem somebody can make you owner of a branch without your approval. E.g. you would like an EPEL branch, so you would requested new EPEL branch to be owned by master branch owner. Without his/her approval.

Replying to [comment:13 ppisar]:

To be more explicit: There is problem somebody can make you owner of a branch without your approval. E.g. you would like an EPEL branch, so you would requested new EPEL branch to be owned by master branch owner. Without his/her approval.

If someone made you owner of a branch without your consent, you can just orphan it.

It was discussed during the current meeting. This task is not within relengs domain and the situation is not considered to require changes. Meeting logs will be in

http://meetbot.fedoraproject.org/teams/releng/

probably at

http://meetbot.fedoraproject.org/teams/releng/releng.2014-01-06-16.29.html

If I read the log correctly, only following lines deal this issue:

{{{
16:40:06 <tilldroid> 5418
16:40:32 <tilldroid> Imho it should be closed wontfix
16:40:45 <dgilmore> tilldroid: thats really not a releng thing as we dont process the scm queue
16:41:10 <dgilmore> the processing of the queue is kind off a strange area though
16:41:21 <tilldroid> So it can be forwarded to fesco?
16:41:22 <dgilmore> ~there is a few people that have been doing it forever
16:41:46 <dgilmore> i honestly think we should just close it cantfix
16:41:58 <dgilmore> and there is nothing to do
16:42:33 <dgilmore> not sure why that ticket did not show up in the meeting report
}}}

I thought that rel-engs process SCM requests. I'm going to forward it to FESCo because somebody has to be responsible.

Actually this request was reported here based on FESCo decision. I will try Fedora Infrastructure which seems to be more appropriate. Moving to [https://fedorahosted.org/fedora-infrastructure/ticket/4166].