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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
signature.asc
Description: Digital signature
-- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
