Re: Using webkit 1.8 for the LTS(?)
On Tue, 2011-11-29 at 19:55 +0100, Sebastien Bacher wrote: > What is your take on using webkit 1.8? Is that choice good for other > teams? Is there any issue or concern you have about updating? As an aside, but also a valid issue, regardless of the version we go with… are there any sort of plans on getting Flash working inside the GTK3 version of webkit, out of the box? signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
GNOME platform versions for the LTS
Hi, Just for information you can find details about the GNOME versions the desktop team plans to use for the LTS on https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-gnome-version We basically aim at updating the GNOME platform (glib at least, probably gtk and the other libraries that will stay compatible with the apis of the current versions), stay on GNOME 3.2 by default and maybe update a bunch of standalone softwares or desktop components where we feel the new version can bring extra stability. -- Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Using webkit 1.8 for the LTS(?)
On 11/29/2011 12:55 PM, Sebastien Bacher wrote: > Hi everybody, > > So following-up on the email I just sent and trying to improve how we > decide on things that might have an impact on others teams I would > like to discuss what version of webkit we will use for the LTS. > > In Oneiric we stayed on 1.4 because we were unsure that 1.6 would be > on time, that leaded to some issues with GNOME (which started using > the new version). We discussed the topic with upstream since and they > said they follow the GNOME schedule nowadays and the project and team > is active enough that there should be no issue for them to stay on track. > > We discussed a bit, at UDS, what version to track for Precise and the > consensus seemed to be that we would benefit to have the most recent > version and should go for 1.8 (which will turn stable in march). I > still need to confirm with upstream that they will keep supporting > gtk2 as a build time option for that serie (I pinged them today but > didn't get a reply yet). > > What is your take on using webkit 1.8? Is that choice good for other > teams? Is there any issue or concern you have about updating? > > -- > Sebastien Bacher > This should be fine as long as 1.8 has GTK2 support still. With my security hat on, as long as we have ABI compatibility (at least as much as 1.6 offered) and GTK2 support, 1.8 would be a much better base for the LTS over 1.6 since we're 6 months closer to trunk out of the gate. Thanks, Micah -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Using poppler 0.18 for the LTS (?)
Hi again, Since for GNOME the Desktop Team decided to be conservative for the LTS and to stay on GNOME 3.2 by default (and update a few selected ones where it makes) we would suggest staying on poppler 0.18 as well. How does that work for other teams? Does anyone has an opinion on the topic? We didn't discuss it with upstream yet (we don't really have an assigned poppler maintainer and nobody stepped to do that), would anyone there be interested to do that and check with them if they have issues with Ubuntu staying on that version? -- Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Using webkit 1.8 for the LTS(?)
Hi everybody, So following-up on the email I just sent and trying to improve how we decide on things that might have an impact on others teams I would like to discuss what version of webkit we will use for the LTS. In Oneiric we stayed on 1.4 because we were unsure that 1.6 would be on time, that leaded to some issues with GNOME (which started using the new version). We discussed the topic with upstream since and they said they follow the GNOME schedule nowadays and the project and team is active enough that there should be no issue for them to stay on track. We discussed a bit, at UDS, what version to track for Precise and the consensus seemed to be that we would benefit to have the most recent version and should go for 1.8 (which will turn stable in march). I still need to confirm with upstream that they will keep supporting gtk2 as a build time option for that serie (I pinged them today but didn't get a reply yet). What is your take on using webkit 1.8? Is that choice good for other teams? Is there any issue or concern you have about updating? -- Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Micro Release Exception needed for nova/glance/keystone
On Tue, Nov 29, 2011 at 12:50:07AM +, Dave Walker wrote: > On Fri, Nov 25, 2011 at 04:15:43PM -0800, Clint Byrum wrote: > > I was just reviewing the SRU's that Chuck Short uploaded for keystone, > > nova, and glance to oneiric-proposed, and it strikes me that really > > OpenStack core components should go through the MicroReleaseException > > process. > > > > Upstream has active QA, and as of diablo supports a stable release branch > > with policies around acceptance. > > > > Just sending this to ubuntu-devel as a PSA that if your SRU has more > > than 2 or 3 bugs to fix at one time, its probably not going to be able > > to pass through our manual patch review process. However, take a look > > at the criteria here and consider applying for a micro release exception: > > > > https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions > > Hi Clint, > > I think this really needs some further clarification. > > I followed this process earlier this year, when performing an SRU for > bind9 which involved a new upstream version.. This was jumping from > upstream versions 9.7.0 -> 9.7.3 in Lucid. > > I raised the subject with the TB, and mdz responded that: > "MicroReleaseExceptions is a list of standing exceptions. It's not > necessary to go through the tech board to handle one-off requests like > this one. The SRU team can decide what to do here without TB > involvement." [0] > > Is this still the case? I see the distinction as: A. "Should we update package foo to version x.y.z in order to fix bugs N and M?" should be cleared with the SRU team. The SRU team can set policy and make exceptions to it as appropriate to act in the best interests of Ubuntu users. B. "Should we, *in general*, track upstream bugfix releases of package foo and trust that they're appropriate for use by all Ubuntu users?" should be cleared with the TB. The TB has set criteria to help evaluate whether this is appropriate. It sounds like Clint is suggesting that B. would be more appropriate than A. for OpenStack. I haven't personally checked if the OpenStack components meet the documented criteria. FWIW, I would support the TB in delegating more of this authority to the SRU team if that would streamline things. So far, there have only been a handful of exceptions, and it hasn't been an issue. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
How to properly communicate on what components versions we will use in a cycle?
Hi everybody, One of the topics that I've seen coming back a few times in online comments is that some people in our community feel like the decisions we take are not always communicated as they should and don't always seem open to feedback from other teams. Do you have opinions on how we could improve that? There are probably different categories there: - infrastructure components (toolchain, python version, etc): the choices there are usually openly discussed and I've not seen a lot of controversies about the process or results - standalone softwares or components specific to a flavor: the discussions around those are happen in the team which has interest for the component and that seems fine - libraries or components used by different flavors and teams: those are the one which usually lead to issues and I'm interested to know what we could do better there. Typically the desktop team will have a session at UDS where we settle on what version of GNOME will be used (that's probably be fine for the desktop team to decide), but also, glib, gtk, the other GNOME libs. We don't discuss everything there though and often get things "sorted on the way" during the cycle, like we will update poppler or webkit because GNOME starts depending on those new version. That "sort of work" and other teams usually cope up with the side effects and catch up, but I'm wondering if we couldn't handle that better. I'm going to send emails to ubuntu-devel about the versions of webkit and poppler (and maybe some other components as well) the desktop team plans to use, I'm interested to know if: - that list is the right place for those informations and to get feedback on the choices we are taking - those informations are useful for you (do all the derivatives teams read the list?) - we have a standard way to track the choices different teams have taken about targetted for the versions (with maybe some reasons on the "why") or if we should try to get one? - what components should be discussed this way (or another)? I guess each derivatives has a list of components they depends on and would welcome to be informed and able to give their feedback on the choices we are doing. Thanks for reading, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Renaming the Packaging Guide
Hello Scott, Am 28.11.2011 18:44, schrieb Scott Ritchie: > Since it's going to cover topics this extensive then I would suggest a > more "bookish" name that feels inviting to read. Something that if > printed and placed on a store shelf would look like it belonged next to > the O'Reilly books rather than spec manuals. > > "How to improve the Ubuntu platform" I like the idea, but to me it feels like we should give the links to the guide and the title of the page that bookish name, but not the project, ie. https://launchpad.net/how-to-improve-the-ubuntu-platform if you see what I mean. Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging Follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
