MOTU Application for kirkland [Was Re: Universe Contributors application for Dustin Kirkland (kirkland)]
dustin.kirkland at gmail.com
Thu Aug 14 22:20:40 BST 2008
On Thu, Aug 14, 2008 at 3:29 PM, Stefan Potyra <sistpoty at ubuntu.com> wrote:
> On Thursday 14 August 2008 22:08:08 Dustin Kirkland wrote:
>> There are numerous other packages that are important for the Ubuntu
>> server, but are still under development; tomcat, augeas, ebox, come to
>> mind. Universe provides a beautiful place for these packages to live
>> and even thrive while we (and upstream) get them in shape for Main.
> ok, being both blunt and picky I'd take this statement as "universe is a base
> to build real stuff upon". Do you agree?
"build real stuff upon" are your words, not mine. Written that way,
my words have been twisted to marginalize Universe packages. That's
neither my belief, nor intention.
"All of this software is compiled against the
libraries and using the tools that form part
of main, so it should install and work well
with the software in main, but it comes with
no guarantee of security fixes and support.
The universe component includes thousands
of pieces of software. Through universe,
users are able to have the diversity and
flexibility offered by the vast open source
world on top of a stable Ubuntu core.
"Canonical does not provide a guarantee of
regular security updates for software found in
universe but will provide these where they are
made available by the community. Users should
understand the risk inherent in using packages
from the universe component.
"Popular or well supported pieces of software
will move from universe into main if they are
backed by maintainers willing to meet the
standards set for main by the Ubuntu team. "
I believe it to be a noble and valuable service to all of the Ubuntu
community (Canonical customers and those who are not), for an Ubuntu
Contributing Developer to work on the security, functionality,
supportability, and packaging of some particular project(s) in
Universe, promoting that package to the Main, formally and longer-term
I have done this with the ecryptfs-utils suite. And I hope to
continue to do so on other server packages more efficiently and more
broadly as a MOTU.
> Also, I might have failed to express the real question: What do you think
> about the interactions between MOTU and ubuntu-server? Could or should these
> be improved?
A number of active ubuntu-server members are also active MOTU. The
following people come immediately to mind:
* dendrobates, emgent, jdstrand, kees, mathiaz, nxvl, scottk, soren,
zul (among others that I'm sure I have forgotten)
I see interaction of myself and other members of the server community
members interfacing with these MOTU and other MOTU on a daily basis.
Perhaps more so in #ubuntu-server than #ubuntu-motu?
I don't think I perceive the issue you are driving at...
>> And I would not expect the fact that Canonical employees are
>> compensated for their work on Universe and Main to negatively impact
>> the Council's recognition of that work.
> And that's equally fair imho! Do you think that's the case right now? or
> during past applications?
>> I would evaluate such exceptions on the overall cost-to-benefit ratio
>> of the change, with my approval threshold steadily rising between
>> Feature Freeze (28 Aug) and Beta Freeze (25 Sep).
> Can you give more insights how you'd come to this cost-to-benefit-ratio? (I'm
> particular interested, since I can't say that I've figured out that ratio
> myself yet, and would welcome any hints).
The suggestions below are by no means an exact science, but could
certainly help generate the appropriate discussion regarding such
* Is the patch acceptable upstream? Approval of the fix by upstream
validates the issue from another knowledgeable party, and lowers our
long-term cost of ownership (ie, carrying patches).
* Is the patch already upstream? If so, this drastically lowers the
cost, as we would inherit validation of the fix by the maintainers of
the code, as well as their other base of consumers (other distros,
* What are the possibilities for regressions? Chances of regression
increase the cost.
* What packages depend on this package? A regression in one package
can trickle down to cause regressions in other packages. A saturated
dependency tree increases the cost.
* How popular is the package? Perhaps estimate with
http://popcon.ubuntu.com/ Fixing a bug in a popular package raises
* How proliferate is the problem? A high number of duplicate bugs in
Launchpad, or a high number of comments in a bug could raise the
* Is the fix a complete fix, or only a partial fix? A hack? A
stop-gap measure? Complete fixes raise the benefit. Partial fixes
may lower the overall benefit, but the associated cost of a partial
fix must also be considered.
More information about the Motu-council