Re: Dealing with the "my packages" problem
On Sun, Nov 29, 2015 at 7:00 PM, Nico Kadel-Garcia wrote: > > On Wed, Nov 18, 2015 at 4:49 PM, Adam Williamson > wrote: > > > Just as a general note on this thread: if you're a packager and you > > have a genuine reason why people should be careful about touching your > > package, or follow some specific process when doing so, or there's > > something that people might think they should change but they > > shouldn't, there is already a pretty effective way of dealing with > > this: > > > > ** PUT A COMMENT IN THE SPEC FILE ** > > > > this is extremely easy to do, and extremely difficult for anyone who > > touches it to claim they didn't see. > > I know this thread is a bit old, but thought I'd add a note when I > checked my backlog and saw it. > > A comment in the code accompanying the change itself can also be > invaluable, especially for changes that should propagate upstream.I > cannot count the number of patches that have *nothing* in the patch > content, only in the comments preceding the patch itself. I'm > personally exhausted with people who refuse to document, whose API has > to be deduced from the code, and especially whose code could fit > *mutliple* workflows. And worse, when the API they think they're using > isn't the one they've actually written, and they get upset when you > don't code to this non-published API. > > That's cost me a job I rather liked. > > > Package builds in a community distro are really just like F/OSS code: > > you should assume other people are going to be looking at it and poking > > it and trying to do stuff with it, and any time it's doing something > > that isn't extremely obvious or diverges from the general conventions, > > it makes sense to comment it. > > Yes, lordie, please, "the code is the documentation" is an attitude > I've encountered far, far too often, and I consider it the sign of a > dangerous programmer. It's afraid it's a job security thing: by > refusing to document you protect your turf. > I'd like to add to this by pleading to *not* strip the comment section out of a patch/diff when you pull them from upstream/git/pull requests/etc. git format-patch is your friend in the Gitverse, and similar tools exist across all major SCM systems. Maybe it's because some people don't know about -p1 or something, but I've seen people strip and partially rewrite patches in the past so that they would apply. I was also guilty of this before I figured out how to use %patch and later learned of %autosetup/%autopatch, so I don't know if it's because people have issues with that or something else. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Dealing with the "my packages" problem
On Wed, Nov 18, 2015 at 4:49 PM, Adam Williamson wrote: > Just as a general note on this thread: if you're a packager and you > have a genuine reason why people should be careful about touching your > package, or follow some specific process when doing so, or there's > something that people might think they should change but they > shouldn't, there is already a pretty effective way of dealing with > this: > > ** PUT A COMMENT IN THE SPEC FILE ** > > this is extremely easy to do, and extremely difficult for anyone who > touches it to claim they didn't see. I know this thread is a bit old, but thought I'd add a note when I checked my backlog and saw it. A comment in the code accompanying the change itself can also be invaluable, especially for changes that should propagate upstream.I cannot count the number of patches that have *nothing* in the patch content, only in the comments preceding the patch itself. I'm personally exhausted with people who refuse to document, whose API has to be deduced from the code, and especially whose code could fit *mutliple* workflows. And worse, when the API they think they're using isn't the one they've actually written, and they get upset when you don't code to this non-published API. That's cost me a job I rather liked. > Package builds in a community distro are really just like F/OSS code: > you should assume other people are going to be looking at it and poking > it and trying to do stuff with it, and any time it's doing something > that isn't extremely obvious or diverges from the general conventions, > it makes sense to comment it. Yes, lordie, please, "the code is the documentation" is an attitude I've encountered far, far too often, and I consider it the sign of a dangerous programmer. It's afraid it's a job security thing: by refusing to document you protect your turf. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Dealing with the "my packages" problem
19.11.2015 14:35, Tomas Mraz пишет: On Čt, 2015-11-19 at 11:06 +0100, Martin Kolman wrote: On Wed, 2015-11-18 at 16:39 -0500, David Airlie wrote: - Original Message - From: "Brian C. Lane" To: devel@lists.fedoraproject.org Sent: Thursday, 19 November, 2015 7:05:57 AM Subject: Re: Dealing with the "my packages" problem On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote: Matthew Miller wrote: On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: After some IRC discussion I've come to the following proposal: that maintainers have some way to easily indicate how open they are to external contributions. Basically this would take the form of a few options in pkgdb where maintainers can indicate their willingness to have provenpackagers carry out a few actions. Please read the github ticket for details: https://github.com/fedora-infra/pkgdb2/issues/274 What if we made the options be about _the package_ rather than about the maintainer's prickliness? Rather than "Please don't touch my package" (I know that's not your wording; added for emphasis) make it "This package has unusual complications; please coordinate any changes with the package maintainers." Well, except, less wordy. :) And, in thinking about it, I don't think we should encourage the option of "Don't even ask". If there really _is_ something that's a big deal, the package maintainer can always say no when asked. As one of the complainers about current policy, here are my thoughts. I appreciate tibbs bringing up the discussion. I'd vote for a default stance of "Ask first." I don't think we need a technical solution, we just need the people who feel the need to modify packages they aren't normally involved with to ask first. It doesn't matter how simple or complicated the change is, just be polite. But that doesn't scale. I think it can be made to scale - at least in most cases. We could have a mechanism that stages the change and notifies the maintainer (eq. asks first automatically) and gives him the option to apply the change or cancel it & do it properly themselves. And if there is no reply from the maintainer, the change will be applied automatically after some time (24-48 hours ? could be configurable). I think this workflow would lessen the burden for both parties involved: * less work for proven packagers when "doing it right" (automatic asking, staging & auto apply) * maintainers get always notified automatically, can easily "ACK" trivial changes or cancel the change and do it properly if needed Yes, this would be almost perfect. If we can get such staging branches to be automatically merged or merge canceled by the package owner to work. It also needs a little cultural change but it should not be a drastic change. Of course this should not encourage provenpackagers to hastily produce incorrect changes and just depending on the review of the owner. We could also have a branch for regular packagers not provenpackagers working in similar way but it would not be merged automatically but only when the owner explicitly say so. You can probably already use private branches for that but it is missing some automation and official workflow definition. Something like gitlab for our packages? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Dealing with the "my packages" problem
On Thu, Nov 19, 2015 at 07:19:13AM -0600, Michael Catanzaro wrote: > But this could still be a great feature, provided we extend the service > to non-provenpackagers. If any old Joe could offer submit requests to > packages, as is already the case in openSUSE, that would be huge in > terms of building the community of Fedora package maintainers. Pingou has talked about moving dist-git to Pagure. At that point, this could be done as pull requests. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Thu, Nov 19, 2015 at 9:44 AM, Orion Poplawski wrote: > On 11/18/2015 02:49 PM, Adam Williamson wrote: >> >> Just as a general note on this thread: if you're a packager and you >> have a genuine reason why people should be careful about touching your >> package, or follow some specific process when doing so, or there's >> something that people might think they should change but they >> shouldn't, there is already a pretty effective way of dealing with >> this: >> >> ** PUT A COMMENT IN THE SPEC FILE ** >> >> this is extremely easy to do, and extremely difficult for anyone who >> touches it to claim they didn't see. > > > I like this and think it covers this issue pretty well. Coupled with a much > needed "get over it - it's not *your* package" attitude shift. > +1, also good git commit logs are helpful in addition to inline comments. I also think it'd be easier to suggest changes to maintainers if we had a good pull request system (I know it's been suggested before... possibly by using mirrors on GitHub) to deal with the occasional one-off drive-by fix. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On 11/18/2015 02:49 PM, Adam Williamson wrote: Just as a general note on this thread: if you're a packager and you have a genuine reason why people should be careful about touching your package, or follow some specific process when doing so, or there's something that people might think they should change but they shouldn't, there is already a pretty effective way of dealing with this: ** PUT A COMMENT IN THE SPEC FILE ** this is extremely easy to do, and extremely difficult for anyone who touches it to claim they didn't see. I like this and think it covers this issue pretty well. Coupled with a much needed "get over it - it's not *your* package" attitude shift. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Thu, 2015-11-19 at 11:06 +0100, Martin Kolman wrote: > We could have a mechanism that stages the change and notifies the > maintainer (eq. asks first automatically) and gives him the option to > apply the change or cancel it & do it properly themselves. At this point we are overengineering. It's rare that a provenpackager touches your package. It's not a big deal when somebody does; just revert the change if you don't like it. But this could still be a great feature, provided we extend the service to non-provenpackagers. If any old Joe could offer submit requests to packages, as is already the case in openSUSE, that would be huge in terms of building the community of Fedora package maintainers. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Čt, 2015-11-19 at 11:06 +0100, Martin Kolman wrote: > On Wed, 2015-11-18 at 16:39 -0500, David Airlie wrote: > > > > - Original Message - > > > From: "Brian C. Lane" > > > To: devel@lists.fedoraproject.org > > > Sent: Thursday, 19 November, 2015 7:05:57 AM > > > Subject: Re: Dealing with the "my packages" problem > > > > > > On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote: > > > > Matthew Miller wrote: > > > > > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III > > > > > wrote: > > > > > > After some IRC discussion I've come to the following > > > > > > proposal: that > > > > > > maintainers have some way to easily indicate how open they > > > > > > are to > > > > > > external contributions. Basically this would take the form > > > > > > of a few > > > > > > options in pkgdb where maintainers can indicate their > > > > > > willingness to > > > > > > have provenpackagers carry out a few actions. Please read > > > > > > the github > > > > > > ticket for details: > > > > > > https://github.com/fedora-infra/pkgdb2/issues/274 > > > > > > > > > > What if we made the options be about _the package_ rather than > > > > > about > > > > > the maintainer's prickliness? Rather than "Please don't touch > > > > > my > > > > > package" (I know that's not your wording; added for emphasis) > > > > > make it > > > > > "This package has unusual complications; please coordinate any > > > > > changes > > > > > with the package maintainers." > > > > > > > > > > Well, except, less wordy. :) > > > > > > > > > > And, in thinking about it, I don't think we should encourage > > > > > the > > > > > option of "Don't even ask". If there really _is_ something > > > > > that's a big > > > > > deal, the package maintainer can always say no when asked. > > > > > > > > > > > > > As one of the complainers about current policy, here are my > > > > thoughts. > > > > > > > > I appreciate tibbs bringing up the discussion. I'd vote for a > > > > default > > > > stance of "Ask first." > > > > > > I don't think we need a technical solution, we just need the people > > > who > > > feel the need to modify packages they aren't normally involved with > > > to > > > ask first. It doesn't matter how simple or complicated the change > > > is, > > > just be polite. > > > > But that doesn't scale. > I think it can be made to scale - at least in most cases. > > We could have a mechanism that stages the change and notifies the > maintainer (eq. asks first automatically) and gives him the option to > apply the change or cancel it & do it properly themselves. > > And if there is no reply from the maintainer, the change will be > applied automatically after some time (24-48 hours ? could be > configurable). > > I think this workflow would lessen the burden for both parties > involved: > * less work for proven packagers when "doing it right" > (automatic asking, staging & auto apply) > * maintainers get always notified automatically, can easily > "ACK" trivial changes or cancel the change and do it properly > if needed Yes, this would be almost perfect. If we can get such staging branches to be automatically merged or merge canceled by the package owner to work. It also needs a little cultural change but it should not be a drastic change. Of course this should not encourage provenpackagers to hastily produce incorrect changes and just depending on the review of the owner. We could also have a branch for regular packagers not provenpackagers working in similar way but it would not be merged automatically but only when the owner explicitly say so. You can probably already use private branches for that but it is missing some automation and official workflow definition. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Wed, 18 Nov 2015 17:23:09 -0500, Rob Crittenden wrote: > I also wonder if I revert a provenpackager change, is that the end of > it? Who is the arbiter in this case if not? It would be necessary to understand why there's disagreement about how to package something. Has there been contact between the provenpackager and the package "owners" before touching the package? What has been the outcome? Perhaps it has been one of the infamous cases of ignoring a bugzilla ticket for months? Over the last years there have been several examples of package "owners" reverting changes to their packages either unknowingly or out of ignorance, dumping spec file updates into git without paying attention to previous commits and the related generated diffs. This has lead to reverting actual fixes as well as general minor cleanup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Wed, 2015-11-18 at 16:39 -0500, David Airlie wrote: > > - Original Message - > > From: "Brian C. Lane" > > To: devel@lists.fedoraproject.org > > Sent: Thursday, 19 November, 2015 7:05:57 AM > > Subject: Re: Dealing with the "my packages" problem > > > > On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote: > > > Matthew Miller wrote: > > > > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III > > > > wrote: > > > > > After some IRC discussion I've come to the following > > > > > proposal: that > > > > > maintainers have some way to easily indicate how open they > > > > > are to > > > > > external contributions. Basically this would take the form > > > > > of a few > > > > > options in pkgdb where maintainers can indicate their > > > > > willingness to > > > > > have provenpackagers carry out a few actions. Please read > > > > > the github > > > > > ticket for details: > > > > > https://github.com/fedora-infra/pkgdb2/issues/274 > > > > > > > > What if we made the options be about _the package_ rather than > > > > about > > > > the maintainer's prickliness? Rather than "Please don't touch > > > > my > > > > package" (I know that's not your wording; added for emphasis) > > > > make it > > > > "This package has unusual complications; please coordinate any > > > > changes > > > > with the package maintainers." > > > > > > > > Well, except, less wordy. :) > > > > > > > > And, in thinking about it, I don't think we should encourage > > > > the > > > > option of "Don't even ask". If there really _is_ something > > > > that's a big > > > > deal, the package maintainer can always say no when asked. > > > > > > > > > > As one of the complainers about current policy, here are my > > > thoughts. > > > > > > I appreciate tibbs bringing up the discussion. I'd vote for a > > > default > > > stance of "Ask first." > > > > I don't think we need a technical solution, we just need the people > > who > > feel the need to modify packages they aren't normally involved with > > to > > ask first. It doesn't matter how simple or complicated the change > > is, > > just be polite. > > But that doesn't scale. I think it can be made to scale - at least in most cases. We could have a mechanism that stages the change and notifies the maintainer (eq. asks first automatically) and gives him the option to apply the change or cancel it & do it properly themselves. And if there is no reply from the maintainer, the change will be applied automatically after some time (24-48 hours ? could be configurable). I think this workflow would lessen the burden for both parties involved: * less work for proven packagers when "doing it right" (automatic asking, staging & auto apply) * maintainers get always notified automatically, can easily "ACK" trivial changes or cancel the change and do it properly if needed > > And scaling is important. We aren't developing a set of 4000s silos > here, > we are meant to be developing a coherent operating system. > > You don't stuff, get over it, maintain it as best you can, if someone > else > screws it up, git revert and move on. If someone persistently screws > things > up then we should deal with *that* problem. I don't think we have > anyone > actively trying to screw up Fedora, so in theory we are all on the > same team > and pulling in the same direction. So maybe if we started with an > attitude > that they are have a good reason for touching the package, and worked > with > that instead of defaulting to silos it would help a lot more. > > Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
> "BCL" == Brian C Lane writes: BCL> I don't think we need a technical solution, we just need the people BCL> who feel the need to modify packages they aren't normally involved BCL> with to ask first. It doesn't matter how simple or complicated the BCL> change is, just be polite. I disagree. And better yet, as a package maintainer, I have packages for which I don't actually want that. Hence my proposal. - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
David Airlie wrote: > > > - Original Message - >> From: "Brian C. Lane" >> To: devel@lists.fedoraproject.org >> Sent: Thursday, 19 November, 2015 7:05:57 AM >> Subject: Re: Dealing with the "my packages" problem >> >> On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote: >>> Matthew Miller wrote: >>>> On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: >>>>> After some IRC discussion I've come to the following proposal: that >>>>> maintainers have some way to easily indicate how open they are to >>>>> external contributions. Basically this would take the form of a few >>>>> options in pkgdb where maintainers can indicate their willingness to >>>>> have provenpackagers carry out a few actions. Please read the github >>>>> ticket for details: >>>>> https://github.com/fedora-infra/pkgdb2/issues/274 >>>> >>>> What if we made the options be about _the package_ rather than about >>>> the maintainer's prickliness? Rather than "Please don't touch my >>>> package" (I know that's not your wording; added for emphasis) make it >>>> "This package has unusual complications; please coordinate any changes >>>> with the package maintainers." >>>> >>>> Well, except, less wordy. :) >>>> >>>> And, in thinking about it, I don't think we should encourage the >>>> option of "Don't even ask". If there really _is_ something that's a big >>>> deal, the package maintainer can always say no when asked. >>>> >>> >>> As one of the complainers about current policy, here are my thoughts. >>> >>> I appreciate tibbs bringing up the discussion. I'd vote for a default >>> stance of "Ask first." >> >> I don't think we need a technical solution, we just need the people who >> feel the need to modify packages they aren't normally involved with to >> ask first. It doesn't matter how simple or complicated the change is, >> just be polite. > > But that doesn't scale. > > And scaling is important. We aren't developing a set of 4000s silos here, > we are meant to be developing a coherent operating system. I have no insight into how many packages provenpackers are tweaking. I guess I'd hope that the number would be low because of responsible package . I assume the number of changes is << 4000. > You don't stuff, get over it, maintain it as best you can, if someone else > screws it up, git revert and move on. If someone persistently screws things > up then we should deal with *that* problem. I don't think we have anyone > actively trying to screw up Fedora, so in theory we are all on the same team > and pulling in the same direction. So maybe if we started with an attitude > that they are have a good reason for touching the package, and worked with > that instead of defaulting to silos it would help a lot more. That may be true but hopefully in most cases the maintainer or co-maintainer knows a bit more about the package than some random provenpackager. Having to revert changes is non-zero work. I also wonder if I revert a provenpackager change, is that the end of it? Who is the arbiter in this case if not? rob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Wed, 2015-11-18 at 10:04 -0500, Matthew Miller wrote: > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: > > After some IRC discussion I've come to the following proposal: that > > maintainers have some way to easily indicate how open they are to > > external contributions. Basically this would take the form of a few > > options in pkgdb where maintainers can indicate their willingness to > > have provenpackagers carry out a few actions. Please read the github > > ticket for details: > > https://github.com/fedora-infra/pkgdb2/issues/274 > > What if we made the options be about _the package_ rather than about > the maintainer's prickliness? Rather than "Please don't touch my > package" (I know that's not your wording; added for emphasis) make it > "This package has unusual complications; please coordinate any changes > with the package maintainers." > > Well, except, less wordy. :) > > And, in thinking about it, I don't think we should encourage the > option of "Don't even ask". If there really _is_ something that's a big > deal, the package maintainer can always say no when asked. Just as a general note on this thread: if you're a packager and you have a genuine reason why people should be careful about touching your package, or follow some specific process when doing so, or there's something that people might think they should change but they shouldn't, there is already a pretty effective way of dealing with this: ** PUT A COMMENT IN THE SPEC FILE ** this is extremely easy to do, and extremely difficult for anyone who touches it to claim they didn't see. Package builds in a community distro are really just like F/OSS code: you should assume other people are going to be looking at it and poking it and trying to do stuff with it, and any time it's doing something that isn't extremely obvious or diverges from the general conventions, it makes sense to comment it. A common example is cases where the Fedora spec is generated as part of some other workflow, and downstream direct edits to the spec screw that up: this is a thing that happens, but it isn't the general convention with Fedora, and you can't really just expect people to magically know about it. If your spec is like this, put a comment in the spec file so anyone who goes to poke it knows about the workflow. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
- Original Message - > From: "Brian C. Lane" > To: devel@lists.fedoraproject.org > Sent: Thursday, 19 November, 2015 7:05:57 AM > Subject: Re: Dealing with the "my packages" problem > > On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote: > > Matthew Miller wrote: > > > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: > > >> After some IRC discussion I've come to the following proposal: that > > >> maintainers have some way to easily indicate how open they are to > > >> external contributions. Basically this would take the form of a few > > >> options in pkgdb where maintainers can indicate their willingness to > > >> have provenpackagers carry out a few actions. Please read the github > > >> ticket for details: > > >> https://github.com/fedora-infra/pkgdb2/issues/274 > > > > > > What if we made the options be about _the package_ rather than about > > > the maintainer's prickliness? Rather than "Please don't touch my > > > package" (I know that's not your wording; added for emphasis) make it > > > "This package has unusual complications; please coordinate any changes > > > with the package maintainers." > > > > > > Well, except, less wordy. :) > > > > > > And, in thinking about it, I don't think we should encourage the > > > option of "Don't even ask". If there really _is_ something that's a big > > > deal, the package maintainer can always say no when asked. > > > > > > > As one of the complainers about current policy, here are my thoughts. > > > > I appreciate tibbs bringing up the discussion. I'd vote for a default > > stance of "Ask first." > > I don't think we need a technical solution, we just need the people who > feel the need to modify packages they aren't normally involved with to > ask first. It doesn't matter how simple or complicated the change is, > just be polite. But that doesn't scale. And scaling is important. We aren't developing a set of 4000s silos here, we are meant to be developing a coherent operating system. You don't stuff, get over it, maintain it as best you can, if someone else screws it up, git revert and move on. If someone persistently screws things up then we should deal with *that* problem. I don't think we have anyone actively trying to screw up Fedora, so in theory we are all on the same team and pulling in the same direction. So maybe if we started with an attitude that they are have a good reason for touching the package, and worked with that instead of defaulting to silos it would help a lot more. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Nov 18, 2015 14:06, "Brian C. Lane" wrote: > > On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote: > > Matthew Miller wrote: > > > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: > > >> After some IRC discussion I've come to the following proposal: that > > >> maintainers have some way to easily indicate how open they are to > > >> external contributions. Basically this would take the form of a few > > >> options in pkgdb where maintainers can indicate their willingness to > > >> have provenpackagers carry out a few actions. Please read the github > > >> ticket for details: > > >> https://github.com/fedora-infra/pkgdb2/issues/274 > > > > > > What if we made the options be about _the package_ rather than about > > > the maintainer's prickliness? Rather than "Please don't touch my > > > package" (I know that's not your wording; added for emphasis) make it > > > "This package has unusual complications; please coordinate any changes > > > with the package maintainers." > > > > > > Well, except, less wordy. :) > > > > > > And, in thinking about it, I don't think we should encourage the > > > option of "Don't even ask". If there really _is_ something that's a big > > > deal, the package maintainer can always say no when asked. > > > > > > > As one of the complainers about current policy, here are my thoughts. > > > > I appreciate tibbs bringing up the discussion. I'd vote for a default > > stance of "Ask first." > > I don't think we need a technical solution, we just need the people who > feel the need to modify packages they aren't normally involved with to > ask first. It doesn't matter how simple or complicated the change is, > just be polite. > It is slightly more complicated than that. I ask.. How long do I have to wait/for an answer? We are worldwide with people who may not be able to answer for 48 to 96 hours. If that means that builds can't be done for that time are the comminity OK with that? And if they aren't then what is the mechanism to show that it was asked and no answer came in by n time so a change was made anyway > -- > Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote: > Matthew Miller wrote: > > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: > >> After some IRC discussion I've come to the following proposal: that > >> maintainers have some way to easily indicate how open they are to > >> external contributions. Basically this would take the form of a few > >> options in pkgdb where maintainers can indicate their willingness to > >> have provenpackagers carry out a few actions. Please read the github > >> ticket for details: > >> https://github.com/fedora-infra/pkgdb2/issues/274 > > > > What if we made the options be about _the package_ rather than about > > the maintainer's prickliness? Rather than "Please don't touch my > > package" (I know that's not your wording; added for emphasis) make it > > "This package has unusual complications; please coordinate any changes > > with the package maintainers." > > > > Well, except, less wordy. :) > > > > And, in thinking about it, I don't think we should encourage the > > option of "Don't even ask". If there really _is_ something that's a big > > deal, the package maintainer can always say no when asked. > > > > As one of the complainers about current policy, here are my thoughts. > > I appreciate tibbs bringing up the discussion. I'd vote for a default > stance of "Ask first." I don't think we need a technical solution, we just need the people who feel the need to modify packages they aren't normally involved with to ask first. It doesn't matter how simple or complicated the change is, just be polite. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
Matthew Miller wrote: > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: >> After some IRC discussion I've come to the following proposal: that >> maintainers have some way to easily indicate how open they are to >> external contributions. Basically this would take the form of a few >> options in pkgdb where maintainers can indicate their willingness to >> have provenpackagers carry out a few actions. Please read the github >> ticket for details: >> https://github.com/fedora-infra/pkgdb2/issues/274 > > What if we made the options be about _the package_ rather than about > the maintainer's prickliness? Rather than "Please don't touch my > package" (I know that's not your wording; added for emphasis) make it > "This package has unusual complications; please coordinate any changes > with the package maintainers." > > Well, except, less wordy. :) > > And, in thinking about it, I don't think we should encourage the > option of "Don't even ask". If there really _is_ something that's a big > deal, the package maintainer can always say no when asked. > As one of the complainers about current policy, here are my thoughts. I appreciate tibbs bringing up the discussion. I'd vote for a default stance of "Ask first." I can only speak for myself, but as someone who owns only a handful of packages that I tend to somewhat carefully, if perhaps too slowly in some cases for the rapidly moving Fedora. Perhaps I would feel differently if I maintained 100+ packages like some others. I wonder if what is obvious to provenpackers is not so obvious to the little packagers. The word that I used to use when thinking about the packages I maintained was "pride." I didn't break Fedora, even rawhide (usually, anyway). I was careful and did things like test compatibility of new versions with other packages to at least take a pass at ensuring I wasn't going to break someone else. Rawhide is not supposed to be a dumping ground, right? The word "pride" is nowhere in the Fedora packaging or core values. Instead the values stress Fast and First. Ok fine, so I take from this that I should care a lot less about what I do because so what, right? If I update to an upstream that breaks everyone else, well, I'm keeping the core value of First and therefore it is up to others to deal with the fallout. Or no? If I happen to be the upstream and someone comes along and makes incompatible changes to the package, well, it's their right and I need to just shut up and move along. For me it was never about crossing some imaginary "ownership" line. I took pride and responsibility that the packages I maintained were in good shape and someone making unannounced changes, good intentions aside, made work for me to go and vet the change and test it on their timeline, not mine. As with most things in life there needs to be balance. I don't think saying in advance "I'm going to do X to package Y" is asking too much (with the obvious exception of rebuilds). I have a rather limited world view of packaging in Fedora though, so maybe I'm missing the bigger picture. In any case, I'm rather cynical about the whole thing now. rob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote: > After some IRC discussion I've come to the following proposal: that > maintainers have some way to easily indicate how open they are to > external contributions. Basically this would take the form of a few > options in pkgdb where maintainers can indicate their willingness to > have provenpackagers carry out a few actions. Please read the github > ticket for details: > https://github.com/fedora-infra/pkgdb2/issues/274 What if we made the options be about _the package_ rather than about the maintainer's prickliness? Rather than "Please don't touch my package" (I know that's not your wording; added for emphasis) make it "This package has unusual complications; please coordinate any changes with the package maintainers." Well, except, less wordy. :) And, in thinking about it, I don't think we should encourage the option of "Don't even ask". If there really _is_ something that's a big deal, the package maintainer can always say no when asked. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
2015-11-18 1:08 GMT+01:00 Jason L Tibbitts III : > tl; dr: I have submitted the following RFE for pkgdb: > https://github.com/fedora-infra/pkgdb2/issues/274 > Please add comments there if you have any. > > I know I'm not the only provenpackager to have applied a bugfix to > someone's package only to be yelled at it for it. Some maintainers are > more prickly about having others touch the packages they maintain for > the community than others, and unfortunately there's currently just no > way to know whether you'll be thanked or flamed for helping out with a > package. > > After some IRC discussion I've come to the following proposal: that > maintainers have some way to easily indicate how open they are to > external contributions. Basically this would take the form of a few > options in pkgdb where maintainers can indicate their willingness to > have provenpackagers carry out a few actions. Please read the github > ticket for details: > https://github.com/fedora-infra/pkgdb2/issues/274 > > This would be purely advisory, with hopefully reasonable defaults. I > believe it has the potential to eliminate quite a bit of friction that > provenpackagers must handle, as well as eliminate the hesitation some of > us feel for fear of being flamed. > > - J< As a provenpackager, I prefer to send an heads up and briefly explain (for non-trivial change) the reason. This lessen the friction a lot. As a comaintainer, I've had issues with non-trivial changes and some buggy updates (e.g. provenpackager pushing latest release though it's known upstream to be broken). Issues that could be avoided with minimal communications, I wish we had an actual reviewing system that creates this communication and lower the threshold to contributing at the same time. Though I prefer review boards like gerrit or ReviewBoard, even a simple Pull Requests based reviewing system as in Pague would be welcome. Regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
On Tue, 2015-11-17 at 19:21 -0500, David Airlie wrote: > > > Maybe by renaming package maintainers to something like caretakers we could > start changing the way people who maintain packages view their positions. We actually already did that, but people haven't taken much notice. If you look in pkgdb, there is no 'package owner' or 'package maintainer', but 'main contact'(s) and 'package administrator(s)'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
> "DA" == David Airlie writes: DA> This seems like a crappy technical solution to a social problem. I don't know; it seems to be more discoverable than the current state, where either you just commit and hope. And yeah, I'm relatively thick skinned but I still don't like to get flamed by a maintainer that I might run into at Flock. Plus, it's not entirely a social problem. Some packages really do need extra care and it's not always obvious. Currently the best you can do is a comment in the specfile. Maybe that's sufficient, I'm not sure. Finally, I don't think having a flag to distinguish between "please ask me first" and "fire at will" (with different possible answers for rawhide vs. release and committing vs. actually building or pushing updates) falls within the realm of the social problem that you mention. DA> Maybe by renaming package maintainers to something like caretakers DA> we could start changing the way people who maintain packages view DA> their positions. That's true, but I think there's more nuance than that and in any case I'm trying to approach it from a different angle. I certainly wouldn't argue if you made a proposal to that effect but I still think I'm trying to solve a slightly different problem. Heck, if my proposal were implemented (which is easy from a coding standpoint) then we might be able to collect some stats on how many maintainers feel a certain way. DA> The other option is to just open all packages to everyone, I've no DA> idea why we still have ACLs in the land of git. Because it still takes nonzero time to undo or merge things, and because I really don't like the idea of giving every single packager (or, depending on what you actually meant, everyone with a Fedora account) root access to my rawhide machines. Or were you proposing removing ACLs only for committing to packages but keeping them for actually doing builds? What about updates? It's not quite so simple. (And yes, I've been a part of several big discussions about this over the lifetime of the project.) - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dealing with the "my packages" problem
> > tl; dr: I have submitted the following RFE for pkgdb: > https://github.com/fedora-infra/pkgdb2/issues/274 > Please add comments there if you have any. > > I know I'm not the only provenpackager to have applied a bugfix to > someone's package only to be yelled at it for it. Some maintainers are > more prickly about having others touch the packages they maintain for > the community than others, and unfortunately there's currently just no > way to know whether you'll be thanked or flamed for helping out with a > package. > > After some IRC discussion I've come to the following proposal: that > maintainers have some way to easily indicate how open they are to > external contributions. Basically this would take the form of a few > options in pkgdb where maintainers can indicate their willingness to > have provenpackagers carry out a few actions. Please read the github > ticket for details: > https://github.com/fedora-infra/pkgdb2/issues/274 > > This would be purely advisory, with hopefully reasonable defaults. I > believe it has the potential to eliminate quite a bit of friction that > provenpackagers must handle, as well as eliminate the hesitation some of > us feel for fear of being flamed. > This seems like a crappy technical solution to a social problem. Maybe by renaming package maintainers to something like caretakers we could start changing the way people who maintain packages view their positions. You don't own a package in Fedora. You are taking care of it on behalf of the Fedora community, other people in the community can touch your package. The other option is to just open all packages to everyone, I've no idea why we still have ACLs in the land of git. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Dealing with the "my packages" problem
tl; dr: I have submitted the following RFE for pkgdb: https://github.com/fedora-infra/pkgdb2/issues/274 Please add comments there if you have any. I know I'm not the only provenpackager to have applied a bugfix to someone's package only to be yelled at it for it. Some maintainers are more prickly about having others touch the packages they maintain for the community than others, and unfortunately there's currently just no way to know whether you'll be thanked or flamed for helping out with a package. After some IRC discussion I've come to the following proposal: that maintainers have some way to easily indicate how open they are to external contributions. Basically this would take the form of a few options in pkgdb where maintainers can indicate their willingness to have provenpackagers carry out a few actions. Please read the github ticket for details: https://github.com/fedora-infra/pkgdb2/issues/274 This would be purely advisory, with hopefully reasonable defaults. I believe it has the potential to eliminate quite a bit of friction that provenpackagers must handle, as well as eliminate the hesitation some of us feel for fear of being flamed. - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
