Replying to [ticket:715 kevin]:

We may want to look at better education of, or pruning of the provenpackager ranks.

This yum commit today:
http://lists.fedoraproject.org/pipermail/scm-commits/2011-December/693055.html

This is just a continuation of my previous patch on spec file:
http://lists.fedoraproject.org/pipermail/scm-commits/2011-December/692836.html

was unfortunate for a number of reasons:

• No communication with package maintainers (who are quite active).

See BZ#750859. It is a known bug.

2011-11-02 11:28:52 EDT - 37 days ago - bug reported
2011-11-18 05:59:55 EST - 21 days ago - patch available
2011-11-30 00:27:35 EST - 9 days ago - ping, help please request
2011-12-09 14:21:15 EST - - my build

Why do you think, 37 days without any response is an "quite active" user?

• Only commiting to the f16 branch, where the bug my affect master/other branches and may cause history issues when merging.

I can merge it in master too. But I think, maintainer will fix this better way upstream
in any new versions. I just need to fix it for users of stable release.

• Uploading a patch to the lookaside cache instead of checking it in. (Makes me wonder if they were trying to 'hide' the contents of the patch at a first glance).

No. I just forgot to upload a patch with spec change. This is what I done:

edit yum.spec (add patch, changelog, increase release)
fedpkg commit & push
fedpkg build (failed, no patch found)
fedpkg upload yum-silence.patch
fedpkg build (done)

What's wrong here? Is it better to build an srpm and import it? Why there is an "fedpkg upload" option available?

Replying to [comment:1 ondrejj]:

See BZ#750859. It is a known bug.

2011-11-02 11:28:52 EDT - 37 days ago - bug reported
2011-11-18 05:59:55 EST - 21 days ago - patch available
2011-11-30 00:27:35 EST - 9 days ago - ping, help please request
2011-12-09 14:21:15 EST - - my build

Why do you think, 37 days without any response is an "quite active" user?

Well, there are around 200 open yum bugs currently.
I can't say why there wasn't a specific comment there, but it could have been it was low priority, they were working on a better/cleaner/more supportable fix, it was related to some other issue they needed to fix first, or they simply didn't have time.

I can merge it in master too. But I think, maintainer will fix this better way upstream
in any new versions. I just need to fix it for users of stable release.

Sure, but perhaps this fix is soon to land on stable releases as well?
(I don't know the yum maintainers schedule of such things, which is why it's good to ask them).

• Uploading a patch to the lookaside cache instead of checking it in. (Makes me wonder if they were trying to 'hide' the contents of the patch at a first glance).

No. I just forgot to upload a patch with spec change. This is what I done:

edit yum.spec (add patch, changelog, increase release)
fedpkg commit & push
fedpkg build (failed, no patch found)
fedpkg upload yum-silence.patch
fedpkg build (done)

What's wrong here? Is it better to build an srpm and import it? Why there is an "fedpkg upload" option available?

You should not upload it. You should just 'git add yum-silence.patch' then 'fedpkg commit -p' and then build again. Patches should be in git so they are more visible, as well as in the git history, as well as seen on the commits list/commits to maintainers.

Replying to [comment:2 kevin]:

Replying to [comment:1 ondrejj]:

Well, there are around 200 open yum bugs currently.
I can't say why there wasn't a specific comment there, but it could have been it was low priority, they were working on a better/cleaner/more supportable fix, it was related to some other issue they needed to fix first, or they simply didn't have time.

And what's wrong, that I helped him to fix this problem? Even if maintainer will fix it other way, this temporary fix will be available until it fixes it other way.

I can merge it in master too. But I think, maintainer will fix this better way upstream
in any new versions. I just need to fix it for users of stable release.

Sure, but perhaps this fix is soon to land on stable releases as well?
(I don't know the yum maintainers schedule of such things, which is why it's good to ask them).

This or other fix will go to stable.
How to ask? We asked him through bugzilla. No reply.

Btw, is it true, that if maintainer works on bug, he should set bug status to "assigned"?
And may be maintainer should say something to bug comment. Then each packager will know, it's working on it.

You should not upload it. You should just 'git add yum-silence.patch' then 'fedpkg commit -p' and then build again. Patches should be in git so they are more visible, as well as in the git history, as well as seen on the commits list/commits to maintainers.

