Re: On packager motivation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/03/2016 08:44 AM, Jerry James wrote:
> On Tue, Feb 2, 2016 at 11:30 PM, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
>> Well, one thing about this is that no-one owns packages anymore. We are a
>> community and there are package maintainers in that community.
>> Each package has one or more maintainers, but nobody owns it. The only reason we
>> even have a point of contact is because of bugzilla that requires a single
>> account to assign the bug reports to.
>>
>> So sorry but you do not own your packages, you maintain them and where you are
>> the point of contact, you are merely the primary recipient of the bug reports :)
> 
> Several people have said something similar lately, and it worries me.
> I understand that we're trying to combat the hostility some packagers
> show when somebody does something to "their" packages, but I'm
> concerned that we may have swung the pendulum too far the other way.
> I foresee two problems:
> 
> 1. Demotivating packagers
> 
> I know a number of companies have experimented with "ownership-free"
> models of code development, but they are able to offer incentives that
> Fedora cannot offer, such as money and kudos offered in front of
> coworkers.  What motivates volunteer packagers to do what they do?
> I'd like to hear from a few packagers on this topic.
> 
> What motivates me is pride in my work, and recognition of that good
> work by others.  If I'm just one packager in a big cloud of packagers,
> and none of us is really responsible for anything ... well, that's
> quite demotivating.
> 
> I am the primary point of contact for a few dozen packages where I
> have done all of the packaging work, all of the reporting of bugs
> upstream, all of the arguing with upstream to do something about
> sticky license situations, all of the handling of bug reports.  I'm
> sure the same is true for many other packagers.  People feel ownership
> of what they work on.  This is human nature.  I fear that by denying
> human nature with this "those aren't your packages" mantra, we will
> suck the joy out of packaging work and see packagers less willing to
> do that work.

I guess I wouldn't have used the phrase "merely the primary recipient of the
bug reports".  It's pretty obvious that most packages have a single primary
maintainer, and that maintainer should justifiably be able to take pride in
the work they do maintaining their packages.

That said, this is also a community project, and we really do need to get away
from the "I own this, stay away" mentality that has arisen in some contributors.

> 2. Motivating responsibility-free drive-by modifications
> 
> If nobody owns any packages, then who is responsible for fixing
> package problems?  I think the reason some packagers react with
> hostility to others changing "their" packages is that we have a
> handful of provenpackagers who make incorrect changes to packages and
> then walk away, without sticking around to fix the problems they
> caused with their incorrect changes.  I've got two recent examples of
> this.  I won't use any names, because my purpose is not to point
> fingers.
> 
> a. Last fall, a provenpackager updated a package for which I am the
> primary point of contact (as well as the original submitter).  The
> update was to an upstream alpha release.  It was alpha for a reason.
> The release is super buggy.  I had not updated to it on purpose.  A
> provenpackager strolled by, updated to the buggy release, then
> strolled away.  Guess who has been getting the bug reports?  Not the
> person who did the update, the person who did not even bother
> contacting the primary point of contact to see if updating was okay.
> 
> b. Just last week, another provenpackager dropped two patches into a
> package for which I am the primary point of contact (as well, again,
> as the original submitter).  One patch only has effect on non-Linux
> systems, so adding it was pointless.  I don't even have any idea what
> the other patch does.  It changes stuff, I can see that, but why?  The
> person who did this did not add any comments to the PatchN: lines in
> the spec file, so I don't know if they have been submitted upstream,
> are from upstream, or what.  Here, again, the provenpackager made *no*
> attempt at all to contact the primary point of contact.
> 
> If I send these two provenpackagers a somewhat hostile email, are you
> going to blame me?  I have no problem with most provenpackager
> changes.  In general, they have an obvious purpose and save me the
> work of making the same change myself.  But changes like the ones
> above make more work for me, work that could have been avoided if the
> provenpackager in question had just bothered to make some attempt, any
> attempt, to contact me first.

Those are unfortunate and inappropriate, and I think would justify complaint.

> I think we need to ask ourselves, as a project, what behaviors we want
> to motivate and what behaviors we want to demotivate in our packagers.
> I think we need to take human nature, flawed as it is, into account
> when doing so.  I fear that this "nobody owns any packages" mantra is
> not providing the motivations and demotivations that we really want.

Both extremes are problematic.  Personally I welcome any and all well
intentioned help with the packages I am the primary maintainer of.  And
barring a few unfortunate version bumps, there isn't much that can't be fixed
by reverting the change.  If someone is consistently causing trouble that
needs to be called out.  At the same time, before reacting with hostility that
someone changed "your" package, ask yourself if the change really was
inappropriate, or if you are upset simply because your weren't asked first.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@xxxxxxxx
Boulder, CO 80301                   http://www.nwra.com
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux