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