I think fedpkg upload added it to git too.
Maybe "fedpkg upload" should be removed from fedpkg (or it's help) if it should not be used.

I have to say that there are some merits on the points of the both sides here.

1. I'd really expect yum maintainers to at least say something on such a bug report. And as there was no response as in this case I'd really allow provenpackagers to act.

but on the other hand

1. I'd really expect provenpackagers to know that patches have to be added and committed to the git repository directly instead of fedpkg uploading them to the lookaside cache. This action does not really add confidence in a provenpackager that does it.

and

1. And Kevin, please, "Never ascribe to malice that which is adequately explained by incompetence".

I agree with comment 4 by tmraz.

Maybe ondrejj should look into making his own yum repository for the computers he's maintaining.

FWIW it's not like I hated the update, or help in general, if so I'd have tried to stop the update instead of just questioning it. My main annoyances/concerns were:

1. I'd kind of assume someone would ping the yum-owner@ address, before creating an update (or use the bots and ping someone on IRC). Even a comment in the BZ saying "this seems like a simple cosmetic fix, but is negatively impacting me and a number of other users, so I'm going to do a backport for F16 in N days unless a maintainer speaks up" would have worked (obviously given the 100s of BZ emails I get a week, I'd much prefer something direct).
   The fact that this was yum, and not some random package heightened my concern.

2. The fact that the proven packager used upload for the patch, which I'd never seen done before, then set off lots of mental alarm bells.

I'd like to note that I am not accusing anyone of malice here. I was just suggesting that uploading patches to the lookaside could be seen as a way to try and bypass easy review in the scm list or with maintainers.

I just want to improve communication and process here so it goes better next time. ;)

So it seems like there's a couple issues here:

There was definitely a lack of communication here. Maybe this could be alleviated if expectations were more clear about how much effort and in what ways provenpackagers should try to reach maintainers:

• What channels should a provenpackager take to communicate with a maintainer (IRC, direct email, etc)?
• If a maintainer does not communicate with a provenpackager, is there other due diligence that a provenpackager should take (looking at times in the package commit log? Looking for other commits/bug reports answered by the packager?)
• Does a provenpackager need to get sign off from a maintainer in case that maintainer does appear to be active by one of these other means of looking?
• Perhaps the last step on a bug should simply be the provenpackager asking for permission to apply a patch and without explicit permission, they'll assume silence is consent to make a build at X date.
• If a provenpackager commits a patch to our package, does that put them on the hook to communicate that patch with upstream?

(note: these questions are supplemental to the http://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages . There is some guidance there already about types of changes that wouldn't need explicit communication between provenpackager and maintainer. This bug fix doesn't seem to fit the existing criteria there. This is trying to establish some expectations on how provenpackagers should go about fixing bugs in packages that aren't critical or security bugs and also aren't part of a mass cleanup effort.)

The other half is that ondrejj doesn't appear to have a "provenpackager level" understanding of how to use the current Fedora packaging tools or workflow. The particular pieces that I see there are:
* Not knowing how to use fedpkg. Perhaps understandable that someone who came from the fedora-cvs time period would not understand precisely how fedpkg and git interact. But -- we definitely want those people to be educated on those tools.
* Not applying the change to the master branch as well as the F16 branch. This one is a little tricky as a few packages (glibc springs to mind) use the latest released Fedora for their builds and then depend on koji inheritance to propagate them to the rawhide branch. ausil has talked about breaking koji inheritance when the new release is branched from rawhide which would make this unambiguous. For now, whether an f17 build has been performed can be looked up in koji.
* Not making a better effort to contact the maintainers. I would speculate that most provenpackagers have read the Nonresponsive maintainers guide[1]_ and try a few of those alternate contact methods before pushing changes as it's the most complete guidance for dealing with maintainers not responding to bug reports. Given that we want to encourage provenpackagers to "just fix things" more often (at least, that was the sentiment during dwmw2's tenure on FESCo and I haven't seen it changed since), it's probably best to explicitly document some of the thoughts about communication mentioned above into http://fedoraproject.org/wiki/Provenpackager_policy . For now, ondrejj could read the Non-responsive maintainers guide for ideas of other methods of communication to try.

.. [1]_: http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

I don't know if there should be a mass education effort for provenpackagers on any of the above points or if the ideas are fairly well known in general (they seem so to me but then, I wouldn't have expected any provenpackager to not understand them).

Replying to [comment:8 toshio]:

• Not applying the change to the master branch as well as the F16 branch. This one is a little tricky as a few packages (glibc springs to mind) use the latest released Fedora for their builds and then depend on koji inheritance to propagate them to the rawhide branch.

Just by way of clarification, glibc is no longer doing this. The maintainer has agreed to do development work in rawhide, and only pull patches into released versions.

Replying to [comment:9 jsmith]:

Just by way of clarification, glibc is no longer doing this. The maintainer has agreed to do development work in rawhide, and only pull patches into released versions.

jsmith and I compared notes -- the glibc maintainer has agreed to do development in rawhide but the builds by the current maintainer are still for F16, not F17. OTOH, the former glibc maintainer broke inheritance a long time ago (by tagging F16 builds into rawhide) so my point about the maintainer of the glibc package depending on inheritance and a provenpackager potentially breaking it would have been wrong here.

ondrejj, the fedpkg upload is useful for uploading the tarballs and other files that should be put in the lookaside cache. So it cannot be removed.

The patches and other textual files should be put into the GIT repository directly by 'git add'.

Decided at 2012-12-12 FESCo Meeting: process is sufficient as-is. FESCo will address issues on a case-by-case basis.