Future of MOTU

Jamie Strandboge jamie at canonical.com
Mon Feb 22 16:58:12 GMT 2010

On Tue, 2010-02-23 at 00:28 +0900, Emmet Hikory wrote:
> > Due to limitations in Launchpad, MOTU-SWAT still needs to be a separate
> > team from ubuntu-security (this is due to the ubuntu-security PPA
> > containing embargoed items and the fact that you must be a member of
> > ubuntu-security to publish from this PPA to the security pocket). We've
> > long wanted MOTU-SWAT to be able to manage themselves and we can
> > help/comment on procedures when the LP limitations are gone.
> >
> > That said, with the help of various MOTU folk[1] we identified
> > improvements in the security sponsorship process and have implemented
> > changes to address them and make our processes more like other teams[2].
> > The ubuntu-security-sponsors team was created, which MOTU-SWAT is a
> > member. Links for the security sponsorship processes are also integrated
> > into the the main SponsorshipProcess[3], just like with other teams.
> > Each week a member of the ubuntu-security team is assigned to process
> > bugs in our SponsorsQueue. So far, we've been doing all review as well
> > as publication, but MOTU-SWAT can get involved in the review process
> > which is really the most important part (while the ubuntu-security team
> > is required for publication, this is simply a matter of copying packages
> > around).
>     This matches my previous understanding that security was still
> tracked on a component basis.  While we still will have components for
> a while, I am expecting that we will have a growth in packagesets in
> the medium-term, as the various teams who already care for loosely
> defined packagesets request formal recognition from the Technical
> Board.  With this change, the set of packages for which MOTU will have
> explicit responsibility will be reduced, and there may end up being an
> increasing gap between the union of "main" and "unseeded packages" and
> coverage of the entire archive.  As a result, I'm not confident "MOTU
> SWAT" remains an ideal identity for the set of people working on
> security who don't have rights to pocket-copy packages to -security.
> Also, while I admire the work the security team has done, I think that
> it likely makes sense to reach out to all the defined development
> teams (Ubuntu Desktop, Kubuntu, Mythbuntu, MOTU, potentially Edubuntu
> if approved tomorrow, etc.) to seek additional assistance with patch
> review, publication to the current development release, and
> backporting to prior releases.
>     As Archive Reorganisation moves forward, and components go away
> entirely, I expect this becomes even more complicated, but I still
> think that it is handled better by an integrated ubuntu-security team
> (perhaps with only a subset authorised to pocket-copy) distribution
> wide than by having a central "core security team" and additional
> representative teams for each packageset providing security.

Historically, the ubuntu-security team is comprised of Canonical
employees only. It is the team that is responsible for officially
supported packages in main and restricted. Moving forward, the
ubuntu-security team will have a list of packages which are supported
(we obviously have to) if/when components go away entirely. While anyone
can submit a patch for a supported package, a member of the
ubuntu-security team will need to perform the review, testing,
publication and USN. I don't really see this as something that should
change, but that of course doesn't mean that ubuntu-security can't work
with other teams providing security support! :)

For community supported packages, in the current process anyone can
submit a patch for a security update with ubuntu-security-sponsors
reviewing them and ubuntu-security publishing ACKd patches.
ubuntu-security only has to be involved at all due to LP limitations,
but performing the shuffling around is not a huge issue atm.

We currently do reach out to the other teams on an individual basis,
though as mentioned in this thread, there is more that can be done with
coordination regarding community supported packages. For now that team
is MOTU-SWAT and moving forward we will work with whatever teams and
processes are in place for this. Ultimately, I see the handling of
community security as a function of the community. Ie, MOTU (or whatever
it will turn into) should define its own processes for dealing with
security updates, but IMHO all that really needs to happen is that
people need to get involved with provided patches and joining
ubuntu-security-sponsors to get them reviewed.

Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20100222/e70b3984/attachment.pgp 

More information about the Ubuntu-motu mailing list