Future of MOTU

[Iain Lane]

Hiya all,

Thanks to Emmet for raising these important issues.

On Mon, Feb 22, 2010 at 12:53:09PM +0900, Emmet Hikory wrote:
>Fellow MOTU,
>
>    During the Jaunty UDS, discussions of Archive Reorganisation (0)
>indicated that MOTU would be no more, and all of us should have
>received a request for feedback as to how we wished to proceed with
>our individual roles in Ubuntu Development.  This work was met with
>wide apathy, and some confusion.  At the Karmic UDS, discussion of the
>future of maintenance of those packages not belonging to specific
>teams was discussed, with the conclusion that it would be sensible to
>maintain a development team dedicated to the maintenance of these
>packages, resulting in a specification (1) that has now been approved
>by the Developer Membership Board (2) and Technical Board (3).  As a
>result, we now have a new mission, summarised as:

I suspect I am not alone in agreeing that the announcements were 
confusing. A lot of the documentation and specs still refer to 
"generalist developers", which does not help when scouring the wiki to 
find out what the current situation is.

>
> [...]
>
>    There remain several areas for action in order to fully realise
>the new MOTU role, as follows:

I'll only address the areas where I have comments in my response.

>A) Leadership
>
>    We have historically been broadly without hierarchy, nominating
>and recognising some of our number as leaders (5) as a result of their
>continuing efforts in some area that directly improves the health of
>the team.  On quick review, our leadership page is out of date, and
>many of our leadership roles no longer have clear meaning as
>ArchiveReorganisation continues.  While each item deserves discussion,
>I'd like to suggest the following:
>
> [...]
>
>ii) Coordinate with all the other Ubuntu Developer Teams to set up a
>distribution-wide REVU Coordination team, with representatatives from
>each development group helping to ensure that packages of interest to
>each area are well tracked, and REVU again becomes considered a useful
>tool.  I'd like to call on the REVU Hackers to support this team,
>potentially extending REVU to better support tracking of "claimed" vs.
>"unclaimed" packages, etc.  The current tags functionality may be
>enough, but it may not.

We are very bad at proactively reviewing new packages on REVU, and 
almost as bad at responding to requests for reviews which we very 
frequently receive on IRC, and less frequently receive on the ML(s). 
Just take a look at the number of packages in the "Needs Review" state. 
I feel that we may be creating a somewhat unfair expectation that there 
is a simple path from .dsc to the Ubuntu archives, when in reality we do 
not have anywhere near the manpower required to make this as smooth as 
it may seem.

In addition to that, it is sadly often the case that once packages are 
accepted into the Ubuntu archives, they are thereafter unmaintained. It 
is encouraged that the intial uploader subscribe to the bug traffic and 
maintain the package, but our development model cannot enforce this.

All other than the most extraordinarily stable packages (which generally are 
not the ones that come in through REVU) need an active maintainer. This 
is something which we get "for free" with our packages that come from 
Debian.

I have heard it said by members of other teams within Ubuntu that REVU 
is not useful to their workflow, and that they manage to work perfectly 
well at reviewing their own packages without it. Such reviews tend to be 
conducted by members of the team. I doubt whether it would be feasible 
to coax other (primarily Canonical) teams over to using REVU, or even 
that there would be a benefit to doing so, as these reviewers are not 
likely to start taking packages from the "general" queue.

Sadly I don't see a pleasant way out of this, given that we are not 
likely to be able to solve the primary problem of having willing 
reviewers. I therefore think that the most palatable option will be to 
increase the barrier of inclusion for Ubuntu local packages. 
Contributors should be required to demonstrate that they have attempted 
to get their package into Debian first, probably through the appropriate 
packaging team. MOTU, as they have a stronger link to the distribution, 
could be permitted to upload their own NEW packages given the usual 
additional positive review. This should not preclude the forward 
progress of the distribution, and in the inevitable cases where a NEW 
package is of clear importance for inclusion in a release, this could be 
allowed given a named MOTU who is willing to take responsibility for 
ensuring that the package is kept in good shape (primarily through 
nudging of the contributor). Anyone sufficiently motivated — not just 
creating a vanity package — should be able to get their work in through 
one of these routes: either taking up maintainership in Debian, or 
convincing a MOTU that their package is good enough. In this vision, 
REVU would become more like mentors.d.n, a purpose that I feel it is 
well suited for.

>iii) MOTU SWAT needs help, especially as it moves from "universe" to
>"unseeded packages".  I believe that extended discussion is worthwhile
>between the MOTU SWAT team and the Ubuntu Security team to determine
>if all security efforts could follow a standardised process and be
>handled by a single extended team (with some potential for separation
>within the team to support embargoed information, disclosure
>requirements, etc.).  If MOTU SWAT is to remain separate, some work
>will need to be done on the tools to help better track what packages
>need attention and when.

