Future of MOTU

[Stefan Ebner]

On 22/02/10 15:06, Iain Lane wrote:
> 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.
>

I totally agree, there was a lot of confusion and still is going on.
It should be easier to distinguish between Draft/Discussion and already 
accepted new Policy.


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

I think everyone knows that the current REVU situation is not really 
satisfying. I'm not sure how the "raise the barrier" is meant but here 
are my thoughts:
I'm of the opinion that there are currently 5 possiblities:

1) Shutdown REVU completely
2) Keep REVU as it's now
3) Only MOTU are allowed to upload and a second MOTU reviews and uploads it
4) Universe Contributors or any other active contributor/uploader does a 
review and when he is happy he gives his +1 which puts the package into 
another stage where MOTU review (and upload). This would decrease the 
time MOTUs have to review packages with a very poor quality (dh-make)
5) Get a NEW package uploaded (either through the current way or 4) ) 
and then use our Debian contacs (MOTU-Debian liason) to get it uploaded 
into Debian in the same turn which you decrease unmaintained packages 
(hopefully)

>
>> 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 agree with Iain that MOTU meetings should be revived but the got lost 
because of lack of topics. I think a weekly meeting is a little bit too 
much as not that much happens imho.

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

You see a name from time to time and that is "Generalist Developer" 
which is more or less the same as the current core-dev. Applying for 
core-dev is a lot of responsibility, everyone agrees on that. Emmet 
stated that we should join as many package sets as we want.
If you have a wide range of interests and are MOTU you don't really have 
a problem joining all the package sets you want. I think many MOTUs or 
other contributors are doing work in many areas (python-apps, games, 
etc) and as main and universe will disappear I'm seeing following problem:
Being in most package sets is nearly the same as being 
core-dev/generalist developer but the barrier of is much lower.

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

Being also such a "Developer" I totally agree with Iain :)

Greeting,
	Stefan