Re: On packager motivation

2016-02-04 Thread Haïkel 
2016-02-03 17:04 GMT+01:00 Jonathan Wakely :
> On 03/02/16 08:44 -0700, Jerry James wrote:
>
>> 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.
>
>
> I want Fedora to be better.
>
>> 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.
>
>
> I don't think that's always realistic to expect.
>
> When a provenpackager is rebuilding *hundreds* of packages at once,
> and trying to deal with maybe dozens of build failures, sending emails
> to all the package owners and waiting to see if they respond promptly
> is not an efficient way to get things fixed. Waiting for a reply adds
> a lot of latency, and then you have to context-switch back to a
> package you were dealing with a day or two ago. That's impractical
> when you have a patch ready to go now and loads more packages to look
> at.
>

I disagree with you on that point.
I agree with the premises that we can't expect provenpackagers to
contact every single maintainers for fixing a large number of packages
at once, but that's the role of fedora devel list.
If you can't contact everyone, a message on fedora-devel is good enough.

For instance, the desktop team maintains a spreadsheet before GNOME
rebuilds so that package maintainers can give their input before a
provenpackager do the builds.
That allows maintainer to provide valuable feedback like avoiding
borken versions upstream, or how to update patchset if they're
maintained in a specific way.

> Sometimes a provenpackager will make a bad change, and that's
> unfortunate, but it happens. Sometimes package owners make bad changes
> too! :-)
>

Yes, but provided that they sent a heads-up on usual communication
channels, there's no problem with it.

> If I make a bad change to a package please do let me know. If I appear
> to change things and walk away it's probably because I've moved on to
> look at other packages that also need attention, not just a careless
> hit & run. I would expect it's similar for others.
>

As a provenpackager, I always ping maintainers, and try to minimize
impact (e.g not fixing spec to my personal liking w/o agreement)
As a packager, I usually go through the changes, unless it broke
something or is non-trivial, I'm fine with letting it go.

If you add epoch to packages I co-maintain without telling me,
I'll hate you until the ends of time ;-)


> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-04 Thread kendell clark 



On 2/4/2016 4:48 AM, Michael Schwendt wrote:

On Wed, 3 Feb 2016 19:35:41 -0700, Kevin Fenzi wrote:


But thats not how I look at it least. Instead of being one package who
says "My packages are great", you can say "My packages are great, and
other people help me when they can, and I help them out and our
community is great". It's not that no one is responsible for anything,
it's that everyone is responsible for everything. If you see some way
you can help, you do, and you don't stop with "oh, thats not my
package, I'll let the owner deal with it"

That's somewhat out of context given that Jerry has referred to
*non-helpful* modifications applied by provenpackagers.

I wonder why nobody has replied to notting's question in this thread yet?

There is a huge difference between the package maintenance models as
applied by different packagers. That's not specific to Fedora. Other
dists are also affected.

Some packagers try to establish contact with upstream devs, others
don't.

Some packagers try to get fixes included upstream to have the entire
community benefit from it, others are proud of their heavily patched
packages.

