Minutes from the Technical Board meeting, 2009-02-24
Apologies for the late sending of this, I had it all ready to send last
Wednesday (with Maria's help) but it got stuck in my Outbox!
= Attendees =
* Matt Zimmerman (chair)
* Mark Shuttleworth
* Colin Watson
* Scott James Remnant
= Minutes =
== Should firstname.lastname@example.org be public? ==
* Technical-board@ serves two purposes:
1. a contact address to reach the TB (and only the TB)
2. a mailing list to discuss TB matters
for 1., a private list is appropriate, but for 2., it is not.
* Currently, the Technical Board is responsible for the following
documents and processes:
1. The Ubuntu Package Policy,
2. Ubuntu Release Feature Goals,
3. Ubuntu Package Selection,
none of that stuff should be private, however there needs to be a
quick, easy and memorable way to talk privately to or among the TB.
* No objections to subscribing select people to the TB list who are
also participating but not actually on the TB. It was also
reaffirmed that where possible, we should shift discussion of public
matters from t-b@ onto ubuntu-devel@
The TB will stay private so long as we only use it for discussions
which ought to be private, and nothing else e.g. if someone emails
technical-board@ and raises a technical concern, we must redirect
that to ubuntu-devel@.
== MOTU Council list of nominees for MOTU Council Election ==
* Appointments to the board are made by Mark Shuttleworth subject to
confirmation by a vote amongst the maintainers
* The CC (and TB) will determine a shortlist of candidates and set up
Launchpad polls accordingly so team members can vote.
* The polls might take the form of confirmation votes or of a race
between more candidates than the available seats on the Team Council.
MC has been well organised, growing it gives an opportunity to
develop more leadership talent so 2 other seats will be added.
* The three nominees are: Daniel Holbach, Nathan Handler, and Jonathan
ACTION: sabdfl to set up Launchpad polls including per-package uploaders
for MC nominee confirmations
== SRU guidelines for Landscape ==
* Sometimes, the Landscape client code must be updated to take
advantage of improvements/updates to the Landscape server...and this
is their reasoning for the need to be part of an SRU.
* The reasons why Landscape is suitable, given the negotiations to
- it has an extensive test suite (yes, like other packages in the
- its developers have committed to doing specific QA on a variety of
upgrade and fresh-install combinations
- it has very limited interactions with the rest of Ubuntu, that are
straightforward to enumerate so that we can have a clear idea of
- those interactions have been specifically called out in the
mandatory QA process that each upgrade must go through
- its developers have agreed to work within the Ubuntu update
* Landscape developers originally raised:
* We want assurance that the potential impact is limited, and that the
testing conducted is sufficient to provide the level of assurance we
expect for stable updates.
* We've entrusted the SRU team to assess the QA aspect and will review
that ourselves as well based on the document that outlines the
criteria we used to make the decision and includes the sentence ("the
TB will consider additional applications in due course following
ACTION: cjwatson to write up a formal decision which the TB can then
== Upload permission for Romain Francoise for 'emacs-snapshot' ==