As an outsider, it seems to me that this team lacks coordination, and 
would benefit from being under the Ubuntu security umbrella so that the 
engineers working there can effectively delegate the required security 
work for Universe packages. With proper work tracking, I can see this 
being a successful collaboration.

>
> [...]
>
>viii) There is current activity merging the MOTU Release Managers with
>the Ubuntu Release team.  Much credit to the good work done in the
>past, but I think we will benefit more from a single coherent team
>than having a separate set of delegates, such that Ubuntu Release
>members drawn from MOTU ought not be seen as having any special role
>with MOTU, but rather a special role within the whole of Ubuntu.
>
>ix) The MOTU Stable Release Update Supervisors is now an obsolete
>team, there being an integrated process for stable release updates
>distribution-wide.  Unless there are objections, I suggest we drop
>this team from our leadership page.
>

These are both positive developments, so long as community members of 
the teams are and continue to be welcomed on equal terms with Canonical 
employees.

The documentation again needs to be cleared up to reflect the now 
unified process across the whole distribution. I hope that each team can 
take an action to do this. (particularly the release team's Feature 
Freeze Exception page. It's not clear how much of motu-release's old 
policies — no FFe for bugfix only uploads, for example — still apply).

>
> [...]
>
>B) Governance
>
> [...]
>
>    My personal feeling is that the model has become overly weighted
>due to procedural requirements and confusion, and while strong in
>intent, needs overhaul to meet our needs in the future.  While all
>sorts of models should be available for discussion, I'd like to
>suggest the following:

Yes. I suspect this is one of the reasons for the decline in meeting 
frequency and ML traffic; it is too hard to get anything done.

>
>i) Retain MOTU Leaders as those who we recognise as having special
>drive, expertise, and activity in specific areas, and continue to
>grant these MOTU special authority to set guidelines and best
>practices related to their area of expertise.  I think this has worked
>in the past, and provides a dynamic force for helping us to know how
>to accomplish many of our goals.  I'd like to add an expectation that
>those MOTU recognised as Leaders report regularly (say monthly) to the
>rest of MOTU on their activities and plans, firstly to encourage other
>MOTU to participate in that area (and provide for backup/turnover as
>individual interests shift), and secondly as a way to help identify
>when Leaders are not making progress, and may need assistance or
>support in their sphere of operations.
>

Right. I would like to specifically include the release and SRU teams 
here. The SRU team in particular seems to have problems dealing with the 
backlog of bugs awaiting approval (I saw some personal pinging take 
place on IRC just yesterday). Regular reporting on progress, and calling 
for help, could assist here.

>ii) Revive the MOTU Meetings on a regular rotating schedule (I like
>22:00, 6:00, and 14:00 UTC with a meeting every week, rotating over
>three weeks).  While I'd like to retain the power of MOTU Meeting to
>establish policy, with Archive Reorganisation, there is much less
>policy that is necessarily MOTU-specific, and we would likely benefit
>from use of the meeting to also discuss other areas (transitions, QA
>efforts, sets of packages with lots of bugs, requests for help with
>specific things, blocking issues, coordination with distribution-wide
>teams, etc.).  To facilitate this, I'd like to suggest that not all
>agenda items need the full announce/meet/shepard process, but rather
>that the sheparding process only be used where policy is specifically
>being adjusted (and only in cases where policy is entirely specific to
>MOTU: many policy issues are better brought to the Technical Board).
>A regular meeting with publised minutes also serves to keep all MOTU
>informed of activities, even when they may not be able to track IRC
>closely or follow various bug reports.

This is probably a good idea. I am personally leading a Haskell 
transition that it would be good to bring up at such a meeting, and I'm 
sure that others have similar projects on the go too.

I am having trouble thinking what policy aspects remain that would be 
best decided by MOTU though. It seems to me that everything would be 
referred to one of the leadership teams. Does anyone have any examples?

>iii) Establish a MOTU Council with explicit responsibility to oversee
>MOTU Leaders, facilitate MOTU Meeting, and resolve disputes within
>MOTU.  I would also expect this team to coordinate with the Community
>Council, Developer Membership Board, and Technical Board for any cases
>where there is confusion or conflict between MOTU policies or
>practices and distribution-wide policies and practies, with explicit
>mandate to seek alignment of any MOTU policies or procedures with
>distribution-wide policies and procedures.  I would like to explicity
>restrict this council from setting policies, guidelines, or best
>practices directly, excepting that individual members may have
>authority to do so as MOTU Leaders, participants in MOTU Meeting, as
>individual MOTU, or due to other distribution-wide roles.
>

If we are to be having regular MOTU meetings once more, there could be a 
role for the council in bringing forth policy discussions for approval 
where they otherwise would have decided themselves. The MOTU meeting 
then acts as the legislature of sorts.