Some packagers try to handle problem reports in bugzilla, others don't
(for various reasons not limited to profane reasons such as "bugzilla
isn't sexy"). Some avoid bugzilla like a plague. That's a big hindrance
for fellow packagers, btw.

Some packagers are easier to deal with than others.

Now as provenpackagers are packagers too, there are some among them who
have completely differing views on how to do package maintenance. That
is the problem, if you touch a package in a way the primary maintainer
doesn't agree with. The provenpackager, who touches his "own" packages
in the same questionable way, likely doesn't see any problem. A maintenance
model that aims at "less responsibility + less effort" is highly
problematic. For version upgrades the provenpackager would better
acquire official commit access to the package *and* keep contact with
the other maintainer(s) to get a feeling on how to team up.


Perhaps we can explain it better by saying "everyone owns all
packages" ?

Hasn't the term "package owner" been considered highly controversial
and problematic several times before?

I really want to see more team-work at Fedora. People practising
package maintenance as a collaborated effort.


"My own personal view is that packagers *should* establish contact with 
upstream devs, so that changes they make can be incorporated upstream. 
However, this is not always easy. The comments in this thread about 
packagers can also be applied, easily, to the upstream community. Some 
devs are friendly and helpful, while others are do it my way types of 
people. Chromium is a good example of the latter. My opinions on chrome 
are well known so I won't repeat them, only saying that accessibility is 
one of those topics that *is not* optional, but mandatory, at least in 
my opinion. The fedora community has treated me extremely well and you 
guys really do care about accessibility, which is fantastic. You're one 
of the few, with the exception of the debian accessibility community, 
who actually seems to care. Which makes it even harder to deal with 
communities where developers, and there are quite a few, that say they 
care but lack the knowledge, frustrating, or simply don't seem to care 
at all, enfuriating. I've looked at the accessibility packages in 
fedora, a couple of them at least, and every developer I've talked to 
communicates with upstream where possible, although espeak is going 
through a bit of flux at the moment having recently been forked. 
Joanmeri diggs, the lead orca developer, , I believe uses fedora to 
develop orca on, which says a lot about it. I use it as one of my main 
distros myself. It was fedora which inspired me to start a git 
repository of pronunciation fixes for espeak, which are now periodically 
being merged into the espeak fork.I'm not completely sure what the OP 
meant in the original post, I think I missed it, but fedora, like every 
other distro, is a community made up of different people. Some of them 
will do their best to make sure their changes and fixes get incorporated 
into upstream, some will assume that upstream should come to them. 
Neither view is wrong, exactly, just different. I have extremely strong 
views on accessibility, sometimes overly strong, which tend to come out 
if I feel slighted or not taken seriously. Especially in this age of 
mass produced products that show little, if any, effort in regards to 
accessibility. Things like phones that don't talk, computers with 
windows that don't come with adequate assistive software, etc. I'm 
rambling, so I'll stop now.


Just my two cents
Kendell clark
"


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-04 Thread Michael Schwendt 
On Wed, 3 Feb 2016 19:35:41 -0700, Kevin Fenzi wrote:

> But thats not how I look at it least. Instead of being one package who
> says "My packages are great", you can say "My packages are great, and
> other people help me when they can, and I help them out and our
> community is great". It's not that no one is responsible for anything,
> it's that everyone is responsible for everything. If you see some way
> you can help, you do, and you don't stop with "oh, thats not my
> package, I'll let the owner deal with it"

That's somewhat out of context given that Jerry has referred to
*non-helpful* modifications applied by provenpackagers.

I wonder why nobody has replied to notting's question in this thread yet?

There is a huge difference between the package maintenance models as
applied by different packagers. That's not specific to Fedora. Other
dists are also affected.

Some packagers try to establish contact with upstream devs, others
don't.

Some packagers try to get fixes included upstream to have the entire
community benefit from it, others are proud of their heavily patched
packages.

Some packagers try to handle problem reports in bugzilla, others don't
(for various reasons not limited to profane reasons such as "bugzilla
isn't sexy"). Some avoid bugzilla like a plague. That's a big hindrance
for fellow packagers, btw.

Some packagers are easier to deal with than others.

Now as provenpackagers are packagers too, there are some among them who
have completely differing views on how to do package maintenance. That
is the problem, if you touch a package in a way the primary maintainer
doesn't agree with. The provenpackager, who touches his "own" packages
in the same questionable way, likely doesn't see any problem. A maintenance
model that aims at "less responsibility + less effort" is highly
problematic. For version upgrades the provenpackager would better
acquire official commit access to the package *and* keep contact with
the other maintainer(s) to get a feeling on how to team up.

> Perhaps we can explain it better by saying "everyone owns all
> packages" ?

Hasn't the term "package owner" been considered highly controversial
and problematic several times before?

I really want to see more team-work at Fedora. People practising
package maintenance as a collaborated effort.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-04 Thread Kevin Kofler 
kendell clark wrote:
> However, this is not always easy. The comments in this thread about
> packagers can also be applied, easily, to the upstream community. Some
> devs are friendly and helpful, while others are do it my way types of
> people. Chromium is a good example of the latter.

As the QtWebEngine (qt5-qtwebengine) packager, I can second that. While the 
QtWebEngine developers at Qt are more helpful, what they can do is limited 
by what Chromium supports (because they don't want to heavily patch 
Chromium). And Chromium refuses, for example, to support x86 CPUs without 
SSE2, so I can only add that support as a downstream patch.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Rich Mattes 
On Wed, Feb 3, 2016 at 2:19 PM, Michael Schwendt  wrote:
> On Wed, 3 Feb 2016 16:04:19 +, Jonathan Wakely wrote:
>
>> When a provenpackager is rebuilding *hundreds* of packages at once,
>> and trying to deal with maybe dozens of build failures, sending emails
>> to all the package owners and waiting to see if they respond promptly
>> is not an efficient way to get things fixed. Waiting for a reply adds
>> a lot of latency, and then you have to context-switch back to a
>> package you were dealing with a day or two ago. That's impractical
>> when you have a patch ready to go now and loads more packages to look
>> at.
>
> https://fedoraproject.org/wiki/Provenpackager_policy
>
>  | Provenpackagers should try to communicate with owners of a package in
>  | bugzilla, irc or email prior to making changes.
>
>  | They should be careful not to change other people's packages needlessly
>  | and try to do the minimal changes required to fix problems, as explained
>  | more in depth in the policy explaining who is allowed to modify which
>  | packages.
>  | -> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages
>
> Even if says "should" two times, Jerry refers to "no prior contact" and
> a version upgrade to alpha level software. That doesn't sound like anything
> provenpackagers should do within arbitrary packages.
>
> I wonder whether a message at the top would have changed the provenpackager's
> mind?
>

Yes, as far as the guidelines state, provenpackager is not carte
blanche to do drive-by modifications of packages at will - there needs
to be communication, even if it seems inconvenient.  For that matter,
it's also not license to violate packaging guidelines by adding
patches without comments or upgrading versions outside of the stable
update guidelines, so I sympathize with Jerry's original mail in that
respect.

If you read 
https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages,
there's even more suggestions for how to go about editing others'
packages, including:

"if you committed changes to another package wait some hours if
possible (normally 24 or 48) before you actually build the updated
package as long it is nothing serious that should be fixed quickly
(security problems, ...). That leaves some time for the maintainer to
wake up ;-) "

I'll also not that the above page seems not reflect at all the "Nobody
owns packages" mantra that Jerry is responding to, like where it says:

"Normally the maintainer that is listed as primary maintainer in the
PackageDB (formerly this was owners.list) of a package is the only one
who modifies the package or gives others permission (e.g. by accepting
them as co-maintainers) to commit and build changes for that package."

I'm not sure who maintains that page or if its an official guideline,
but it certainly outlines what my impresson of the best way to go
about changing things is.

Speaking for myself, I do all of my Fedora work in my free time
outside of $DAYJOB, so I do appreciate when others step in and help
out with issues in my packages.  It also means I'm not always able to
respond to bug reports or rawhide failures within a couple of days,
but I do try my best to get to things within a week or so.  That said,
I do have a life, and things occasionally fall off of my radar.
Keeping up with others' changes to my packages, especially if they're
not high caliber changes, just takes more time I could be spending on
other things.  It's a much better use of my time to respond to a bug
or email to the package-owner alias about forthcoming changes than to
try to reverse engineer changes after the fact.

In that vein, and to address the *hundreds* of packages at once issue,
a mass email to package owner aliases that says "i'm going to make X
huge change in a few days, these are the packages affected, I plan on
resolving fallout, let me know if you'd like to handle it instead" is
a good compromise that only extends the time it takes for you to do
your work by a reasonable notification period.  Similarly, status
updates like "This side tag will be merged on $DATE, please be ready
for fall-out" will help everyone else help you for big changes.

>> Sometimes a provenpackager will make a bad change, and that's
>> unfortunate, but it happens. Sometimes package owners make bad changes
>> too! :-)
>
> You're taking it too lightly. Somebody who performs version upgrades really
> needs to take care of a package and incoming problem reports as well.

