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.
signature.asc
Description: Digital signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
