6:08 p.m.
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<
6:21 p.m.
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.
6:48 p.m.
>>>> "DA" == David Airlie
<airlied(a)redhat.com> 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<
9:21 p.m.
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
5:23 a.m.
2015-11-18 1:08 GMT+01:00 Jason L Tibbitts III <tibbs(a)math.uh.edu>:
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.
9:04 a.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:24 p.m.
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
3:05 p.m.
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)
3:27 p.m.
On Nov 18, 2015 14:06, "Brian C. Lane" <bcl(a)redhat.com> 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3:39 p.m.
----- Original Message -----
From: "Brian C. Lane" <bcl(a)redhat.com>
To: devel(a)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.
4:23 p.m.
David Airlie wrote:
----- Original Message -----
> From: "Brian C. Lane" <bcl(a)redhat.com>
> To: devel(a)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 <insert favorite synonym for maintainer>. 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
4:57 a.m.
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.
4:06 a.m.
On Wed, 2015-11-18 at 16:39 -0500, David Airlie wrote:
----- Original Message -----
> From: "Brian C. Lane" <bcl(a)redhat.com>
> To: devel(a)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.
5:35 a.m.
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" <bcl(a)redhat.com>
> > To: devel(a)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.)
3:32 p.m.
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" <bcl(a)redhat.com>
>>> To: devel(a)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?
7:19 a.m.
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
12:04 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5 p.m.
>>>> "BCL" == Brian C Lane
<bcl(a)redhat.com> 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<
3:49 p.m.
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
8:44 a.m.
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 Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
10:58 a.m.
On Thu, Nov 19, 2015 at 9:44 AM, Orion Poplawski <orion(a)cora.nwra.com> 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.
6 p.m.
On Wed, Nov 18, 2015 at 4:49 PM, Adam Williamson
<adamwill(a)fedoraproject.org> 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.
7:10 p.m.
On Sun, Nov 29, 2015 at 7:00 PM, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Wed, Nov 18, 2015 at 4:49 PM, Adam Williamson
<adamwill(a)fedoraproject.org> 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!
3070
days inactive
3082
days old
22 comments
17 participants
participants (17)
-
Adam Williamson -
Brian C. Lane -
Christopher -
David Airlie -
Haïkel -
Jason L Tibbitts III -
Martin Kolman -
Matthew Miller -
Michael Catanzaro -
Michael Schwendt -
Neal Gompa -
Nico Kadel-Garcia -
Orion Poplawski -
Pavel Alexeev -
Rob Crittenden -
Stephen John Smoogen -
Tomas Mraz