Distribution quote of the week [LWN.net]

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.

-- Jerry James

to post comments

Distribution quote of the week

Posted Feb 9, 2016 16:45 UTC (Tue) by ovitters (guest, #27950) [Link] (1 responses)

Funny, I package in a different distribution mainly because I'm not the sole owner! I prefer that a group of people own these instead of just me. There's a great tendency to find one owner. As soon as you often touch one package you're assumed to own it. Despite having a ownership list (which can be "nobody"). Unfortunately that list doesn't support groups yet.

I love working with development, but hate the effort that is needed to update something for a stable release. Similarly, QA freezes bore me.

I've tried often to get more people to be involved (e.g. try to get rid of the idea that I'm the owner of something). That hasn't been very successful. Though maybe because I'd assume group responsibility and someone would prefer full ownership (and thus credit)..

Distribution quote of the week

Posted Feb 10, 2016 10:22 UTC (Wed) by jezuch (subscriber, #52988) [Link]

> I've tried often to get more people to be involved (e.g. try to get rid of the idea that I'm the owner of something). That hasn't been very successful.

Debian (as a project) is pushing towards more team-maintained packages. I guess the primary motivation is better handling of maintainers who go AWOL, but (as you already know) there are many advantages to this.

Distribution quote of the week

Posted Feb 11, 2016 15:58 UTC (Thu) by kingdon (guest, #4526) [Link] (1 responses)

Isn't this a case for building/adapting a tool similar to github/gitlab pull/merge requests? That automates the process of "ask the people who care about this package what they think" while also being tied to specific proposed changes.

Distribution quote of the week

Posted Feb 11, 2016 19:59 UTC (Thu) by rleigh (guest, #14622) [Link]

I've found it interesting to participate in homebrew (MacOS X) packaging and BSD ports changes over the last year or so. Both have the complete packaging in a single place, so anyone can propose changes to any component, or even a whole set in one go. The homebrew process is very streamlined, and every change is subject to continuous integration testing, including of all the dependencies to make sure nothing breaks. It's not perfect, but the infrastructure greatly eases maintenance. For example, when I was maintaining a Debian package, I'd have to apply the patches, review, build and test by hand, and then commit to the version control (if any) and upload by hand. Here, you can simply review the pull request, check the CI status, hand test if necessary and then merge. While this might seem trivial, the reduction in personal workload is really significant, and the fact that anyone can participate in the review and testing, as well as open up pull requests directly, is really beneficial.
The BSD ports are a little less streamlined, but even there it's just a matter of checking out the SVN, make and submit the change and later on it's merged (that step isn't quite so automated, though there has been development of Jenkins CI infrastructure).

From the submitter's side, they also make it much more convenient to submit changes and then participate in the review process.

Distribution quote of the week

Posted Feb 17, 2016 12:59 UTC (Wed) by valhalla (guest, #56634) [Link] (1 responses)

In my experiences both extremes of this are bad.

Single maintainers may be good for motivation, but is also really bad from the bus factor point of view.

With big teams or full-distribution mantainers, on the other hand, I've noticed a big tendency to think that somebody else will take care of stuff, which leads to boring tasks being postponed and forgotten.

In my opinion the best model is with small teams, 2 to 10 people for most packages, because in this size it is easier for members to talk to each other, know what is being done, and who should be doing it (and who is the backup if this person can't).

Distribution quote of the week

Posted Feb 17, 2016 16:37 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> In my opinion the best model is with small teams, 2 to 10 people

Funny you should mention that because one of the points in the Mythical Man Month is that teams don't scale, so small teams work best, his recommendation of 10-person teams includes QA and documentation writers as well as developers.