Future of MOTU

[Emmet Hikory]

Iain Lane wrote:
> Emmet Hikory wrote:
>> A) Leadership
<...>
>> 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.
<...>
> 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.

    I know that at least some of the other teams use REVU (Kubuntu-dev
being a particularly prolific example), and I think that wider
adoption would either improve the tool, or otherwise foster discussion
about good workflows for peer review of NEW packages entering the
distribution.  I don't think that MOTU should have any special role
with REVU, but raher that it should be open to all Ubuntu Developers,
of any type.  I'm also not convinced that there is any obligation to
"clear the REVU queue", although in the spirit of collaboration, we
ought make an effort to review each other's packages (I've seen
packages prepared by active Ubuntu Developers sit there for months).

    I think that if we consider REVU a tool to support peer-review of
NEW packages, and work with all Ubuntu Developer teams to build a
strong common workflow (which may include REVU), we would do better
than by attempting to establish a set of restrictive policies.  We may
end up with a greater number of packages that are unreviewed, or end
up using tags to only track sets of packages, but while I've seen
vanity packages, I've also seen a number of packages that are
presented by otherwise new contributors that are essential to goals
for some team: let's focus on having REVU enable and support positive
activities, rather than restricting what can be done or what should be
done with REVU.

    We would do very well to improve the documentation around this
area.  I'm not convinced new packaging is a useful way to learn to
package: for some packages it's trivial to make a working package, and
for others it's a mess.  As a side effect of our documentation
attempting to introduce those we wish to have help us fix bugs to all
possible variations of packaging, we end up with many packages on REVU
being very complicated, or as outdated as our documentation.  While
these packages *can* be massaged to be policy compliant, I'm not sure
they represent best practices, nor that those attempting to learn
packaging through preparing new packages are well served by the REVU
process.  We have always had a backlog of outstanding bugs: we
probably ought do better to suggest that those wishing to join us work
on bugs, and bugfixing.  This will expose them to a variety of
packaging (which our packaging documentation can help them
understand), and also help reduce our future workload (especially if
these new contributors are encouraged to share their fixes with
various upstream sources).

    I'm also not convinced that simply getting a package through REVU
and having an interested person in Ubuntu is suffiicient to assure
close maintenance: I know that there were two packages I requested not
be removed during the mass-unmaintained-package-removal earlier this
cycle because I care about them, but this has yet to result in me
uploading them to either Ubuntu or Debian (although the sources are
unpacked locally waiting for my attention), simply because I don't use
these packages nearly as much now as I did in hardy (although I still
know of no replacements).

    That all said, I still think that we ought not retain the
responsibility of NEW package review to MOTU, and that all of Ubuntu
is better served by having a distribution-wide team coordinating this
(and would expect that team to then take responsibility for best
practices in dealing with NEW packages).

>> B) Governance
<...>
>> 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.

    I'd like to explicitly not include these teams as "MOTU Leaders".
I really think it's better to have distribution-wide coordination.
The Release Team has a meeting every Friday (I think it's 16:00 UTC)
which provides fairly good oversight of the process, although I don't
know if minutes are posted anywhere.  There is a report on SRU
activities during the weekly QA Meeting, including test results,
current status, etc.  I think these are much more appropriate fora
than a monthly summary to MOTU.

>> ii) Revive the MOTU Meetings on a regular rotating schedule
<...>
 (I like
>> 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).
<...>
> 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?

    I expect Leaders to just go off and do stuff.  Sometimes the
entire body of MOTU doesn't want them to do that, or things change
quickly enough to be confusing.  I'd rather that the Leaders were
unable to set any sort of official policy, but raher just defacto
policy through best practices.  In cases where we need to establish
some delegation or policy, I'd rather have that be MOTU Meeting.  An
example from the past was that MOTU Meeting decided that some of the
MOTU Leadership teams (specifically -sru and -release) needed to have
a public commentary period before changing membership.  This no logner
meaningfully applies, but I would imagine that other cases may arise
where some policy would only apply within the team.  I think that the
model of judging consensus we have is very powerful (if complicated),
and serves to ensure that we only end up with policies that are useful
(and specifically that we don't end up with too many)

    My fear in completely delegating policy to the Leaders is that we
end up needing to invoke disputes to call the Leaders to heel if some
activities are not met with acclaim: I'd rather be able to set
policies to guide the leaders to ensure we are all moving towards a
common set of goals.

>> iii) Establish a MOTU Council with explicit responsibility to oversee
>> MOTU Leaders, facilitate MOTU Meeting, and resolve disputes within
>> MOTU.
<...>
> 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.

    I'd rather retain the introduction of discussions to the several
MOTU than delegate to only MOTU Council.  Otherwise, MOTU Council
tends to get involved in internal discussions with insufficient
transparency (and I would not have been empowered to start this
thread).  In terms of Walker's separtion of powers, I consider the
Leaders as "Governing", the Meeting as "Legislative", and Council as
"Judicative".

>> C) Communication
<...>
>>   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.
<...>
> There could be an MOTU-Debian (QA?) liaison, as one of our MOTU leaders.

    We've had one before, and can certainly have one again.  It just
needs someone to volunteer to fill that role.  I'm certain I speak for
many of us in saying that this person would garner great respect for
doing so.

>> D) Coherance
<...>
> 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.

    My apologies if I implied any pressure: I strongly encourage
anyone who wishes to be MOTU to remain so (but perhaps also consider
additional roles).

>>   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?)

    I don't know of any firm guidelines, but I believe the packages
are expected to be related in some way and have some team interested
in specialising in that area.  I don't think we should make any effort
to align with team structures in Debian, except in cases where this
has already happened naturally: the social dynamics are sufficiently
different that it may be that the reasons for some team separations in
Debian don't make sense in Ubuntu and vice-versa.  I would expect that
if some integrated team of Debian and Ubuntu Developers approached the
TB and requested the creation of a packageset it would be approved,
and I imagine that responsibility for approving members of the
development team associated with this package set would initially be
delegated 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.

    Indeed.  Part of the rationale of Archive Reorganisation is
precisely to enable teams like this.  Please do create it, as it both
increases assurance that a given set of packages is well maintained in
Ubuntu and decreases the set of packages for which MOTU is
responsible.  Having done so, I'd hope you'd consider yourself both a
CLI developer (or whatever it gets called) and a MOTU, and continue
work in both areas.

-- 
Emmet HIKORY