#449 I don't want anyone to commit my packages
Closed None Opened 13 years ago by pnemade.

Hi,
I have already told that ajax is not cleaning up his packages but he is showing proverpackagership by modifying my package. Its just 13 hrs away for me to rebuilding m17n-lib after some broken dep issue reported in bugzilla but he like to touch my package.
If any Fedora policy can help to make my packages only be modified by allowed owners then please do it.
I suppose we are still in F14 Alpha freeze, I wonder how that quick rebuild helped ajax as its still to show in branched f14 report?
Parag.


There is no policy for disallowing provenpackager commits except by specific exception (such as the mozilla trademark issue.) I suppose FESCo can consider this a request for such an exception, but I highly highly doubt you're going to get one.

Ok if no policy there. But good if people will do some discussion on this in meeting. Looks to me violation of proverpackagership where person don't will to commit patch provided in merge review but like to work on others packages.

Another thing, is it ok if I will start working randomly on any bug and fix any package where I can see that person can work on that bug and can fix it easily?

Is Fedora going towards who can work maximum and fix other's packages? :)

NOTE:- I am really confused on such situations so need FESCo to answer on this.

kage review cleanups Parag is referring to are almost purely cosmetic, which is why I haven't been paying attention to them; I have plenty of other things that are more important. I operate on the assumption that the distro as a whole, and the packages therein, are all collectively owned. If Parag feels that I'm not paying attention to cosmetic fixes to my own packages, he is welcome and encouraged to fix them for me. Back when cvsextras existed, the X packages were all cvsextras+ for exactly this reason.

The change I made to m17n-lib fixed an upgrade path issue from F13:

http://pkgs.fedoraproject.org/gitweb/?p=m17n-lib.git;a=commitdiff;h=66d1541ab0ade0b5ae0341eef6cd013470823c8b

This was a bug with a trivial fix, and it was in the way of me doing other work (updating the laptop to F14 so I could test it), so I fixed it as a drive-by cleanup. I believe my fix was correct, and in line with the obsoletion conventions in the packaging guidelines:

http://fedoraproject.org/wiki/PackageNamingGuidelines#Renaming.2Freplacing_existing_packages

I believe this action is in keeping both with my above assumption of collective ownership, and with the established provenpackager policy:

http://fedoraproject.org/wiki/Provenpackager_policy

However, I do apologize for not searching bugzilla for any existing open tickets on the matter and closing them out after this change.

As a fesco member I must naturally recuse myself from any vote or decision on this matter.

I really can't see how there's any wrongdoing here - it looks as if ajax fixed a legitimate bug that was causing failures on upgrade. It would be nice to also get package reviews sorted out, but that's an unrelated issue to fixing some other package.

I agree changes I used to suggest on some packages are cosmetics but if Fedora also says we need reviewers to fix merge-review packages and I am doing my best to help Fedora by providing patches then I think I certainly expect maintainer to reply me by either committing changes or saying in comment "this package can be fixed by any provenpackager"

Seems FESCo really need to work on good policy for merge-reviews where maintainers are busy and reviewers want to help to fix packages.

Replying to [comment:4 pjones]:

I really can't see how there's any wrongdoing here - it looks as if ajax fixed a legitimate bug that was causing failures on upgrade. It would be nice to also get package reviews sorted out, but that's an unrelated issue to fixing some other package.

Issue is how much freedom one can expect with provenpackagership? how much one can wait before using his proverpackage power?

I really wonder why you said in FESCo meeting that merge-reviews are "giant waste of time". Why don't then close merge-reviews without any reviews?

Replying to [comment:5 pnemade]:

I agree changes I used to suggest on some packages are cosmetics but if Fedora also says we need reviewers to fix merge-review packages and I am doing my best to help Fedora by providing patches then I think I certainly expect maintainer to reply me by either committing changes or saying in comment "this package can be fixed by any provenpackager"

I don't think that's how it works. Any provenpackager can fix any package they want. That's the whole point: by granting someone provenpackager status we are saying they have proven themselves to be capable and responsible packagers and we trust their ability to do good work of their own volition.

In your particular case, I'm almost certain I've told you before that you can commit merge review cleanups without needing my approval. libX11, for example.

Seems FESCo really need to work on good policy for merge-reviews where maintainers are busy and reviewers want to help to fix packages.

We addressed this in the last meeting, in response to ticket #448 (which you filed). See the discussion:

http://meetbot.fedoraproject.org/fedora-meeting/2010-08-10/fesco.2010-08-10-19.30.log.html#l-93

And the conclusion:

http://meetbot.fedoraproject.org/fedora-meeting/2010-08-10/fesco.2010-08-10-19.30.log.html#l-156

There was some debate on the devel list about whether the "reviewer != committer" restriction was necessary. I don't think it is necessary.

ok, so where are we here?

Personally I would say:

  • You can ask for your package(s) to be closed to provenpackager commits. I would vote against such an exception based on what I know now.

  • I think we should revisit our discussion from last week, and make clear that:

a) If you are a reviewer in a merge review, and are a provenpackager, and the packager says "go head and commit your changes", that should be just fine.

b) You are a reviewer in a merge review, and the packager doesn't respond at all to that merge review, you should not commit changes, and instead should have another provenpackager review and commit them. They can then finish the review with you if they solve all issues outstanding in the merge review.

Thoughts? Anything further to clarify? Anything further to act on in this ticket?

I think we are dealing with two different problems here:
1. People are not paying much attention to the merge reviews. This is a bad thing and we should work on fixing it.
1. Proven packagers are allowed to touch every package in order to fix bugs. Some maintainers don't like that.

Just because ajax is both a proven packager and owner of packages that are under merge review, this doesn't mean these problems are related. IMHO he did the right thing.

Ok. So overall what I got from above discussion is that, proverpackagers are free to jump any package bugs and fix packages without looking who is its maintainer and whether maintainer is alive or not to fix them.

Is above correct?

We agreed in the 2010-08-17 meeting that no exception should be granted here for provenpackager commits. We also clarified the provenpackager and merge reviews process.

Feel free to re-open if there are further items to address here.

Login to comment on this ticket.

Metadata