Proposed new release team member

[Dave Walker]

On Wed, Aug 24, 2011 at 02:11:57AM +0200, Stefan Potyra wrote:
<SNIP>
> 
> Given that, I'd like to ask you a question:
> 
> Considering, that an FFE is requested for a server/cloud-related library.
> What would you check for the update?
> What questions would you ask regarding the FFE?
> 
> Cheers,
>    Stefan.

Hi Stefan,

Good questions. :)

However, I'm not entirely sure they can be answered in a prescriptive
manner, as otherwise the job of the release team would be better
defined, like AA and SRU's seem to be.  I will try my best to answer
in generic terms.

Probably one of the first things I think is reasonable to consider is
impact on other flavours of Ubuntu, and with that possible issues it
might cause for other developers outside the use case that is being
addressed in the FFe.

Is the Feature a shiny new toy, or something that is genuinely
required for a good release?  The deeper into the cycle we progress,
the higher the standards for the second element are to satisfy. 

In addition, a release team ack has the potential to cause instability
and more work for others; which might not have been expecting this.
This needs to be carefully communicated and managed to avoid surprises,
and frustrations.

In the case of a new upstream release which introduces features, then 
i'd look at how much confidence I/We have in the upstream for 
stability. 

This is based on:
 - Prior experience with the package / upstream
 - Code quality
 - How long the release has been in the wild, gaining confidence with
   lack of upstream (or other distro) reports.
 - Unit / functional tests that are applicable.
 - Compatibility with it's reverse depends (including potential ABI
   changes)
 - If the package is in main, does it introduce new build / run
   depends that need will MIR review?
 - Does it require new (or newer) depends?
 - If the change is coming in via a Debian sync/merge, and it's in
   experimental - why?  Does the Debian maintainer have low
   confidence?
 - If we are jumping ahead of Debian, is a team or person likely to
   have the time and knowledge to be able to support it well?

Two FFe's that have been causing me great concern for this very reason
is:
 - qemu-kvm- [FFE] Upgrade qemu-kvm for oneiric to version 0.15 from 
   upstream. (LP: #827831)
 - libvirt - [FFE] Merge 0.9.3-5 from debian unstable. (LP: #828792)

The reason these two are giving me concern, is that it is really rather 
late in the cycle to change two things that we rely *heavily* upon.  I
appreciate that Server is probably the largest consumer of those two
packages, but it's not something i'd authorise without wider
discussion as I appreciate other flavour users also use these two
packages.

I've tasked a few people to actually use those two packages, as both
seem to resolve some issues we've identified and believe that a FFe
should still have consideration, but with extreme caution.

Another FFe that *i've* raised is:
 - FFe: kombu (LP: #825093)

It's probable that we need a new upstream version for a release
critical project.  I've already checked the reverse depends and build
depends, and discovered that it requires a new amqplib.  I'm currently
working with upstream to see if we can avoid this newer version if
possible.

As these packages do not have other reverse depends other than the
ones we are trying to resolve, i'd be happy working through this FFe
myself.

I appreciate that one of the core qualities of a release team member is
probably communication, consideration with fellow members and
developers in general.  If I am accepted onto the release team, then I 
need to either create distance between myself and the issues I need to 
consider for release concerns, or involve other members of the release 
team.

I think there are many more aspects to these questions, but at a
generic level; I hope I have answered your questions.  If you have any
further questions, please let me know.

Please note, my subscription for this list doesn't seem to have been
approved as yet.  Please CC me directly on all mails regarding this
thread, as I only noticed your reply as someone directed me to it.
Reconstructing a mail from mbox archive isn't fun. :)

Thanks.

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/20110824/6768941a/attachment.pgp>