>
> [...]
>
>C) Communication
>
>    There's been less and less traffic on the MOTU Mailing List, and,
>to my impression, less coordination discussion on the IRC channel (it
>seems largely devoted to training and chatting).  I feel that in order
>to maintain a sense of "team" and in order to best get things done, we
>would do well to better communicate with each other about what we are
>doing, and what we plan to do.  So, please speak up.  Let others know
>what you are doing, what you think, or if you need help, or if you're
>bored and have time to help someone else.

I do wonder sometimes whether the training discussions that so often 
take place on IRC put people off from discussion other matters.

>
>    Further, as our new role has been defined in parallel to Debian
>QA, let's put more effort into communicating with Debian QA, and
>coordinating our efforts.  As MOTU, we do a lot of work on packages
>that are only maintained by Debian QA (as they don't have proper
>maintainers in Debian, so bugs tend to accumulate).  To avoid
>duplication of effort, we should be aggressively seeking to keep these
>packages in good shape *also* in Debian, just to avoid the effort of
>merges (as there are few packages in this category that truly require
>Ubuntu variation).
>

There could be an MOTU-Debian (QA?) liaison, as one of our MOTU leaders.

>D) Coherance
>
>    In the past, some people viewed MOTU as a "first step" towards
>getting involved in another area of Ubuntu Development.  Others with
>narrower interests would join MOTU as the only option to be able to
>work on e.g. scientific packages.  With Archive Reorganisation, we now
>have significantly extended facilities to provide for flexible access
>control.  All of you should have received a query asking what sort of
>Ubuntu Developer you were interested in being in the absence of MOTU.
>To help the coherence of MOTU as a team, I'd like to request that
>those of you with narrower specific interests request the
>identification of packagesets to cover your interests: this may be of
>especial interest to those teams who coordinate closely with Debian
>(e.g. Pythonistas or Games).  Where there exist teams with narrow
>interests, let's get package sets established.  Please sign up to be
>as many types of Developer as you'd wish, and identify all the
>packages that *do* have teams that care for them.  Those of you who
>wished to focus on specific flavours, please seek to join (or define)
>flavour-specific teams.  Those of you who wished to become core-dev,
>please apply.  Those of who who have upload access to all your
>packages of interest by other means, please consider whether you wish
>to continue as MOTU under the new definition.

Bear in mind that there is still a very useful QA role to be played by 
MOTU (as highlighted above), so people should not feel pressured into 
stepping down or stepping aside into a more limited role if they feel 
they still wish to work towards the MOTU goals.

>    Let's focus on identifying the true set of packages that *need*
>MOTU attention (due to not already having a maintenance team), and
>helping to identify which of us have a real interest in working to
>improve those packages.  With this increased focus, we should be able
>to do a much better job of keeping the entirety of the archive in good
>shape for each release, and ensure that Ubuntu remains an incredibly
>flexible, dynamic, rich, and powerful software collection into the
>future.

Are there any guidelines on what should be in a package set? As one of 
our goals is/should be to reduce divergance with Debian where possible, 
I wonder if it would be possible to begin to establish package sets 
along the lines of those packages maintained by Debian teams. As Ubuntu 
developers are encouraged to give back to Debian, so we could encourage 
Debian developers to give to Ubuntu by being able to push their fixes 
directly. Obviously each team will need one or (preferably) more Ubuntu 
developers to act as managers, but I think this couuld work. This would 
also provide inroads for new contributors with more specialised 
interests. I believe that we could come up with a policy for such teams 
that would work well (perhaps even applying to the DMB?)

 From my own experience, I would be interested in creating a 
pkg-cli-{apps,libs} package set. Developers (myself included) who were 
interested in working in Debian but seeing their work in Ubuntu 
previously went down the MOTU route to facilitate this, but given a 
larger number of more focused sets, would be able to carry out their 
work with less fuss.

>    Thanks for reading the entirety of this: please criticise,
>commend, amend, adjust, and discuss: let's make MOTU strong again!

I hope that my incoherent thoughts made sense.

Cheers all,
Iain

>
>0: https://wiki.ubuntu.com/ArchiveReorganisation
>1: https://wiki.ubuntu.com/Specs/LucidMOTU
>2: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000672.html
>3: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000673.html
>4: https://wiki.ubuntu.com/ArchiveReorganisation/Permissions#Nomenclature
>5: https://wiki.ubuntu.com/MOTU/Leaders
>6: https://wiki.ubuntu.com/MOTU/School
>7: https://wiki.ubuntu.com/Packaging/Training
>8: https://wiki.ubuntu.com/MOTU/Mentoring
>9: http://qa.ubuntu.com/reports/sponsoring/
>10: https://lists.ubuntu.com/archives/ubuntu-devel/2010-February/030194.html
>
>-- 
>Emmet HIKORY
>
>-- 
>Ubuntu-motu mailing list
>Ubuntu-motu at lists.ubuntu.com
>Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20100222/3156b502/attachment.pgp