Agreed.  "They did it too!" is not a strong defense.  I also object to
the following comment:

>> If I appear
>> to change things and walk away it's probably because I've moved on to
>> look at other packages that also need attention, not just a careless
>> hit & run. I would expect it's similar for others.

These things are not mutually exclusive. Other packagers can't tell
what you're up to if you don't communicate with them.

Rich
--
devel mailing list

Re: On packager motivation

2016-02-03 Thread Bill Nottingham 
Michael Schwendt (mschwe...@gmail.com) said: 
> > Sometimes a provenpackager will make a bad change, and that's
> > unfortunate, but it happens. Sometimes package owners make bad changes
> > too! :-)
> 
> You're taking it too lightly. Somebody who performs version upgrades really
> needs to take care of a package and incoming problem reports as well.

Is "you, as a provenpackager, are responsible for seeing any changes you
make to completion, and dealing with any fallout from them" not the current
policy?  If not, why wouldn't it be?

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Ian Malone 
On 3 February 2016 at 23:00, Kevin Kofler  wrote:

>
> Really, it is not realistic to expect people who need to urgently fix
> something to write up a polite e-mail and wait possibly days for you to
> reply (especially if you then answer that you don't want the change and more
> days are wasted going back and forth arguing for why the change is needed).
> Either you are reachable quickly through real-time communication (which
> effectively means IRC in the Free Software world) or you will just not be
> asked.
>
> I always curse when I try to contact a packager and see either no IRC
> contact info, or an IRC nick that is clearly not in active use (last seen
> weeks ago).
>

