Re: Just gimme the IP!
On 6/14/2011 2:59 PM, Luke Faraone wrote: We could just get an API key from whatismyip.com, or use whatismyip.org Wouldn't it be much more viable to just create a quick script on a sub-domain ip.launchpad.net or ip.ubuntu.com or ip.canonical.com and then curl or wget it? EXP: curl -s ip.envygeeks.com wget -q -O - ip.envygeeks.com No added text, no need to grep, no need to sed, nothing but the IP. You can even have the script adjust the curl command per interface too making it so if you have multiple IP's you can get each one. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping tomboy from the CD at least for part of the oneiric cycle
Since that work has been stalling for a while, What are the chances that the mono bindings won't be ready by October, and if that's the case, what happens to Tomboy? Chris -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing XULRunner from oneiric - call for help
Hi, I've already spent way too much on time on this and I really need to be doing other things, so unless someone steps up now for a particular application that they care about, the remaining pacakges depending on xulrunner will be dropped from the archive by alpha 2. This includes: - xiphos - needs either porting to Webkit (probably a lot of work, but not sure yet) or switched to using is gtkhtml backend (easy, but gtkhtml sucks). - dehydra - already using Spidermonkey, but needs switching to use the proper lib. Probably just minor build-system changes. - mongodb - same as dehydra. - edbrowse - needs porting to Spidermonkey 1.8.5. Based on experience of doing this already for couchdb, gxine and mongodb, this is probably going to be a lot of work for the unfortunate victim who ends up doing this. The list of remaining work can be found at https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance There are still other outstanding items not mentioned here, either because people really shouldn't bother with them, they have someone assigned or I still plan to look at them (eg, vlc, fennec and eclipse). If I've not heard anything by the end of the week, I will assume that nobody cares about the remaining packages and will start filing removal requests for them. Regards Chris On Fri, 2011-05-20 at 15:53 +0100, Chris Coulson wrote: Hi, At UDS we decided that we are no longer going to maintain XULRunner in the Ubuntu archive from Oneiric onwards (although, this process already started at the end of Natty when we did some last minute work to demote it to universe). The reason for this is that the new rapid release cadence for Firefox [1] makes XULRunner difficult to support for the entire life of an Ubuntu release (up to 3 years for a LTS). The new process doesn't really affect us that much for Firefox - we will still get security updates at a similar frequency as before, and the changes between these updates will be mostly incremental. The main differences are that regular security updates (e.g., the upcoming 4.0.1 = 5.0 update) will bring incremental changes to strings and API, whereas these previously only happened during major version upgrades (such as the recent 3.6 = 4.0 upgrade). There will also only be one supported stable branch in the future, as opposed to the multiple supported stable branches that we've been used to in the past. The development cycle is fairly similar to that of Chrome/Chromium. The reason this makes XULRunner difficult to support is that regular security updates will be exposed to API changes. Although these will be incremental, it means that the security team would have to spend a lot of time every 6 weeks or so transitioning and testing applications to make sure that they continue working. I know this is the case as I maintain a binary extension for Firefox which I've already had to make changes in, to ensure that it continues working on the latest nightly builds of Firefox from mozilla-central. The alternative to this is to just backport major security fixes to the version of XULRunner we ship at release time, but we already know from past experience that this is a lot of work too, and I don't think anybody is going to volunteer to do that. I really don't think we have enough bandwidth to pursue either of these options with an acceptable level of quality. In addition to this, Mozilla have removed the GtkMozEmbed embedding API [2], which is still being used by some applications in the archive (chmsee + anything depending on python-gtkmozembed). The work to remove XULRunner is being tracked in the desktop-o-mozilla-rapid-release-maintenance blueprint [3]. When I started creating work items I realized that we still have quite a lot of applications in the archive that are using it. Over the next few days I'm going to be reviewing these dependencies to work out what we should do with each package. Where applications do have a hard dependency on XULRunner, I will try to spend time removing that dependency, e.g., by porting those to an alternative API (such as Webkit). This is where I would appreciate help from anyone who has a particular interest in any of the affected applications listed on the blueprint. Obviously, it would be a shame to lose applications such as chmsee (I use that, and this is one application which I think is definitely worth keeping), but I'm not going to spend significant amounts of time working on applications which aren't that popular or are not very well maintained. So, the current plan of action is: - Browser plugins that are currently depending on xulrunner-dev just to include the NPAPI headers can depend on firefox-dev for those instead (eg, packagekit). The alternative is to include a local copy of the headers instead (eg, Totem does that). - Browser plugins that are actually using Mozilla interfaces will need to be modified to not do that (or they
ARM porting Jam *today* 14:00 - 18:00 UTC)
Hi fellow ARM fans, Linaro Developer Platform team organises every week (Wednesday 14:00 - 18:00 UTC) an ARM porting Jam. The idea is to gather all developers together to fix userspace portability issues across the board. The list of bugs being worked on is at launchpad: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queueorderby=-id Interested in making the software in Ubuntu run better on ARM? Join us on the #linaro channel on irc.linaro.org today! Cheers, Riku -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Just gimme the IP!
On 14 June 2011 20:59, Luke Faraone l...@faraone.cc wrote: On 06/14/2011 12:09 PM, Mathieu Trudel-Lapierre wrote: Would it make sense to also have a way to get the current *public* ip address? That's difficult to determine, without calling on an external service. We could just get an API key from whatismyip.com, or use whatismyip.org / icanhazip.com. We already have an app in the default install which does something similar. The remote desktop server makes a call out to the author/maintainers website to discover if the Ubuntu install is remotely accessible via VNC. Aside: I believe we shouldn't be leaking info like this. https://bugs.launchpad.net/ubuntu/+source/vino/+bug/608701 Perhaps as Jordon suggests a *.ubuntu.com based service would be preferable both for IP discovery and VNC connectivity test. Al. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Plymouth boot log messages
Hello, I created patches which add support for writing boot log messages into plymouth (for drm/framebuffer or classic text console renderer). So on plymouth screen (or in text console) is written messages by plymouth (like in old usplash): Starting daemon XYZ... ok Stopping daemon XYZ... failed Here is my merge requests: https://code.launchpad.net/~pali/ubuntu/natty/plymouth/plymouth/+merge/61897 https://code.launchpad.net/~pali/ubuntu/oneiric/kubuntu-default- settings/kubuntu-default-settings/+merge/63334 https://code.launchpad.net/~pali/ubuntu/oneiric/initramfs-tools/initramfs- tools/+merge/64373 What is missing is boot log messages for System V init scripts in /etc/init.d/ This can be added into file /etc/lsb-base-logging-ubuntu.sh Plymouth-upstart-bridge can handle all upstart scripts from /etc/init/ and initramfs/functions can handle all messages generated from initramfs. PS: I'm not in mailinglist, CC me. -- Pali Rohár pali.ro...@gmail.com 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
Re: Providing icons for multiple themes
On 13/06/2011 17:03, Georg Schmidl wrote: Hi all, I developed a system monitor indicator called SysPeek, and I'm wondering if there's a proper way to provide icons for multiple themes. I build a package that installs icons in /usr/share/icons/ubuntu-mono-dark and /usr/share/icons/ubuntu-mono-light and it seems to work, but I'm not sure if this is a good idea. Is there any documentation about this? What are the icon names? If they're fairly specific, I would think that the way to go about it would be to get the icons included into the individual theme projects themselves. Just create a bug on launchpad.net targeting both projects and attach the icons you want included? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Just gimme the IP!
On 06/15/2011 11:37 AM, Clint Byrum wrote: Except that this would fail completely if you don't have access to ip.envygeeks.com. Which would mean that either their host is down, or you don't have a route to the public Internet. The unavailability of a single host could be resolved by testing multiple, with a short timeout. -- Luke Faraone;; Debian Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Just gimme the IP!
Excerpts from Luke Faraone's message of Wed Jun 15 08:44:52 -0700 2011: On 06/15/2011 11:37 AM, Clint Byrum wrote: Except that this would fail completely if you don't have access to ip.envygeeks.com. Which would mean that either their host is down, or you don't have a route to the public Internet. Precisely. Corporate networks often don't have a route to the internet. Especially when talking about complex server setups. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Just gimme the IP!
Excerpts from Dustin Kirkland's message of Mon Jun 13 18:58:21 -0700 2011: Howdy ubuntu-devel! I'm seeing quite a bit of code duplication in scripts and packaging in Ubuntu around the determination of IP addresses. Most are permutations of 'ifconfig' or 'ip addr', and four to six pipes through awk, grep, sed, and/or cut. Some others dig through /proc. Some are buggy (ie, more than one ip address on the system, foreign locale but does not set LC_ALL=C, etc). Many of them do their job well enough, but I can't help but think there's some room for improvement. First, Dustin, thanks for taking this on. Seeing my hacks on top of hacks in principia seems to have pushed you to do something positive about the propagation of this flawed technique, which if nothing else has accomplished a spirited discussion about the issue. However, after reading the logs of Dustin's discussion on IRC w/ Keybuk and cjwatson, I have to think that this is actually something we should move away from. The usage of the ifconfig parse hack in principia is actually completely unnecessary, and stems from a very old distrust of DNS that I have had for a long time as a sysadmin. The truth of the matter is, DNS is the right way to resolve this, and any latency concerns should be addressed with local DNS caches. You should have an FQDN, and it should always lead a remote host that can talk to you, to the IP that it needs to use to talk to you. This isn't always true, but in the use case we have in Ensemble and Principia, this is precisely the case. Amazon assigns an IP and a FQDN to each host, and that FQDN resolves inside Amazon to the internal IP that any machine on the same security group can use to access it. For anything else, you need more information that isn't available on the machine anyway (such as your external NAT address or elastic IP in the EC2 case). So really, passing what I *think* is my IP isn't nearly as useful as passing what I *know* is my hostname. This is especially important as we transition to IPv6. For the other places where IP is being used, the use should be evaluated, as its likely hostname would work, and should be used instead. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[dpkg-dev] auto-generated patch too easily included (debian/patches/debian-changes-*))
Hi, Currently, if the upstream code is changed (anything other than debian/*).. When dpkg-buildpackage is run, an automated patch is created. This is a really nice feature, but it is very easy to miss this. I have seen multiple uploads where these auto-generated patches have been included accidentally (I have also been guilty of this). This can be overridden locally with: $ cat ~/.devscripts DEBUILD_DPKG_BUILDPACKAGE_OPTS=--source-option=--abort-on-upstream-changes I think the chance of someone wanting an auto-generated patch is low, and would like to suggest the default is changed to fail to create the source package. The alternative fix would be a dput hook. Thoughts? I have raised a bug to track this: https://launchpad.net/bugs/797839 Kind Regards, Dave Walker -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [dpkg-dev] auto-generated patch too easily included (debian/patches/debian-changes-*))
On Wednesday, June 15, 2011 12:40:27 PM Dave Walker wrote: Hi, Currently, if the upstream code is changed (anything other than debian/*).. When dpkg-buildpackage is run, an automated patch is created. This is a really nice feature, but it is very easy to miss this. I have seen multiple uploads where these auto-generated patches have been included accidentally (I have also been guilty of this). This can be overridden locally with: $ cat ~/.devscripts DEBUILD_DPKG_BUILDPACKAGE_OPTS=--source-option=--abort-on-upstream-changes I think the chance of someone wanting an auto-generated patch is low, and would like to suggest the default is changed to fail to create the source package. The alternative fix would be a dput hook. Thoughts? I have raised a bug to track this: https://launchpad.net/bugs/797839 Please don't make the Ubuntu default different than the Debian default. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [dpkg-dev] auto-generated patch too easily included (debian/patches/debian-changes-*))
On 06/15/2011 07:40 PM, Dave Walker wrote: Currently, if the upstream code is changed (anything other than debian/*).. When dpkg-buildpackage is run, an automated patch is created. This is a really nice feature, but it is very easy to miss this. I have seen multiple uploads where these auto-generated patches have been included accidentally (I have also been guilty of this). There is a lintian tag for this, format-3.0-but-debian-changes-patch. This can be overridden locally with: $ cat ~/.devscripts DEBUILD_DPKG_BUILDPACKAGE_OPTS=--source-option=--abort-on-upstream-changes I think the chance of someone wanting an auto-generated patch is low, and would like to suggest the default is changed to fail to create the source package. If that is done, people will run into a problem when they try to change a problematic debian package. That might introduce unnecessary diffs to debian. (because the package will fail on ubuntu) If you want to change the default, it would be better to coordinate with debian. Cheers, Andreas signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
On Tuesday, June 14, 2011 01:57:11 AM Allison Randal wrote: At UDS-O, we talked about balancing the 6-month cycle from the current 24/28 split towards a more even split. The general consensus was to keep the long 28 week cycle for P, since it's an LTS, but discuss more for Q and R. For context, I did a little walk down memory lane: https://wiki.ubuntu.com/AllisonRandal/ReleaseCadence Turns out, we've only had an actual 26 week cycle twice in the history of Ubuntu (Gutsy and Lucid), and never back-to-back. The longest cycle ever was 33 weeks (Dapper), immediately followed by the shortest cycle ever at 21 weeks (Edgy). The most common cycle length was 27 weeks (Breezy, Hardy, Intrepid, Karmic). Maverick was 24 weeks, Natty 28, and Oneiric and P follow the same 24/28 split. In the current draft schedules for Q and R we continue the 24/28 split: Q: October 11, 2012 (24 weeks) R: April 25, 2013 (28 weeks) The concern raised at UDS is that 24 week cycles are difficult for upstreams working to synchronize their cadence with ours. The simplest proposal is to bump Q one week later, and R one week earlier for: Q: October 18, 2012 (25 weeks) R: April 18, 2013 (26 weeks) And after that follow a more-or-less 26/26 split (barring interference by international holidays, etc). Would this change be helpful or harmful for you? If so, could you share a bit about how? Is the change adequate to address the needs of upstreams? To help our wonderful UDS planners (who need to know when to book UDS space for us), I'll summarize the thread for this Friday's release meeting, and we can discuss any remaining questions there. Thanks all, Allison For Kubuntu, when we've been able to release at the end of the month we've been able to release with KDE 4.X.2. For Maverick we had to release with 4.5.1. This required significant effort on the part of Kubuntu developers to review all the upstream branches and cherrypick a number of important patches. I think that a roughly balanced schedule (nominally 26/26) is the best one for giving other projects that want to align to Ubuntu releases a reliable target to aim for. I like the idea of keeping a steady cadence. My preference would be slightly different, to go straight to 26 weeks: Q: October 25, 2012 (26 weeks) R: April 25, 2013 (26 weeks) This would align pretty well with what I expect will be the most likely upstream release plan for KDE. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Daily builds now hybrid CD/USB images
As of tomorrow's daily builds, all Oneiric amd64 and i386 CD images on cdimage.ubuntu.com can also be written directly to a USB device. You can still use usb-creator if you need to enable persistent storage on the USB stick, but if all you need is to install from the stick then this simplifies the process. There is a small size cost to this feature; part of this is partition alignment to 1MB cylinders (since the image now has to simultaneously look like a CD and a partitioned USB disk), and part of it is a second directory tree whose size is roughly proportional to the number of files in the image. On the server CD (and probably the alternate CD too, though I haven't measured that), this came out to about 5MB, but as luck would have it I found a way to save about the same amount by hardlinking some files together, so the size there stays roughly the same. On the desktop CD, unfortunately, we lose about 1MB (although I consider myself to have paid for this by way of the 2MB or so we gained by switching to live-build ...). If this becomes a problem close to release time, then we may be able to shave off a bit at the possible cost of some USB-booting compatibility on a few machines by dropping the 1MB alignment. See the recent thread on pkg-libburnia-devel for details. I realise that we're behind a number of other major distributions on this. The delay was because (like Debian) we couldn't simply use isohybrid because that would break jigdo downloads, so we had to switch to xorriso as the CD image generator on these architectures for its new JTE support, and by the time all that landed in Debian I didn't really want to cram it into 11.04. See http://blog.einval.com/2011/01/07#isohybrid_CDs for the gory details, and thanks a lot to Steve, Thomas, and George for their hard work on that. Please file bugs on https://bugs.launchpad.net/ubuntu-cdimage if this change causes the image to stop working on machines where it previously worked. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
On 06/15/2011 11:34 AM, Scott Kitterman wrote: For Kubuntu, when we've been able to release at the end of the month we've been able to release with KDE 4.X.2. For Maverick we had to release with 4.5.1. This required significant effort on the part of Kubuntu developers to review all the upstream branches and cherrypick a number of important patches. I think that a roughly balanced schedule (nominally 26/26) is the best one for giving other projects that want to align to Ubuntu releases a reliable target to aim for. I like the idea of keeping a steady cadence. My preference would be slightly different, to go straight to 26 weeks: Q: October 25, 2012 (26 weeks) R: April 25, 2013 (26 weeks) This would align pretty well with what I expect will be the most likely upstream release plan for KDE. Very valuable perspective, thanks. To other upstreams, do you have similar or opposite needs? A few practical considerations I ran through: - Release on Oct 11 means UDS on Oct 29-Nov 2 (the week of Halloween) - Release on Oct 18 means UDS on Nov 5-9 - Release on Oct 25 means UDS on Nov 12-17 (the week before Thanksgiving) Having UDS the week before Thanksgiving will cause substantial travel problems for return flights from a US-based UDS. Having UDS on the week of Halloween could go either way (it's fun to have our semi-traditional UDS Halloween party, but parents based in countries that celebrate it would probably rather be home with their kids that week). Easter is March 31st in 2013, so we don't have to schedule around it for R. (In many years, Easter is the tricky bit for April releases.) Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Daily builds now hybrid CD/USB images
On Wed, Jun 15, 2011 at 04:28:10PM -0500, Mario Limonciello wrote: When written to a USB stick in this fashion, what filesystem is the stick operating as? AFAIK it's still ISO9660. If it's not actually FAT32 (or FAT16 for that matter), I'm wondering what uEFI firmware will say about it when trying to boot in uEFI mode. No idea as yet :-) -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
On Wed, Jun 15, 2011 at 03:58:54PM -0700, Steve Beattie wrote: On Wed, Jun 15, 2011 at 02:48:58PM -0700, Allison Randal wrote: Very valuable perspective, thanks. To other upstreams, do you have similar or opposite needs? Perhaps this is just me being naive, but with upstreams, shouldn't we be emphasizing the Feature Freeze date rather than the actual Release date? This is a really good point. Of course, I wonder if very many upstreams are adjusting their cadences to follow ours? Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
On 06/15/2011 05:58 PM, Steve Beattie wrote: On Wed, Jun 15, 2011 at 02:48:58PM -0700, Allison Randal wrote: Very valuable perspective, thanks. To other upstreams, do you have similar or opposite needs? Perhaps this is just me being naive, but with upstreams, shouldn't we be emphasizing the Feature Freeze date rather than the actual Release date? That's the merge window deadline they should be targeting, and where the Ubuntu cadence should be most relevant. This is at least how the upstream I do release management for targets the Ubuntu releases. Going back through the previous calendars, it seems that we've had Feature Freeze be 9 weeks before release on non-LTS releases and 10 weeks prior on LTS releases (until you go back to Feisty where it starts to deviate). I also note that looking at the current draft Q schedule and R schedules, Feature Freeze is tentatively marked in at 11 weeks and 10 weeks prior to the respective releases. So even if the Q and R release cycles were moved to straight 26 week cycles, unless the Feature Freeze dates are also aligned, upstreams won't really have a 26 week cadence to target for development. Indeed, but something to remember is that certain upstreams (KDE and GNOME amongst others), have a microrelease exception which allows the point releases to be included. These were granted since no new features are included in point releases. I believe this is the point Scott K was raising in that we get an extra round of bug fixes if we do a 26/26 split on the fall release. Micah -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
Steve Beattie sbeat...@ubuntu.com wrote: On Wed, Jun 15, 2011 at 02:48:58PM -0700, Allison Randal wrote: Very valuable perspective, thanks. To other upstreams, do you have similar or opposite needs? Perhaps this is just me being naive, but with upstreams, shouldn't we be emphasizing the Feature Freeze date rather than the actual Release date? That's the merge window deadline they should be targeting, and where the Ubuntu cadence should be most relevant. This is at least how the upstream I do release management for targets the Ubuntu releases. Going back through the previous calendars, it seems that we've had Feature Freeze be 9 weeks before release on non-LTS releases and 10 weeks prior on LTS releases (until you go back to Feisty where it starts to deviate). I also note that looking at the current draft Q schedule and R schedules, Feature Freeze is tentatively marked in at 11 weeks and 10 weeks prior to the respective releases. So even if the Q and R release cycles were moved to straight 26 week cycles, unless the Feature Freeze dates are also aligned, upstreams won't really have a 26 week cadence to target for development. In general, yes. In the particular case I'm worried about having time before final freeze to integrate a bugfix update from KDE so release and the related freeze milestones are the relevant ones. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
Micah Gersten mic...@ubunt.com wrote: On 06/15/2011 05:58 PM, Steve Beattie wrote: On Wed, Jun 15, 2011 at 02:48:58PM -0700, Allison Randal wrote: Very valuable perspective, thanks. To other upstreams, do you have similar or opposite needs? Perhaps this is just me being naive, but with upstreams, shouldn't we be emphasizing the Feature Freeze date rather than the actual Release date? That's the merge window deadline they should be targeting, and where the Ubuntu cadence should be most relevant. This is at least how the upstream I do release management for targets the Ubuntu releases. Going back through the previous calendars, it seems that we've had Feature Freeze be 9 weeks before release on non-LTS releases and 10 weeks prior on LTS releases (until you go back to Feisty where it starts to deviate). I also note that looking at the current draft Q schedule and R schedules, Feature Freeze is tentatively marked in at 11 weeks and 10 weeks prior to the respective releases. So even if the Q and R release cycles were moved to straight 26 week cycles, unless the Feature Freeze dates are also aligned, upstreams won't really have a 26 week cadence to target for development. Indeed, but something to remember is that certain upstreams (KDE and GNOME amongst others), have a microrelease exception which allows the point releases to be included. These were granted since no new features are included in point releases. I believe this is the point Scott K was raising in that we get an extra round of bug fixes if we do a 26/26 split on the fall release. Yes. Exactly. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [dpkg-dev] auto-generated patch too easily included (debian/patches/debian-changes-*))
On 16/06/2011 04:52, Micah Gersten wrote: [...] I actually use this as a feature. I modify the upstream code, create a source package, then rename the patch and add DEP-3 info. I think it should be opt-in rather than opt-out. I've had too many occasions where I accidentally introduced a new file, say cscope.out/cscope.files, and it ends up creating an unwanted diff. For that reason, I always work on packages in git. This way I get control over what changes I want in and out of the package. That said, the DEBUILD_DPKG_BUILDPACKAGE_OPTS=--source-option=--abort-on-upstream-changes method seems to work pretty well, so I think I'll just keep that in my .devscripts. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
Ted Gould t...@ubuntu.com wrote: On Wed, 2011-06-15 at 14:48 -0700, Allison Randal wrote: A few practical considerations I ran through: - Release on Oct 11 means UDS on Oct 29-Nov 2 (the week of Halloween) - Release on Oct 18 means UDS on Nov 5-9 - Release on Oct 25 means UDS on Nov 12-17 (the week before Thanksgiving) Does UDS have to be a fixed number of days from the release? It certainly hasn't historically. BTW, I think the week before Thanksgiving is fine. It's definitely better than the week before Christmas (which we've done - I skipped that one). Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
On 06/15/2011 07:41 PM, Ted Gould wrote: Does UDS have to be a fixed number of days from the release? It's been as short as 1 week after the release (no break, not much time to prepare), and as long as 6 weeks after (cuts heavily into the work of the cycle). So no hard rules, just weighing the +1s and -1s. 2 weeks is enough to regroup for the next cycle, but also allow plenty of development time. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
Steve Beattie [2011-06-15 15:58 -0700]: Perhaps this is just me being naive, but with upstreams, shouldn't we be emphasizing the Feature Freeze date rather than the actual Release date? That's the merge window deadline they should be targeting, and where the Ubuntu cadence should be most relevant. I think the FF target makes more sense for upstreams who don't align their release cycle with our's, i. e. for the common case. For upstreams who do the final release date is more relevant, as usually after our FF they will also release bug fix only upstream releases which we then take into the distro. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
Allison Randal [2011-06-13 23:57 -0700]: Q: October 18, 2012 (25 weeks) R: April 18, 2013 (26 weeks) And after that follow a more-or-less 26/26 split (barring interference by international holidays, etc). Would this change be helpful or harmful for you? That sounds better indeed. People are usually on summer vacation for two weeks, and take roughly two weeks off over christmas/new year, so holiday wise it should be pretty even as well. If we want to have different cycle lenghts, I'd prefer making the winter cycle longer, as the LTSes are the April ones. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Partially hidden launcher - updated mockup 3d shelf
I updated the mockup so it looks like a 3d shelf. As before, hovering over the shelf for a period of time makes the icons slide out of their compartments. This lets one interesting new way to add favorite applications - click and hold on an empty compartment and the applications lens should appear to drag the desired application to a compartment. Of course, the mockup would benefit from someone with better artistic skills :) On Mon, Jun 13, 2011 at 18:58, Erlan Sergaziev erlan.sergaz...@gmail.comwrote: Hi everyone, I would like to suggest a new way of handling launcher auto-hide. First, some reasons: 1) When the launcher is hidden, the user is unable to quickly switch/launch applications (so it's a regression for many against old-style taskbar panel) and also misses the benefits of seeing launcher badges. 2) When the launcher is always on, it steals some pixels and makes the interface cluttered. Therefore, I'd like to propose that the launcher is partially hidden (about 1/3rd of full width of app's icon) and then rolls out to full width if the user hovers over it with a delay. This way the user gets the following benefits: 1) Much less horizontal space stolen, yet the icons are still recognizable and the user can quickly point and click to launch/switch. 2) The space potentially can fit a minimal version of a badge. E.g., the full badge for an email app should have two parts, the count and a small envelope. When the launcher is partially hidden, the count gets hidden but the envelope stays. Another way would be to change color/highlight of the icon. 3) It is consistent with the notion of new style scrollbars in Unity. 4) For some users constant hide/autohide is irritating, so they might choose to have the launcher always partially hidden. Attached are mockups, please excuse their bad quality, but you'll get the idea. What do you think? Erlan attachment: Launcher_Shelf_Normal.jpg-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
