Proposed new release team member

[Dave Walker]

On Thu, Aug 25, 2011 at 02:12:38PM -0700, Steve Langasek wrote:
> Hi Dave,
> 
> +1 for adding you to the team.
<SNIP> 

Great!  Thanks.
 
> In addition to protecting *other* teams from the knock-on effects of feature
> work, one of the purposes of Feature Freeze is to help the team itself make
> the right trade-offs between ongoing feature development and bug fixing to
> ensure *their* product has a high-quality release.  Even when a feature
> getting an exception is rock-solid and doesn't introduce any regressions,
> time spent implementing / landing that feature after FF is time not spent
> fixing bugs.
> 
> As technical lead for the Ubuntu Server team, you'll be rather close to some
> of the features for which your team is seeking freeze exceptions.  When a
> feature misses Feature Freeze, how will you navigate the tension between
> delivering features that are important to your team's roadmap, and the need
> to focus on fixing bugs to keep release quality up?
> 
<SNIP>

Firstly, I'd like to clarify that it's not my intention to only care
about the Ubuntu Server issues, same as I imagine you do not only care
about Foundation issues when representing the Release Team.

I think really, this is a case-by-case basis.  I would imagine it
differs very little to the concerns members of the release team which also 
have a comparable position on other teams within Ubuntu.

Having already had to bring out the feature-reaper for the last two
cycles, I am accustomed to compromising features for both feasibility
and stability.

The details I provided in my previous mail I believe are relevant to
this point.  It mainly comes down to confidence in the options
available. 

If I am confident that a feature can be satisfied by those committed 
to working on it, without taking their valuable knowledge and 
experience away from other known or yet to be discovered issues; then 
it would be unfortunate not to progress on a feature.

I'm well able to determine if my judgement is compromised by trying to
juggle multiple hats; if this is the case, then it's only natural to
discuss concerns with others involved - including the developers,
flavour manager and fellows of the release team.

We also have a pretty well defined process for handling incoming bugs,
and tracking those that are pertinent to release.  Depending on the
weight of the list, depends how features might need to be dropped or
restricted in breadth.

Currently, once an FFe is approved - there isn't much of a feedback
loop to the release team to ensure it's still on track for delivery.  
For actions within my team, I am well placed to cover this gap.

I appreciate that it's not simply a case of giving an 'Ack' on a
feature, but following it to completion.

Over the years, a number of decisions have been made during the
development cycle; that with hindsight have turned out to be a mistake
or a poor gamble.  This, whilst hoped to be rare, will happen and
includes the mysql-server (5.1.30really5.0.75) debacle.  As a release 
team member with a strong interest in Server, I am well placed to be 
able to catch these issues early and make help lead action to make
sure we have a good release.

TL;DR - It's a judgement based compromise.

HTH

Kind Regards,
Dave Walker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20110826/e086e8ea/attachment.pgp>