If this is a requirement then it rules out a lot of potential
packagers who are not full time employed to work on OSS. I could not
sit at my desk and respond to IRCs about Fedora all day.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Kevin Fenzi 
On Wed, 3 Feb 2016 23:26:23 +
Ian Malone  wrote:

> If this is a requirement then it rules out a lot of potential
> packagers who are not full time employed to work on OSS. I could not
> sit at my desk and respond to IRCs about Fedora all day.

As with so much in life, IMHO, it's not a black and white issue, it's
somewhere in between. 

It's nice when you can find a maintainer on IRC and ask about something
quickly, but if they aren't there then thats too bad and you can either
just send them email or update the bug or update the package if it's
particularly urgent. 

Communication is important. As a provenpackager if you are changing a
bunch of packages for some issue, it's unlikely you can mail each
maintainer/co-maintainer separately, but you should definitely keep the
list updated and answer questions sent to you about it. 

kevin


pgpYGM3JzoqA6.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Kevin Fenzi 
On Wed, 3 Feb 2016 08:44:32 -0700
Jerry James  wrote:

> 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.

But thats not how I look at it least. Instead of being one package who
says "My packages are great", you can say "My packages are great, and
other people help me when they can, and I help them out and our
community is great". It's not that no one is responsible for anything,
it's that everyone is responsible for everything. If you see some way
you can help, you do, and you don't stop with "oh, thats not my
package, I'll let the owner deal with it"

> 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 don't think anyone wants to take that away. Instead we just want to
avoid the "These packages are mine mine mine, and no one can touch
them" when in fact you are just stewarding them for Fedora. 
> 
> 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.

It's not that nobody owns any packages, it's that we all do. 

snip cases of bad provenpackager behavior

> 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.

Well, yes, because I don't think hostile email is ever a good idea. :) 

But did you manage to talk to either of these provenpackagers and hear
back from them?  
> 
> 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.

Perhaps we can explain it better by saying "everyone owns all
packages" ?

kevin


pgpF9bD2YxixI.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Ian Kent 
On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote:
> 
> 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.

I agree.

I believe that package ownership has at least a couple of clear advantages for
obvious reasons and I find it hard to understand how people can discount their
usefulness.

1) A point of contact and co-ordination for changes is needed.

Often, when dealing with difficult problems it's necessary to seek advice from
maintainers of other packages. Being able to find out who that is and having
at least some chance they will be familiar with upstream package status is
important.

