Proposed new release team member

[Stefan Potyra]

Hi Dave,

On Wed, Aug 24, 2011 at 10:58:34AM +0100, Dave Walker wrote:
> 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.

Thanks for the detailed answer! I can do nothing but fully agree with you.
I believe that you'll be a great addition to the release team :).

And yes, I do share your feeling that communication is a key issue. If only I
were better at it ;).

> 
> 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. :)

Sorry for that, I hit group-reply and thought it'd do the right thing. Hope it
works this time.

Cheers,
   Stefan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20110824/2657ab4c/attachment.pgp>