2) Taking (even notional) ownership of a package implies there is at least
some interest in the package from an upstream POV.

Some (probably many) packages need a packager to take an interest in what is
happening upstream. Building relationships with upstream maintainers doesn't
always work too well but even that is an important part of knowing what the
upstream status of a package is.

This is essential to be able to provide 1) above, someone who has some
understanding of the upstream status really is needed to at least help keep
our packages as stable as we can.

It's true that package owners don't always have enough upstream knowledge of
packages they own or relationships with upstream but that doesn't mean that
ownership is a bad thing. After all a point of contact is still needed IMHO.

I fail to see how allowing ad-hoc changes to packages, which will often not
even involve letting others interested in the package know what has happened,
will lead to improvement overall.

If the goal is to reduce the barrier for others to contribute then that
doesn't necessarily mean doing away with package owners. It means defining
processes to allow this while keeping the owner (the one that probably has
some idea of the upstream package status) in the loop. Whether that also means
power of veto over changes is slightly different but somehow I think that must
be the case to maximize package stability.

It might be obvious that my view is influenced a lot because I'm also an
upstream package maintainer.

Clearly I strongly believe in the need for downstream packagers to be in touch
with what's happening upstream. And, yes, it can be hard to take the "no" or
"I don't like that change" or an "I'm not going to do that" but that is all
part of working with upstream and knowing a package, the bit downstream
packagers seem to miss all too often IMHO.

Don't forget, the relationship (that is needed) is just as hard for upstream
as it is for downstream, that's just life.

Ian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Ian Kent 
On Wed, 2016-02-03 at 16:04 +, Jonathan Wakely wrote:

> > 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.
> 
> I don't think that's always realistic to expect.
> 
> When a provenpackager is rebuilding *hundreds* of packages at once,
> and trying to deal with maybe dozens of build failures, sending emails
> to all the package owners and waiting to see if they respond promptly
> is not an efficient way to get things fixed. Waiting for a reply adds
> a lot of latency, and then you have to context-switch back to a
> package you were dealing with a day or two ago. That's impractical
> when you have a patch ready to go now and loads more packages to look
> at.
> 
> Sometimes a provenpackager will make a bad change, and that's
> unfortunate, but it happens. Sometimes package owners make bad changes
> too! :-)
> 
> If I make a bad change to a package please do let me know. If I appear
> to change things and walk away it's probably because I've moved on to
> look at other packages that also need attention, not just a careless
> hit & run. I would expect it's similar for others.

Sorry but this sounds more like a process definition problem than anything.

In fact, problems like this sound like they would be better dealt with by
alerting the package maintainer and passing the ball to them. If the problem
isn't dealt with quickly enough then perhaps that package should not be re
-built at this time. There should be some responsibilities for package
maintainers.

And, surely, in this case the provenpackager has too much to do to pay
suitable attention to changes needed and really does need to move on.

Yes, there would be some need to define process around this so the ball could
come back to a provenpackager on a second pass, hopefully when they have a
little more time to attend to the problem, if there was no response from the
maintainer.

This reminds me of the saying "more haste less speed"!

Ian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Kevin Fenzi 
On Thu, 04 Feb 2016 09:09:33 +0800
Ian Kent  wrote:

> I agree.
> 
> I believe that package ownership has at least a couple of clear
> advantages for obvious reasons and I find it hard to understand how
> people can discount their usefulness.
> 
> 1) A point of contact and co-ordination for changes is needed.
> 
> Often, when dealing with difficult problems it's necessary to seek
> advice from maintainers of other packages. Being able to find out who
> that is and having at least some chance they will be familiar with
> upstream package status is important.
> 
> 2) Taking (even notional) ownership of a package implies there is at
> least some interest in the package from an upstream POV.
> 
> Some (probably many) packages need a packager to take an interest in
> what is happening upstream. Building relationships with upstream
> maintainers doesn't always work too well but even that is an
> important part of knowing what the upstream status of a package is.
> 
> This is essential to be able to provide 1) above, someone who has some
> understanding of the upstream status really is needed to at least
> help keep our packages as stable as we can.
> 
> It's true that package owners don't always have enough upstream
> knowledge of packages they own or relationships with upstream but
> that doesn't mean that ownership is a bad thing. After all a point of
> contact is still needed IMHO.

I agree with what you are saying, but disagree that anything above
requires you to "own" packages and guard them from anyone else. 

You can still be a point of contact and/or interested upstream and want
to help keep the packages in Fedora high quality and working, but still
be willing to work as part of the entire collection of maintainers not
isolated or defensive. We all want to improve things, even if we make
mistakes doing so. 
> 
> I fail to see how allowing ad-hoc changes to packages, which will
> often not even involve letting others interested in the package know
> what has happened, will lead to improvement overall.

* The change is something cosmetic over vast piles of packages (like
  the recent note that %defattr is useless) Sure you can clean that up
  yourself, but if we have an automated way of fixing it, why not let
  the automation do so?

* The issues might be things on some other arch that you don't have
  access to or care about, so someone interested in making Fedora
  better on that arch might add a patch or the like. 

* Some fix or workaround might be needed urgently and you may be
  unavailable. When you get back you can work on the real fix or
  whatever, and the things blocked went on in your absense. 

* Some package your package(s) depend on may have changed and that
  maintainer wants to rebuild your package against their new one so
  everything keeps working. 

However IMHO for all these cases there should be mention on list,
directly to maintainers, bugzilla, or be completely obvious. 

...snip...

kevin


pgp0NnSPLIKVy.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Jonathan Wakely 

On 03/02/16 08:44 -0700, Jerry James wrote:


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.


I want Fedora to be better.


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.


I don't think that's always realistic to expect.

When a provenpackager is rebuilding *hundreds* of packages at once,
and trying to deal with maybe dozens of build failures, sending emails
to all the package owners and waiting to see if they respond promptly
is not an efficient way to get things fixed. Waiting for a reply adds
a lot of latency, and then you have to context-switch back to a
package you were dealing with a day or two ago. That's impractical
when you have a patch ready to go now and loads more packages to look
at.

Sometimes a provenpackager will make a bad change, and that's
unfortunate, but it happens. Sometimes package owners make bad changes
too! :-)

If I make a bad change to a package please do let me know. If I appear
to change things and walk away it's probably because I've moved on to
look at other packages that also need attention, not just a careless
hit & run. I would expect it's similar for others.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Kevin Kofler 
Jerry James wrote:
> 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.

Looking at:
https://admin.fedoraproject.org/accounts/user/view/jjames
https://fedoraproject.org/wiki/User:Jjames
I see no IRC contact info at all. And you're surprised that people did not 
try to contact you?

Really, it is not realistic to expect people who need to urgently fix 
something to write up a polite e-mail and wait possibly days for you to 
reply (especially if you then answer that you don't want the change and more 
days are wasted going back and forth arguing for why the change is needed). 
Either you are reachable quickly through real-time communication (which 
effectively means IRC in the Free Software world) or you will just not be 
asked.

I always curse when I try to contact a packager and see either no IRC 
contact info, or an IRC nick that is clearly not in active use (last seen 
weeks ago).

> 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.

Patch comments are also overrated. Often, the patch name already clearly 
says what the patch does. (E.g., guess what
kdelibs-3.5.10-CVE-2015-7543.patch is for. :-) That said, I always try to 
add at least 1 line of comments for patches, even in my own packages; the 
particular patch I cited here actually has a 4-line comment.)

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Ian Kent 
On Wed, 2016-02-03 at 18:44 -0700, Kevin Fenzi wrote:
> On Thu, 04 Feb 2016 09:09:33 +0800
> Ian Kent  wrote:
> 
> > I agree.
> > 
> > I believe that package ownership has at least a couple of clear
> > advantages for obvious reasons and I find it hard to understand how
> > people can discount their usefulness.
> > 
> > 1) A point of contact and co-ordination for changes is needed.
> > 
> > Often, when dealing with difficult problems it's necessary to seek
> > advice from maintainers of other packages. Being able to find out who
> > that is and having at least some chance they will be familiar with
> > upstream package status is important.
> > 
> > 2) Taking (even notional) ownership of a package implies there is at
> > least some interest in the package from an upstream POV.
> > 
> > Some (probably many) packages need a packager to take an interest in
> > what is happening upstream. Building relationships with upstream
> > maintainers doesn't always work too well but even that is an
> > important part of knowing what the upstream status of a package is.
> > 
> > This is essential to be able to provide 1) above, someone who has some
> > understanding of the upstream status really is needed to at least
> > help keep our packages as stable as we can.
> > 
> > It's true that package owners don't always have enough upstream
> > knowledge of packages they own or relationships with upstream but
> > that doesn't mean that ownership is a bad thing. After all a point of
> > contact is still needed IMHO.
> 
> I agree with what you are saying, but disagree that anything above
> requires you to "own" packages and guard them from anyone else. 
> 
> You can still be a point of contact and/or interested upstream and want
> to help keep the packages in Fedora high quality and working, but still
> be willing to work as part of the entire collection of maintainers not
> isolated or defensive. We all want to improve things, even if we make
> mistakes doing so. 

Sure, anyone that argues against this is not playing well with others.
But I do feel like my use of "owner" has been misunderstood.

I certainly don't mind if changes are made to packages I look after, it
happens and is mostly not a problem.

So I think the problem being discussed won't be resolved by changing to a
model of not having a package "owner" (however that's defined), it's not
process or policy, it's behavioural based.

That's probably not going to change no matter what efforts are made to change
processes and policy.

So I don't really know what to say to improve matters, sorry.

Ian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Nathanael D. Noblet 
On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote:
> 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.

I can't speak to the rest of the issues you've experienced as I haven't
so far. I became a packager because software I was using on some of our
systems weren't in Fedora/EPEL. I was using them and building them and
figured, 
a) I've always wanted to contribute to FOSS but haven't really been
able to yet. 
b) These are packages that I already have to deal with, might as well
have them in the distro to make life easier and provide them for
others.

Since that first package I'm the point of contact for a mere 12
packages and co-maintainer of 3. Each of those because I was using
something and needed newer versions or what have you. Looking at the
list, there are a number of dependencies on a package I'm the
maintainer of but no longer actively use, however it doesn't change
much so why not keep at it.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Michael Schwendt 
On Wed, 3 Feb 2016 16:04:19 +, Jonathan Wakely wrote:

> When a provenpackager is rebuilding *hundreds* of packages at once,
> and trying to deal with maybe dozens of build failures, sending emails
> to all the package owners and waiting to see if they respond promptly
> is not an efficient way to get things fixed. Waiting for a reply adds
> a lot of latency, and then you have to context-switch back to a
> package you were dealing with a day or two ago. That's impractical
> when you have a patch ready to go now and loads more packages to look
> at.

https://fedoraproject.org/wiki/Provenpackager_policy

 | Provenpackagers should try to communicate with owners of a package in
 | bugzilla, irc or email prior to making changes.

 | They should be careful not to change other people's packages needlessly
 | and try to do the minimal changes required to fix problems, as explained
 | more in depth in the policy explaining who is allowed to modify which
 | packages.
 | -> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages

Even if says "should" two times, Jerry refers to "no prior contact" and
a version upgrade to alpha level software. That doesn't sound like anything
provenpackagers should do within arbitrary packages.

I wonder whether a message at the top would have changed the provenpackager's
mind?

> Sometimes a provenpackager will make a bad change, and that's
> unfortunate, but it happens. Sometimes package owners make bad changes
> too! :-)

You're taking it too lightly. Somebody who performs version upgrades really
needs to take care of a package and incoming problem reports as well.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

2016-02-03 Thread Orion Poplawski 
On 02/03/2016 08:44 AM, Jerry James wrote:
> On Tue, Feb 2, 2016 at 11:30 PM, Pierre-Yves Chibon  
> 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