[Bug 1585362] Re: add stable-phone-overlay repository upon install
I rejected the upload for now as this apparently still takes some time to discuss, and we have no other comments/state on the unapproved queue. -- You received this bug notification because you are a member of Ubuntu Technical Board, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1585362 Title: add stable-phone-overlay repository upon install To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1585362/+subscriptions -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Nominations to the Tech Board
Daniel Holbach [2016-04-06 11:59 +0200]: > just before we set up the poll and everything, I had a look at the list > of nominations and it looks like Jason de Rose is not member of > ~ubuntu-dev, who are the ones who can vote for the TB. At least the wiki > isn't clear if this is a problem or not, did we have cases like this in > the past? For the record, no, I don't think so. So far we used to pick candidates out of the ~ubuntu-core-dev ranks. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies for today's meeting
Hello all, I'd really like to attend a public event this evening, and since we have no agenda for today's meeting I would like to excuse myself. Concerning that, in a meeting a few months ago we raised the idea of cancelling the meeting if there was no agenda some hours before it -- do we want to try and do that? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MRE request: virtualbox
Hello Gianfranco, Gianfranco Costamagna [2015-10-29 18:50 +0100]: > I would like to apply for a micro release exception for Virtualbox Since [1] we actually did away with (most) explicit MREs, and adjusted the SRU policy to generalize those. [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html > Upstream: > > - Micro releases happen from low-volume stable branches, > approximately once every two months. > > - Stable branches are supported with bug fixes for some years > (normally 5 years + 6 months or more). > > - Upstream commits are reviewed by members of the Virtualbox Server > Engineering team. > > - All commits to stable branches are evaluated wrt. potential > regressions and signed off by the Virtualbox team. > > - Unit tests and regression tests are run on multiple platforms per > push to the source code repository. In addition, there are more > extensive test suites run daily and weekly. > > - Each micro release receives extensive testing between code freeze > and release. This includes the full functional test suite, > performance regression testing, load and stress testing and > compatibility and upgrade testing from previous micro and > minor/major releases. > > - Tests are run on all supported platforms (currently amd64 and i386). This satisfies the current policy, so this looks fine for SRUing. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hello all, I can't attend today's meeting, I have an appointment this evening. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU policy: Allow new features in LTSes under certain conditions
Hey Robie, sorry for the late answer, I missed your reply. Robie Basak [2015-09-02 10:51 +0100]: > On Tue, Sep 01, 2015 at 05:45:26PM +0200, Martin Pitt wrote: > > They must not change the behaviour on existing installations > > (e. g. entirely new packages are usually fine). If existing software > > needs to be modified to make use of the new feature, it must be > > demonstrated that these changes are unintrusive, have a minimal > > regression potential, and have been tested properly. > > For clarity, let me call the above requirements "the quality criteria". > > Consider a new feature where the proposed LTS update does meet the > quality criteria. Who will decide whether this feature is acceptable to > SRU to the LTS? The intention is that the SRU team who reviews the change decides whether this matches the policy, as usual. If the SRU team has doubts about a particular change, they should continue to express that in the bug, and/or appeal to the TB. > Would each proposed feature still need to go individually to the TB for > approval? Or would this new policy give uploaders the ability to add new > features to the LTS directly, since the SRU team would simply approve it > under this new policy? That was the idea: We want to greatly reduce the number of special cases that we need to document and check explicitly, and instead generalize the principles upon we granted them into the main policy, so that this becomes less arbitrary. > For example, what should a sponsor do to handle a new feature in the > sponsorship queue? Just upload if it meets the quality criteria, to be > accepted by the SRU team after they have double-checked? Or should extra > steps be taken to determine if we want the new feature in the LTS? There is only so much common sense which you can formalize. This is certainly not meant to swamp LTSes with all kinds of corner case new features, they should continue to be the exception. But yes, the idea of the policy is that everyone can check whether the criteria match and we avoid long turnarounds with individual discussions for exceptions. As a sponsor you take responsibility for the uploaded change, be it in the devel series or SRU; so if as a sponsor you are convinced that SRUing that new feature is a good idea, safe, and matches the above policy, then go ahead. The SRU team will review the change anyway. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
SRU policy: Allow new features in LTSes under certain conditions - v2
Hello again, Martin Pitt [2015-09-01 17:45 +0200]: > occasionaly we get a request to introduce a new package into LTSes. > This is usually unproblematic as there is a miniscule chance to break > existing installations (unless the Package uses > Conflicts:/Replaces:/Provides:), which should obviously not be > allowed). In July however we got a more intrusive request for > introducing Ubuntu FAN into trusty [1]. This was granted a special > exception by the TB, but it would be good to generalize the principles > upon we agreed to this. > > I therefore propose the following amendment to the policy, relative to > the changes proposed in [2]. This updated proposal incorporates the suggested changes from Stéphane and Steve. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) --- StableReleaseUpdates.specialcases 2015-09-16 06:44:07.135737058 +0200 +++ StableReleaseUpdates.newfeatures 2015-09-16 06:51:45.290663836 +0200 @@ -49,6 +49,7 @@ * Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). * For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. + * For Long Term Support releases we sometimes want to introduce new features. They must not change the behaviour on existing installations (e. g. entirely new packages are usually fine). If existing software needs to be modified to make use of the new feature, it must be demonstrated that these changes are unintrusive, have a minimal regression potential, and have been tested properly. To avoid regressions on upgrade, any such feature must then also be added to any newer supported Ubuntu release. Once a new feature/package has been introduced, subsequent changes to it are subject to the usual requirements of SRUs to avoid regressions. * New versions of commercial software in the Canonical partner archive. * '''FTBFS'''(Fails To Build From Source) can also be considered. Please note that in '''main''' the release process ensures that there are no binaries which are not built from a current source. Usually those bugs should only be SRUed in conjunction with another bug fix. signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Generalizing SRU policy for special cases/MREs
Hello all,
over the years our SRU policy [1] has accumulated a fair amount of
special cases [2] and exceptions for new microreleases [3]. There is a
lot of commonality between them, mostly related to automated testing.
Since most of these were added, a lot of projects have moved to a CI
based development model; this includes Ubuntu itself, which is now
running package integration tests for both the development series [4]
and SRUs [5].
The attached patch against [1] is my proposal for updating the SRU
policy accordingly. It mostly extends the "When" section for the cases
that we've seen in practice, and reduces [2] to just documentation
about three packages (kernel, landscape, tzdata), which don't include
a changed policy, just a "how to update this".
This should go together with dropping [3]. A lot of the existing
entries in [3] now fall under the revised "New upstream microreleases"
policy (e. g. postfix, PostgreSQL, MariaDB, firefox, mesa), and others
have been obsolete for quite a while (Ubuntu One, bzr). The section at
the bottom ("SRU verification for Micro Release Exceptions") was
included into the main [1] documentation (in spirit, not verbatim). I
believe that the page [3] has never been very well maintained, as
things become obsolete, there is no clear distinction between
provisional and full exceptions, etc. Thus I believe setting a general
policy and instead asking for linking to the QA policy in SRU bugs is
a better and more dynamic approach.
Comments, language improvements, etc much appreciated!
Thanks,
Martin
P.S. I still have a TODO item to propose an amendment for introducing
new features into LTS, such as the recently proposed "Ubuntu FAN" [6].
I will do this after this cleanup got discussed/improved/accepted.
[1] https://wiki.ubuntu.com/StableReleaseUpdates
[2] https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases
[3] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[4]
http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[5] http://people.canonical.com/~ubuntu-archive/pending-sru.html
[6] https://lists.ubuntu.com/archives/technical-board/2015-July/002122.html
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--- StableReleaseUpdates 2015-09-01 15:45:25.245567920 +0200
+++ StableReleaseUpdates.specialcases 2015-09-01 16:33:58.559594596 +0200
@@ -30,28 +30,53 @@
== When ==
+=== High-impact bugs ===
+
Stable release updates will, in general, only be issued in order to fix '''high-impact bugs'''. Examples of such bugs include:
* Bugs which may, under realistic circumstances, directly cause a '''security vulnerability'''. These are done by the security team and are documented at SecurityTeam/UpdateProcedures.
* Bugs which represent '''severe regressions''' from the previous release of Ubuntu. This includes packages which are totally unusable, like being uninstallable or crashing on startup.
* Bugs which may, under realistic circumstances, directly cause a '''loss of user data'''
+ * Updates that need to be applied to Ubuntu packages to adjust to changes in the environment, server protocols, web services, and similar, i. e. where the current version just ceases to work. Examples:
+ * app-install-data-commercial is a package index which regularly needs to be adjusted to changes in the commercial package archive.
+ * clamav needs [[ClamavUpdates|regular updates]] to latest virus signatures
+ * tor needs a newer version to still work with the current Tor network.
+ * A library for a web service needs to be updated for changes to the web server API.
+
+=== Other safe cases ===
+
+In the following cases a stable release update is also applicable as they have a low potential for regressing existing installations but a high potential for improving the user experience, particularly for Long Term Support releases:
+
* Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
- * For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers.
+ * For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates.
* New versions of commercial software in the Canonical partner archive.
SRU policy: Allow new features in LTSes under certain conditions
Hello all, occasionaly we get a request to introduce a new package into LTSes. This is usually unproblematic as there is a miniscule chance to break existing installations (unless the Package uses Conflicts:/Replaces:/Provides:), which should obviously not be allowed). In July however we got a more intrusive request for introducing Ubuntu FAN into trusty [1]. This was granted a special exception by the TB, but it would be good to generalize the principles upon we agreed to this. I therefore propose the following amendment to the policy, relative to the changes proposed in [2]. Thanks, Martin [1] https://lists.ubuntu.com/archives/technical-board/2015-July/002122.html [2] https://lists.ubuntu.com/archives/technical-board/2015-September/002153.html -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) --- StableReleaseUpdates.specialcases 2015-09-01 16:33:58.559594596 +0200 +++ StableReleaseUpdates.newfeatures 2015-09-01 17:41:37.611778569 +0200 @@ -49,6 +49,7 @@ * Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). * For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. + * For Long Term Support releases we sometimes want to introduce new features. They must not change the behaviour on existing installations (e. g. entirely new packages are usually fine). If existing software needs to be modified to make use of the new feature, it must be demonstrated that these changes are unintrusive, have a minimal regression potential, and have been tested properly. * New versions of commercial software in the Canonical partner archive. * '''FTBFS'''(Fails To Build From Source) can also be considered. Please note that in '''main''' the release process ensures that there are no binaries which are not built from a current source. Usually those bugs should only be SRUed in conjunction with another bug fix. signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Adding a hook to ubuntu-drivers GUI for a driver PPA
Hello all, Jorge O. Castro [2015-08-18 14:13 -0400]: - An additional entry in the graphics driver dialog that says something similar to The latest upstream driver from Nvidia), this selection would never be the default. We already have this in Ubuntu itself: We have several versions of nvidia-*, with one of them being the recommended one by ubuntu-drivers-common. We would then update the PPA according to Nvidia's upstream release schedule. Big NACK, for the reason Stéphane pointed out. I see nothing that would stop these packages getting into stable-updates properly, especially if they are new upstream versions that don't change existing systems (unless you opt-in, of course). I. e. I do support the idea of supplying the latest graphics drivers especially to LTSes, but within the Ubuntu archive, not via PPAs. Of course PPAs are fine for pre-release testing, but enabling them as a way to work around Ubuntu policies is a dangerous and slippery slope. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposal to help CC with potential conflicts of interest
Hey Mark, Mark Shuttleworth [2015-06-09 13:40 +0100]: I am writing to see how you, as a representative TB, feel about the proposal. If you are comfortable with handling such discussions in the very unlikely event they were to occur, that would be sufficient support for me to suggest it as a good practice to the CC for future reference. As the project gets a little older, it's not inappropriate for us to endeavour to be a little wiser too, so put this email in that bucket :) I think this is a very sensible approach and avoids inventing further boards and procedures. The only remark that I have is that if such a case occurs, I'd rather discuss it privately first than in the public and logged IRC meeting. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: docker in 14.04
Hello James, James Page [2015-04-09 12:57 +0100]: 1) The package maintainer of docker will work in-conjunction with docker upstream to identify at any given point in time what the best stable release is for Ubuntu. This allows us to deal with the 'new' releases of docker alongside the previous 'stable' release and switch things at the right time. 2) This release of docker will be packaged for the development release and as a back port for all released versions of Ubuntu still under support back to 14.04. To clarify, does that mean you want to entirely drop the previous proposal of having multiple supported versions with packages like docker, docker-1.5, or docker-stable, and instead we'll just have a single supported docker which gets new major versions for stable releases, at least as long as they stay compatible in the sense below? If that's possible, I much prefer this to the previous proposal, which IMHO made things even worse and more labor-intense and didn't address the fundamental problem at all. 3) As part of the SRU testing process, we'll perform automated upgrade testing of docker to ensure that a cross section of popular application containers work both before and post upgrade, as part of the upgrade AND being rebuilt pre and post upgrade. That sounds good to me. If the primary/intended way of consuming docker is to always run the latest upstream stable release, then docker workloads should not be too surprised if existing rollouts suddenly find a new docker version. We should operate this policy until 16.04 release, at which point we need to review whether its still appropriate or whether docker development velocity is now shelving off, and we can seriously consider a true stable docker maintenance approach for 16.04. If the backwards compatibility is given/tested, this sounds much more practical, less confusing, and better to me indeed. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Please demote maas 1.2 from Ubuntu Precise
Hey Andres, Andres Rodriguez [2015-02-27 15:32 -0500]: This is a request to demote MAAS from Main for Ubuntu 12.04 Precise. MAAS version (1.2) in Ubuntu Precise is no longer maintained upstream and we are no longer committed to maintain it in Ubuntu. This is a very old release (we are at 1.7 now) and currently would require a lot of effort to keep maintaining it, hence we are requesting its demotion. These are the current versions in precise: maas | 0.1+bzr482+dfsg-0ubuntu1 | precise | source, all maas | 1.2+bzr1373+dfsg-0ubuntu1~12.04.6 | precise-updates | source, all We technically cannot demote packages in stable releases. However, as you already updated the 0.1 version to 1.2, there might be a case to update 1.2 to something newer that you still maintain which is still fully backwards compatible to 1.2. We recently discussed that as part of the SRU exception, too, and I had the impression that you try hard to not break backwards compat? Note that we require filing MIR bugs (like MAAS' in #961344) for exactly this case: it's a commitment to yes, we want to support this for 5 years, and thus also a promise to people who actually roll this out in production. Finally, if 1.5/1.7 are not backwards compatible to 1.2, and you don't want to update 1.2 any more, what's the minimum maintenance that actually is required on 1.2? As long as it works, it doesn't require updating, and given that it is a mechanism to completely own/control a bunch of hardware, this doesn't appear to be a primary worry for security updates either? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hello all, I can't attend today's meeting, I'm afraid; I have an appointment this evening. FTR, the one in two weeks didn't happen as most TB members were not available (travelling). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Community Council catchup - Ubuntu Technical Board
Hey techboard, Elizabeth K. Joseph [2015-02-04 15:49 -0800]: Just a quick reminder that this is coming up tomorrow, Thursday February 5th. I'm afraid I'm AFK for the whole afternoon and evening for a long appointment (I took off half day), so I can't participate. Does anyone else have time? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: docker in 14.04
Hello James, sorry for the very late answer! James Page [2014-12-18 17:32 +]: but once stable switches to a new release, they currently no longer backport security fixes to the old stable release. So the current recommendation to fix security issues to to upgrade to the latest stable, which will have the required fixes. That's in fact the position of the majority of upstreams out there, and why we have to backport individual security patches to our released versions. So this is nothing special really, we've done that for ten years. ;-) We (as in the Canonical Server team) considered whether we would be able to backport security fixes to the version we released with in 14.04 (1.0.1) OK, that's good to know. Hopefully there won't be too many? E. g. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=docker shows 6 vulns for 2014, but not all of them apply to 1.0.x. docker is in universe, so we aren't obliged to maintain this for the full duration of the LTS. So once we stop being able to backport security fixes, or that version becomes totally useless for some (good) reason, a last-resort exit path is to replace it with an empty package in -updates: https://wiki.ubuntu.com/StableReleaseUpdates#Package_Removals This of course will hit deployments pretty badly, but might still be better than leaving gaping security holes forever. I'm also keen that we keep deployment repeatable, meaning that an end user of the Ubuntu docker packages can deploy and expand capacity without worrying (within reason) that they are suddenly going to have a version mismatch on the new servers they just added. For those cases it seems prudent to always keep docker as the version that we released with? And only introduce new package names for newer versions, if we want to do that at all. For these reasons, I'm proposing the approach of maintaining three docker versions at any given point in time. [...] with separate meta packages to support: - docker.io-unstable - docker.io-1.4 - docker.io-stable - docker.io-1.3 - docker.io-oldstable - docker.io-1.2 That seems rather complicated, very maintenance intense, and rather aggravating the problem? Instead of one version which we can't/don't want to support for long we'd now have an ever-growing number of them. Once a docker-io-X.Y package is no longer referred to by a meta package, it gets removed from the archive and is no longer installable. So this allows end-users to manage their migration between versions, by directly using the docker.io-X.Y packages, OR track what we consider to be 'stable' or 'unstable' (if people really want to bleed). This is a contradiction though. If we allow people to install docker.io-X.Y directly, there is again no upgrade path when you remove them, and they'd be left with an insecure version forever. But if we replace them with an empty package, you again break people's deployments. I would feel better about this if we'd use -backports for this and always just keep the latest version in trusty-backports for the users who explicitly opt-in; of course this also isn't ideal, but no solution that tries to accomodate stability with fast-moving and compatibility-breaking upstream releases will be. Users who don't opt into backports would just keep using the stable one we released with, for reproducability/reliability. Another option: if docker really wants to be the fast-moving project without maintaining stable releases for a nontrivial time, then we should accept that and not try and keep packaging it into an LTS where we keep the illusion of stability, if we can't or don't want to live up to that promise and actually maintain all these versions. In that case it seems better to directly get docker.io from upstream at your own pace IMHO. There's times when the traditional distro model and the fast-moving upstream model collide :-) So in summary, I'm not sure how this package N versions in parallel is going to help with maintenance effort OR reliability in any way? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Elections
Marc Deslauriers [2015-01-13 11:17 -0500]: ACK for 2015-02-16. +1 from me as well. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Hello again, Martin Pitt [2014-11-11 14:54 +0100]: Hello TB, as discussed in the last meeting, I wanted to put up a proposal for amending https://wiki.ubuntu.com/StableReleaseUpdates for package removals like the recent owncloud. Please check that this graps what we discussed; I'd also appreciate language cleanups. Apparently that got voted on in the previous meeting without telling me (or sending minutes to u-d-a@). I now integrated the proposal into the above page. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: docker in 14.04
Marc Deslauriers [2014-12-05 7:46 -0500]: Wouldn't it be simpler to maintain two docker packages in the LTS release, one that is stable to which security fixes get backported (in the case of trusty, it looks like it's currently 1.0.1), and a second one that is always the latest version? Is there any value in maintaining a multitude of packages with known vulnerabilities in the archive? I'd prefer limiting the number of parallelly supported versions, too. I guess the answer depends on whether the next docker version is fully backwards compatible with existing installs. I. e. if we update docker-current from 1.4 to 1.5, does that break existing installs? If so, then this isn't feasible and we need to start a new series. But if it is compatible I see little reason for keeping the old 1.4 then? Either way, this is a significant increase in 14.04 maintenance work. Who is going to commit to that? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Policy For Sunsetting GPG Keys 2048 Bits
Dimitri John Ledkov [2014-11-28 10:45 +]: My concern with ECC algorithms is smaller key sizes to match equivalent RSA security (e.g. 224 bit ECC key ~= 2048 bit RSA key). Which leads to requiring less quantum computing power to break ECC key over RSA key, thus if/when quantum computing takes off ECC keys will be broken ahead of RSA keys. I don't understand that, why? The relative key sizes of EC discrete logarithm vs. prime factorization based algorithms correspond to the relative complexities of the best currently known algorithm. So while a quantum computer would have to grind through 2^224 possibilities for an EC key (it has to, as there is no known algorithm for the discrete logarithm problem better than O(2^n) brute force), it would certainly *not* grind through 2^2048 possibilities for RSA. Even if the current best (subexponential) algorithm for factorization would not immediately be applicable to quantum computers, there are for sure variants of it which are. I. e. it would only need a number of steps/possibilities which is more like 2^224 than 2^2048. I. e. if you had a quantum computer with 224 bits, ECC 224 bit vs. RSA 2048 bit shouldn't matter? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Hey Kees, Kees Cook [2014-11-11 9:13 -0800]: FTR, this proposal now lives on https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves for easier editing (already did a typo and a grammar update suggested by Robbie, thanks!) I like it, thanks! Is it worth maintaining the explicit list of removals (more than just Examples:)? Yes, I think it is, there won't be too many of those. I adjusted the wiki page accordingly. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Hello Chuck, Chuck Peters [2014-11-12 3:25 +]: Both tor and owncloud are recurring examples! tor was reintroduced explicitly two years after the removal (https://launchpad.net/bugs/413657). If that is out of date again and unmaintained, we should remove it again and blacklist it this time so that it doesn't come back automatically. If that's the case, then I suggest filing a new removal/SRU bug for this. owncloud isn't a recurring example; it was removed now and blacklisted. If we just make an empty package that gives the user some direction on installing upstream, why don't we just do it for them This is *exclusively* a crutch for stable releases to override an undeletable package in a stable release. In the devel series (and hence in all future stable disto releases) the package should be removed completely. We don't want installer packages for free software in the archive by policy. Furthermore amending the SRU process as proposed doesn't really address the fundamental issue of universe packages are often not maintained and with something like tor the consequences can be very dangerous. Right, that's why we are drafting this policy now so that we don't start from scratch every time :-) But in reality most unmaintained universe packages are by far not as dangerous as tor. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRUs for meeting today
Hey Jonathan, Jonathan Riddell [2014-10-28 12:37 +0100]: At the tech board meeting today I'd like the board to consider approving https://bugs.launchpad.net/ubuntu/+source/owncloud/+bug/1384355 ownCloud should be removed This seems like a no-brainer to me. I followed up to the bug with a minor technical detail, but in general this seems fine. and everyone's favourite https://bugs.launchpad.net/ubuntu/+source/kubuntu-settings/+bug/1378789 Added both to the agenda at https://wiki.ubuntu.com/TechnicalBoardAgenda now. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU IO Scheduler in Kubuntu 14.04
Hello all, Steve Langasek [2014-10-14 13:24 -0700]: I don't agree with the highly limited in impact, but I do agree with the compromise of putting the udev rule into kubuntu-default-settings. While this isn't an appropriate long-term solution (i. e. it definitively shouldn't be done that way in Utopic or at least not in V), I don't know of a more appropriate place for an SRU. Note that this change is already present in utopic. Are you asking the Kubuntu team to revert this? Oh, you mean Utopic's kubuntu-default-settings already has that rule? I understood it like we changed the kernel default scheduler in utopic. #1378789 does not explain the fix in utopic, nor does it have a package upload that closes the bug. I suppose this is a case where the SRU is being done on a fresh synthetic bug instead of the real bug report, and so it doesn't have all the relevant information. Anyway, now is not the time to change utopic's kernel default. I outlined here some additional regression testing that I think needs to be part of the SRU plan: https://lists.ubuntu.com/archives/ubuntu-release/2014-October/003071.html *nod* thanks As the Kubuntu team's request specifically concerns asking the TB to expedite the SRU for this Oh, that's not how I understood it. I interpreted proceed with the SRU as land it in -proposed now instead of well after Utopic's release, which I fully agree with. Of course verifying the changes will take quite some time as finding enough people with different SSD/HDD hardware and getting them to do the measurements will just not be done in a week. But then again I see no rush. 14.04 has been out for 6 months, and everyone who uses it either has learned to get along with the sluggishness or disabled balloo, or uses something else. So taking a few weeks in -proposed to be sure about the impact of this seems adequate. I wouldn't tie it to any results in Utopic, as utopic has a different kernel, different software versions etc., so the numbers aren't directly comparable anyway. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies for today
Hello all, I'm at LinuxCon/Plumbers this week, and there is a high chance that I'll miss today's meeting. The main topic today is the Kubuntu SRU wrt. the scheduling policy, I'll reply to that by email. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU IO Scheduler in Kubuntu 14.04
Hello Harald, hello TB, Harald Sitter [2014-10-08 17:03 +0200]: I would like to kindly request the TBs input on a possible IO scheduler changing SRU for Kubuntu 14.04. I followed the discussion in the other thread (on u-devel@?). As seen in comment #5 of [2] it was suggested to wait until after the release of 14.10 and only then proceed with the SRU. Most Kubuntu devs do not appear to agree with this as being too conservative an approach. The possible fallout is highly limited in impact (could only make some things slower) and scope (only could do so on Kubuntu with HDD). I don't agree with the highly limited in impact, but I do agree with the compromise of putting the udev rule into kubuntu-default-settings. While this isn't an appropriate long-term solution (i. e. it definitively shouldn't be done that way in Utopic or at least not in V), I don't know of a more appropriate place for an SRU. Would the technical board support a swifter resolution of the problem or indeed prefer waiting? I think we shouldn't wait with landing that change in -proposed, but do it now so that we can start collecting feedback and doing measurements on this. This will require quite extensive verification/testing on various hardware, which certainly won't be done by next week. This should include some positive results for KDE+balloo on HDD, confirm that the scheduler isn't changed for KDE+balloo on SSD, and that running Unity/zeitgeist with kubuntu-default-settings installed doesn't show a significant regression (some minor timing changes are acceptable, I think). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Standing SRU for new MAAS releases.
Hello Andres, thanks for the updates. (Also, I was on holiday, sorry for late reply) Andres Rodriguez [2014-08-13 19:58 -0400]: testing. We will provide an upgrade path that just works. Can you please expand that? I. e. how do you make sure that existing MAAS deployments that were done with earlier versions continue to work with proposed new versions? How much do protocol changes affect particular hardware, i. e. up to which degree can this be tested automatically with e. g. a bunch of commodity hardware or even QEMU, and which parts would need the actual supported set of hardware, things like ppc64el or ARM servers, or other hardware which is hard to get into a CI environment? We currently maintain backwards compatibility with all of the components, so every upgrade will yield a working MAAS that continues to work as expected. We currently do manual testing for upgrades, but we are in the process of adding automated upgrade testing to our CI. How do you do the manual upgrade testing, and what's the rough structure of testing this automatically then? The what is quite clear now, I'm still interested in the How for regression-testing newer versions against existing deployments. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Standing SRU for new MAAS releases.
Hello Andres, Andres Rodriguez [2014-07-21 14:20 -0400]: - Change DHCP Management in MAAS to make it robust. - Getting rid of moving parts (Getting rid of the usage of Celery, RabbitMQ, others) So none of those are considered public API, it's all through MAAS specific projects? (I. e. it's not supported to inject AMQP requests into the queues from scripts or so, only through MAAS) - Making MAAS easier to use by providing UI and CLI improvements. How do you ensure CLI API stability, to avoid breaking existing scripts? No new dependencies will be introduced into MAAS that are not already in the “main” component of the Ubuntu archive (Question: what about dependencies in universe, can we do a MIR?) As discussed in today's TB meeting, we really don't want to include that into a provisional MRE. This should be avoided at all cost, and if such an exceptional case happens I'd rather have the options be discussed individually in a TB meeting than giving a blanket exception. Extensive QA / Automated Testing of new MAAS releases, including upgrade testing. We will provide an upgrade path that just works. Can you please expand that? I. e. how do you make sure that existing MAAS deployments that were done with earlier versions continue to work with proposed new versions? How much do protocol changes affect particular hardware, i. e. up to which degree can this be tested automatically with e. g. a bunch of commodity hardware or even QEMU, and which parts would need the actual supported set of hardware, things like ppc64el or ARM servers, or other hardware which is hard to get into a CI environment? Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Fwd: Re: Juju Stable Update Policy
I just realized that Curtis didn't reply to the list. Forwarding. Martin - Forwarded message from Curtis Hovey-Canonical cur...@canonical.com - Date: Mon, 28 Jul 2014 12:47:11 -0400 From: Curtis Hovey-Canonical cur...@canonical.com To: Alexis Bruemmer alexis.bruem...@canonical.com, martin.p...@ubuntu.com Subject: Re: Juju Stable Update Policy X-Spam-Status: No, score=-1.9 required=3.4 tests=BAYES_00 autolearn=no version=3.3.2 From: Martin Pitt martin.p...@ubuntu.com Date: Tue, Jul 22, 2014 at 9:05 AM Subject: Re: Juju Stable Update Policy Alexis Bruemmer [2014-07-08 14:05 -0700]: Juju developers and have a specific QA review, and a variety of fresh install and upgrade combinations must be explicitly tested on every cloud that Juju supports (for details see the “Testing a revision” section of the Juju CI Design and Operation document linked below) This really seems to be the crux of regression testing as far as SRUs and existing cloud deployments are concerned. Whenever I try to open the google docs I just get a File unavailable. Sorry, there's a problem with this file. Please reload., so I can't look at the details. Does that mean that newer clients are tested on existing deployments with older servers and agents? Which combinations does that cover? I have updated the sharing policies for the Juju Ci doc, let me know if you still have issues accessing the file. I can see it now, but it still doesn't explain how you test backwards compatibility to existing deployments? Or I can't find it. I can see teh google doc now, but it still crashes on the first mouse click. I think for long-term documentation we don't want to bury that in google docs, but perhaps underneath https://wiki.ubuntu.com/StableReleaseUpdates ? So in summary, I have reasonably good confidence in the currently documented CI, but I need some more convincing about backwards compatibility testing. We don't have automated tests of minor-to-minor-client-to-server yet. We are not scheduled to start work on this feature for a a few weeks. We are added infrastructure to Juju CI to support this and we have done some manual testing to prove how we will automate this. 1. CI will have a store of stable minor jujus: 1.18.4, 1.20.1, 1.21.0... 2. For each new revision of juju, * For each stable minor juju an env will be bootstrapped. * The juju client under test will be run through a series of commands that demonstrate the env can be maintained. * The test will culminate in a destroy environment to show the env can reach its EOL. * An env will be bootstrapped with the new juju * For each stable minor juju a series of commands will test that old client can maintain the new env. * reports.vapour.ws will have a report showing the all combinations pass test suite. 3. Only revisions that pass all tests are considered for release, CI will provide the actual release tarball. 4. CI will gain a mechanism to test a packages built for Ubuntu (ubuntu's packaging rules) that will test the packages pass all the tests the release tarball passed. Demonstrating that juju and the ubuntu packaging are compatible with the versions published in Ubuntu. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board - End forwarded message - -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Juju Stable Update Policy
Hello all, Curtis Hovey-Canonical [2014-07-28 12:47 -0400]: We are added infrastructure to Juju CI to support this and we have done some manual testing to prove how we will automate this. 1. CI will have a store of stable minor jujus: 1.18.4, 1.20.1, 1.21.0... 2. For each new revision of juju, * For each stable minor juju an env will be bootstrapped. * The juju client under test will be run through a series of commands that demonstrate the env can be maintained. * The test will culminate in a destroy environment to show the env can reach its EOL. * An env will be bootstrapped with the new juju * For each stable minor juju a series of commands will test that old client can maintain the new env. Perfect, thanks! That's what I was looking for. Provisional MRE granted (after quick discussion in today's TB meeting), I'll update https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions as soon as this mail hits the archive. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Juju Stable Update Policy
Hello Alexis, Alexis Bruemmer [2014-07-08 14:05 -0700]: Juju developers and have a specific QA review, and a variety of fresh install and upgrade combinations must be explicitly tested on every cloud that Juju supports (for details see the “Testing a revision” section of the Juju CI Design and Operation document linked below) This really seems to be the crux of regression testing as far as SRUs and existing cloud deployments are concerned. Whenever I try to open the google docs I just get a File unavailable. Sorry, there's a problem with this file. Please reload., so I can't look at the details. Does that mean that newer clients are tested on existing deployments with older servers and agents? Which combinations does that cover? I have updated the sharing policies for the Juju Ci doc, let me know if you still have issues accessing the file. I can see it now, but it still doesn't explain how you test backwards compatibility to existing deployments? Or I can't find it. I can see teh google doc now, but it still crashes on the first mouse click. I think for long-term documentation we don't want to bury that in google docs, but perhaps underneath https://wiki.ubuntu.com/StableReleaseUpdates ? So in summary, I have reasonably good confidence in the currently documented CI, but I need some more convincing about backwards compatibility testing. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MRE request: xfce
Hello Jackson, this was discussed on yesterday's TB meeting, and this appears quite similar to the existing GNOME and KDE microrelease exceptions. So we approved a provisional exception for XFCE to see how the first few microrelease updates go. For each update the main use cases for the component should be described and tested. Jackson Doak [2014-06-27 17:51 +1000]: xfce core: other (xfce made): These seem fine. xfce related: catfish lightdm-gtk-greeter light-locker menulibre mugshot These are not controlled by the XFCE upstream stable policy, and are also being used outside of Xubuntu, so the above exception does *not* include these. These related packages will continue to be under the normal SRU policy (which still allows bug fixes). I put the core and other packages on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions/XFCE and will update the MRE wiki page as soon as this hits the ML archive. Thanks, Martin p.p. Ubuntu Technical Board -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Juju Stable Update Policy
Hello Alexis, thanks for writing down the summary, and the initial adjustments after our PMs. Sorry for responding so late, this slipped through the cracks :( In general this seems fine to me, I just have two questions: Alexis Bruemmer [2014-06-26 13:00 -0700]: It is critical that the state server and agents be kept in sync, and both of these sets of machines are created, booted, and managed by Juju. Out of interest, how is that enforced? If you dist-upgrade one VM but not the other, will bad things happen? Or should that be worded differently? Tests are required for all changes, each change must be signed off by two Juju developers and have a specific QA review, and a variety of fresh install and upgrade combinations must be explicitly tested on every cloud that Juju supports (for details see the “Testing a revision” section of the Juju CI Design and Operation document linked below) This really seems to be the crux of regression testing as far as SRUs and existing cloud deployments are concerned. Whenever I try to open the google docs I just get a File unavailable. Sorry, there's a problem with this file. Please reload., so I can't look at the details. Does that mean that newer clients are tested on existing deployments with older servers and agents? Which combinations does that cover? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MRE for juju-core/juju-mongodb
Hello, Robie Basak [2014-06-18 11:24 +0100]: How should I proceed? Will you consider granting at least a one-time MRE for this, please? This was discussed in today's TB meeting. For the record, provisional MRE approved under the condition that from now on juju-quickstart gets tested (manually until LP#1325013 gets implemented) as part of the SRU verification, to make sure it doesn't get broken again. I'll add this to [1]. Thanks, Martin https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Matters approaching
is significantly simpler and still combines the system image and deb package worlds in an useful manner. The other half of this to consider are the installed files. I don't think that we need to do particular measures to ensure that these files are readonly: As long as we ensure in dpkg/apt that the files don't get changed through these tools, any changes which an admin does to the files will just be silently reverted on the next system image upgrade. But that's exactly the same behaviour that we have always had in any dpkg/rpm based system. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Meeting time
Kees Cook [2014-05-12 13:57 -0700]: Okay, sure. I may be late from time to time, but that can work. Great, thanks! I put in the new time on https://wiki.ubuntu.com/TechnicalBoardAgenda then, i. e. 2014-05-27, 17:00 London time / 16:00 UTC. I also asked Matt Zimmerman to update the fridge calendar (or remove his entry, and I can add a new one). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Provisional MicroReleaseExceptions review
Hello all, Brian Murray [2014-05-07 15:33 -0700]: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions/ProvisionalStatus Many thanks Brian! As per Monday's meeting (https://wiki.ubuntu.com/TechnicalBoard/TeamReports/14/May) I moved most of the provisional ones to approved, and keep the others (vlc, LibO, mesa) as provisional for now until we finished reviewing them in detail. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Provisional MicroReleaseExceptions review
Brian Murray [2014-05-14 7:32 -0700]: I don't think iscsitarget should have been moved away from provisional since we had only a month's worth of data and it was not included in the provisional status report. Indeed, that wasn't intended. Thanks for pointing out! Additionally, it would be useful if when packages were added to the provisional section we also added a date for reviewing their provisional status using the same tool. Sounds good. Both done in https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diffrev2=49rev1=48 Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Meeting time
Hello again, Martin Pitt [2014-04-30 10:46 +0200]: http://doodle.com/zmi9m7gfwtyczg5s Now everyone added themselves. Unfortunately there's not a single time when everybody is available, just some which are all-but-one: * Monday 19 to 21: all but Martin * Tuesday and Thursday 18 to 20: all but Adam So perhaps we can alternate between Monday and Tuesday 19:00 (London time, i. e. UTC plus DST) and just live with either Adam or me not being there and catching up by mail? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
Steve Langasek [2014-04-09 12:15 -0700]: This looks mostly good to me. The one request for changing from me is to clarify free licenses; this should at least be free as in beer (i. e. redistributable without fee), but I'm not sure whether it actually means free as in speech (I suppose it doesn't?) This text was changed by me in response to feedback from Iain on IRC. Previously it spoke of GPL/LGPL software, but I agree with Iain that the decision shouldn't encode a specific license. I believe the intent here is to ensure that this new archive is not used for software that should go in the main Ubuntu archive. Ah, so it should (almost?) say the opposite, like freely distributable, but not DFSG compliant? Maybe this is a better way to write that sentence?: Packages developed by the Ubuntu Kylin team that are freely redistributable will be delivered through the regular Ubuntu repository. That clarifies what the free license means, so +1 for me on that. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
Steve Langasek [2014-04-07 17:47 -0700]: Packages in the repository must adhere to the Extension Repository Policy. If there is any exception, there should be a request to Ubuntu Technical Board. I think we should drop the second sentence: there should never be exceptions to the Extension Repository Policy here, but the TB can amend that policy as necessary, so it's redundant to spell this out here. +1, or changing that to Changes to the that policy need to be discussed and approved by the Ubuntu Technical Board. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
Steve Langasek [2014-04-07 17:40 -0700]: The Ubuntu Kylin team has captured this now in a wiki page: https://wiki.ubuntu.com/Ubuntu%20Kylin/Ubuntu%20Kylin%20Archive Let's please iterate there. This looks mostly good to me. The one request for changing from me is to clarify free licenses; this should at least be free as in beer (i. e. redistributable without fee), but I'm not sure whether it actually means free as in speech (I suppose it doesn't?) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [MRE] Iscsitarget 1.4.20.3+svn490 into Precise
James Page [2014-04-04 12:31 +0100]: [r499] Compatibility with 3.13 kernel (LP: #1291641). +1 from me for this, as we are planning to backpor the trusty kernel this needs to be fixed anyway. [r498] Fix backward compatibility patch rules for 3.x kernels. [r497] Fix SERVICE ACTION IN / READ CAPACITY (16) - regression from r488. These seem to be fairly normal bug fixes, and appropriate regression tests to check iscsi on both the current precise as well as the backported trusty kernel should cover these as well. And a single fix in the packaging to make the init script retry unloading of the kernel module a few times if it fails at first. Why does it fail, because the device is still busy? OOI, why does the init script need to unload the kmod at all? If it's at all avoidable, I'd rather not try that at all. I've seen kernel panics, hangs, and other nasty things when trying to unload modules, I wouldn't generally consider that safe especially in such an automatic and hard to avoid way. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MRE request: lxc
Hey Stéphane, Stéphane Graber [2014-04-02 16:19 -0400]: LXC upstream does full automated test runs on amd64, i386 and armhf for every commit to both the master and stable-1.0 branch. We also do test builds and test runs using clang, push daily builds to coverity for static code analysis and do automated cross-builds for Android. The upstream Jenkins server is at: https://jenkins.linuxcontainers.org I poked around and I can only find source builds for LXC itself, and the daily download builds from lxc-templates. Where are the actual test suite runs for CI? I had a look at the test suite[1]. It covers quite a lot of the API, but only the most common cases and often only ensures that the calls don't fail: E. g. it doesn't check that a call like add_device_node() actually does what it promises. But while it doesn't cover many corner cases it certainly covers all the major workflows and functionality, especially the integration tests like lxc-test-ubuntu. These also run in the autopkgtest which we intend to keep running for trusty after the release. I did a spot check of about 10 recent commits, and none of them were accompanied by test updates (in particular tricky stuff like https://github.com/lxc/lxc/commit/0d9acb9 which applies to relatively subtle changes which can easily regress without noticing quickly). Do you have plans to also cover testing of the templates? Bugs like https://bugs.debian.org/743425 are a bit of a bummer to have if they hit a stable release (apparently that's not what happened in that case, though, it's just something which I ran into recently). Seeing the very large amount of SRUs we've been doing in the past few releases, it's my belief that an MRE will save a lot of time to Serge and I as well as the SRU team by simplifying the amount of documentation required for our updates. I can't say that the existing test coverage would be sufficiently reliable to use it as fully automated SRU testing, but for each new microrelease we should run a test plan for the most important scenarios. But with that I have no general objection, especially as the changes you intend to do to the 1.0 branch are bug fix only (contrary to other MREs). So I don't see verifying individual bugs for SRUs as the most important issue here, but regression testing. When doing that, and limiting this MRE to bug fixes only, I'm fine with the MRE. Thanks, Martin [1] Small chuckle: createtest.c creates a busybox container and says trusty container. Totally not important for this mail, of course :) -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hello TB, I'm afraid I can't make today's meeting. Sorry for missing two in a row, but I promise I'll be there at the next one again. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hey all, I can't attend today's meeting tonight, I won't be at home. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: DMB elections
Iain Lane [2014-01-28 16:01 +]: https://wiki.ubuntu.com/CommunityCouncil/Restaffing Recommends 2 weeks each for nominations and voting. Given that, can we extend the terms of the remaining members until the end of February? That seems to be the most sensible option to me, much better than rushing the voting. +1 from me. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Packagesets ownership
Stéphane Graber [2014-01-21 10:06 -0500]: The full list of TB owned packagests can be found here: http://paste.ubuntu.com/6792052/ Does anyone from the TB object to handing over those to the DMB? As the DMB is the body which governs the membership it makes much sense to me to also allow them to administrate them. So +1 from me. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: gthumb follow up in ubuntu baseline request or MRE
Hello Romuald, there currently is no official TB (elections are in progress), but I can make a comment on the current state. Romuald TISSERAND [2013-10-01 17:36 +0200]: Dear Ubuntu technical board,The current version of gThumb in the Ubuntu baseline is 3.0.2 which is more than a year old. But gThumb is still actively developed and maintained. The problem is the gThumb 3.0.2 doesn't work well in Ubuntu 13.10 Beta because of a change in GTK+. This issue, of course, doesn't appear this the last version 3.2.3 released this last august. The current development release (trusty) has 3.2.5 now, and it's now being autosynced from Debian as all our modifications went there. So in the future it should keep itself up to date better. As for SRUing 3.2 into Ubuntu 13.10: If 3.0 works poorly or not at all, and 3.2 is buildable in Ubuntu 13.10, and does not have major UI changes, an SRU certainly sounds adequate. I trust the SRU team to judge this. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SmartScope Server Side Application
Lucio Torre [2013-10-30 12:34 -0700]: The server code that handles all requests from users is not open source. We try to do many things with the data we collect to improve the service, and that changes every day. The question surely isn't about opening the collected data to the public, just the server code itself. Everything we do is within the terms of service and privacy policy of the project. This would be easier to verify if one could see the server-side code. Is there a specific reason why it's closed? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Provisional MRE Request For KDE Telepathy
Hello Scott, Scott Kitterman [2013-09-07 1:20 -0400]: The recent extension of the KDE MRE did not include telepathy related packages because we didn't have a good test case yet. We do now. The follow the KDE maintenance policy, which is generally similar to our SRU policy. We have a set of packages in the queue that I've reviewed. The package contain bug fixes and translations updates. I found nothing that would be problematic. The packages in question are: ktp-text-ui ktp-send-file ktp-kded-integration-module ktp-filetransfer-handler ktp-desktop-applets ktp-contact-runner ktp-contact-list ktp-common-internals ktp-call-ui ktp-auth-handler ktp-approver ktp-accounts-kcm I would like to have a provisional MRE now for 0.6.3 in the queue for raring and then based on how that goes, request a full MRE for the set afterwards. This was officially approved in today's TB meeting. I'll adjust https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions accordingly now. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: UDS Organizers Team Review
Hell all, Chris Johnston [2013-08-20 15:28 -0400]: I was going through the list of people in the ~uds-organizers team as we prepare for another UDS and noticed that quite a few people who are still on the team no longer have an affiliation with Ubuntu. I was wondering if it may be possible for the TB, as it is the admin for the team, to do a review of the members of the team and purge any members who are no longer in a position in which they should be on the team. Going through https://launchpad.net/~uds-organizers/+members I think the following people should be dropped because they left Ubuntu and Canonical or work for Linaro (which has had its own summit for a long time): Amit Kucheria Dave Walker Jesse Barker Marianna Raffaele Martin Mrazik Paul McKenney Zach Pfeffer Will Cooke I'm not sure about the following people: Ara Pulido Christian Reis Jeremy Kerr Stephen Doel Steve Edwards Perhaps we should generally change membership to time out after one year, with self-renewal? That would provide automatic cleanup. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Tech Board nominations and elections due in a month
Hello Mark, the current Tech Board period ends in about a month [1]. Of the current members, Colin Watson and Matt Zimmerman stated that they want to step down. The others haven't explicitly said that they want to continue. As far as I remember, the last time you asked around for and nominated some candiates, asked for their agreement, and then we held an election. Is that still the procedure which you want to follow? Thank you! Martin p. p. the Ubuntu Technical Board [1] https://launchpad.net/~techboard/+members signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: UDS Organizers Team Review
Hello Chris, Chris Johnston [2013-08-20 15:28 -0400]: I was going through the list of people in the ~uds-organizers team as we prepare for another UDS and noticed that quite a few people who are still on the team no longer have an affiliation with Ubuntu. I was wondering if it may be possible for the TB, as it is the admin for the team, to do a review of the members of the team and purge any members who are no longer in a position in which they should be on the team. We quickly discussed this in today's TB meeting and agreed to set the default expiry to one year, with self-renewal. I removed members where it's clear that they don't need membership any more, set the ones who probably don't need it any more to expiry in a month, and everyone else to expire on 2014-06-01 (to avoid expiring in the middle of an UDS). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro Release Exception for OpenvSwitch SRU's
Hello James, James Page [2013-08-16 14:16 +0100]: I'd like to apply for a MRE for the openvswitch package for 12.04 and above. We reviewed the upstream test suite and current autopkgtests. The latter currently hang eternally (and thus the test times out), but aside from that both the upstream tests as well as the autopkgtests look quite fine and appropriate for catching regressions. The TB grants a provisional MRE for this, and will review this after a few successful SRUs. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies for next meeting
Hey Tech board, I will be on holiday and without enough bandwidth/devices/time to be able to make next Monday's meeting. I sent the notes of the last meeting to the list and to https://wiki.ubuntu.com/TechnicalBoard/TeamReports/13/July and I updated the SRU pages according to the decisions back thne, so I think I'm not currently owing any reports/edits at the moment. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Extending the KDE Software Collection MRE
Hello Scott, Scott Kitterman [2013-07-17 15:37 -0400]: For the last 2 1/2 years there has been an MRE in place for the core KDE Software Collection that has worked quite well. We've delivered roughly three post-release updates per Ubuntu series since then without significant issues (we have caught a few issues in our pre-release testing, but I don't think there's been a problem with regressions in -updates). I experienced several of those during my active ~ubuntu-sru time and can confirm this. Based on that success, we (Kubuntu developers) would like to extend this to some additional packages. lightdm-kde (successful SRU in precise for point release) This is the only one which we need to be really cautious about, as breaking it for some users has disastrous effects. Everything else seems good for me, +1 from me for MRE for these. What kind of changes are being introduced into lightdm-kde post-release? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hello fellow TBers, I'm sorry, my stomach is acting up tonight; I'm afraid I have to skip the meeting today, and rather crawl into bed. AFAIR there wasn't much on the agenda anyway. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies
Colin Watson [2013-05-27 15:22 +0100]: It's a UK bank holiday today, so I won't be around this evening. I believe it's a US public holiday too; should we defer the meeting? WFM; the only pending topic that I can see is the discussion of the OpenSSL licensing issue (which we already deferred last time because you couldn't attend, so it would be pointless to try and discuss it today when you also cannot attend). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Readjusting SRU review process
Steve Langasek [2013-05-24 13:19 -0700]: There are definitely times when I have a sense that the SRUs in the queue are not the best use of our time. Every developer has their own idea of what's important enough to SRU, and it's difficult as an SRU team member to be in the position of arbitrating, and rejecting uploads because /you/ don't think they're important. It's also difficult to actually /know/ what's important enough for an SRU when it's sitting in front of you in the queue - some of this only shows up in aggregate after the fact, when we see that -proposed is full of packages that no one has bothered to verify. That's actually a very good point. It seems that over time we have become rather lenient about which kind of fixes we allow as SRUs. My gut feeling is that the current level is just about right for LTSes, but especially with the deemphasized role of the non-LTS releases we should perhaps set the bar much higher again for those? We've tried to mitigate this with stricter enforcement of the requirements around test cases Having those is great, but a separate issue from the severity of bugs. but it seems there is still a big gap between the resources for preparing SRUs and the resources for validating them. Maybe we need to start pushing for self-verification of SRUs more aggressively? With defined test cases, this is less risky than in the past, and if SRU uploaders were explicitly expected to do the verification (if no one else does), then that could help reduce the problem of fire-and-forget SRUs clogging up -proposed with no one to verify them. We have done this in the past for cases where verification for other people proved hard/impossible, like for rare hardware. I don't think that self-verification is a bad thing when being documented properly. It's not even the primary concern for SRUs, as we most importantly need to avoid regressions in them, not necessarily be completely sure that all of the referenced bugs are 100% fixed (as we can always do a followup SRU). My feeling is that having fewer SRUs (for the non-LTSes) altogether would go a long way in raising motivation again; what's your feeling about this? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Catch up with the CC Thursday 30th May
Hello fellow TBers, Laura Czajkowski [2013-05-27 10:06 +0100]: We'd like for some representatives of your board to join us at our next meeting for this on Thursday, 30th May, 2013 at 17:00 UTC. I'm on holiday and in the mountains this Wed to Saturday, so I cannot join this. Does anyone else have time? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Readjusting SRU review process
Brian Murray [2013-05-16 15:19 -0700]: I'm not sure the length of the queue is actually indicative of what needs to be reviewed as we tend to ask people to add missing information, e.g. Regression Potential, to the bug description rather than rejecting the upload. That was also my first thought. That's true for some uploads, but I actually went through the queue and associated bugs, and the majority of old ones didn't have any action on the bugs yet. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU request for custom unity-greeter indicators
Michael Terry [2013-04-30 12:26 -0700]: Hello! I'd like to request an SRU for unity-greeter that contains a new feature. Since this is a feature and not a bug fix, the TB was mentioned as the appropriate place to request an SRU. I already answered, and there have not been any objections from other members in today's TB meeting. So please go ahead, but please ensure that the new D-BUS interface does not cause any regression. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Readjusting SRU review process
Hello SRU team, the Tech board recently received a proposal to forego the review of -proposed uploads and directly accept them into -proposed: https://lists.ubuntu.com/archives/technical-board/2013-May/001613.html https://lists.ubuntu.com/archives/technical-board/2013-May/001618.html In today's TB meeting there was unanimous agreement that this is not a flaw in the defined SRU process, but a flaw in its execution. We do not want to give up peer review for what goes into stable releases, and rather want to address the workflow problem in the SRU team. Does that match your feeling as well, or do you feel differently? There are obviously problems with getting timely reviews at the moment: many items in the precise and quantal queue are one to two months old already, and even raring's queue has rather simple SRUs which are already three weeks old. It seems the regular reviewing days got dropped some time ago. How is the reviewing process currently meant to work, and what do you see as the reasons that it doesn't? Would reintroducing regular review days help against them never turning into your focus otherwise, or have they been ineffective as well? Mabye the team is even too big now for anyone to feel sufficient responsibility for doing reviews? Please don't consider this as personal criticism; we just need to figure out a modus that actually works. Thank you! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU approved without waiting in unapproved
Jonathan Riddell [2013-05-08 14:59 +0100]: Discussing ways to make the SRU process smoother with upstream KDE folks we wondered if uploads to -proposed could go straight into the archive then be approved by ~ubuntu-sru during the 7 days waiting period. If there's a bug which is causing lots of bugs reports upstreams are keen to get updates in ASAP and anything which delays it longer means they spend more time triaging bugs which they have already fixed. It would just remove one of the places this process can be blocked. What does tech board think? I'm not that keen on this to be honest. Quite a number of developers and even technical users are running -proposed, and for a stable update it's always good to have at least two pairs of eyes on a change. At least in my ubuntu-sru time there have been quite a number of uploads which had to be rejected due to missing/wrong LP bug links, a really bad changelog, errors in applying patches, and the like. I also hit changes which were inappropriate for an SRU in the first place. I think it is much better to prod ubuntu-sru members on IRC with this is urgent, can you please review?, and then sort out potential fallout on IRC for faster turnaround times. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU request for custom unity-greeter indicators
Hello Michael, Michael Terry [2013-04-30 12:26 -0700]: https://launchpad.net/bugs/1155157 == The rationale == A Canonical customer asked for some new features in unity-greeter. Specifically: * The ability to add new indicators to the greeter session * The ability to change which user is selected in the greeter (done over DBus) These changes are only really useful for administrators. This customer is using them for automatically selecting a user based on an inserted smartcard. Both these features landed in raring. But for them to be truly useful to the customer, they would ideally see the light of day in precise. This does not change the default behaviour, and happens in an LTS release, so I'm inclined to agree to this. == The details == The patch in that bug adds a new gsettings key /com/canonical/unity-greeter/indicators which lists indicators to load. Note that this is pulled from the gsettings database under the lightdm user, not your everyday desktop user. So a system administrator would likely add a system gsettings override file to modify it. Or call sudo -u lightdm gsettings. This seems fine. It also adds a DBus interface with just one function (SetActiveEntry) to set the currently selected user. This is exposed only on the session bus. Since arbitrary processes cannot be started under the greeter, there is currently no real consumers for the interface. But that's where a custom indicator can come into play. Such an indicator could call SetActiveEntry. I don't really see how this is related to the ability to define which indicators to load? AFAICS these are really two independent changes, and thus should be in two separate patches? This second one does change the default behaviour (the indicator now creating a new D-BUS connection and exporting an object), so this needs careful testing. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies for meeting tonight
Hello fellow TBlers, I'm afraid the cold that I have evaded to catch from everyone around me in the last two months has gotten me at last, I'm not feeling too well. So I figure I'll have a hot bath and early sleep tonight instead of staying awake long for the TB meeting. I responded to Mark's strawman proposal by email already, and it seems we all by and large agree there, except for some details. Thanks, and sorry, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Updated release management straw man for TB consideration
to evaluate whether it’s worth changing our archive naming and management conventions so that one release, say ‘raring’, stays the tip release so that there is no need to ‘upgrade’ when releases are actually published. I wouldn't call it raring, as that sounds too much like the actual stable releases we've been doing. Using a role name like Debian's unstable or rolling or devel seems more appropriate to me. As long as we are still going to have actual 6-monthly releases, I don't think we actually need to reengineer Launchpad for this. We merely need a devel (or whatever name) symlink that keeps pointing to the name of the current development series to keep upgraders at the devel series at all times. As a (possibly) separate matter, in the blog I mention that decoupling platform and apps might help us go faster, and encourage app developers to make the tough choices about which versions of their apps are supported on which releases of the platform. If apps means packages in Ubuntu which are not part of the default install, that has been discussed several times already and I don't think that this works (agreeing to what Colin said). If apps means the new style apps that we are introducing with the new Ubuntu SDK, i. e. which only expose a well-defined API, them I'm all for this. I'd even say that we won't be able to attract a lot of app developers if we can't keep this API reasonably stable. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Release Cycle Changes
Scott Kitterman [2013-02-28 16:28 -0500]: As you are all no doubt aware, a Canonical manager has proposed significant changes to the development and release process for the entire Ubuntu project: https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036537.html Is the decision about this proposal one the tech board will be making or will it be made by Canonical corporate outside the Ubuntu governance process? As a member of both Canonical and the TB I haven't heard an official word about this yet. My expectancy is certainly that changes of this magnitude should be discussed and blessed by the TB. But please let's first have the detailled discussions about the pros, cons, and implementation details at the ML and UDS. However, it's certainly Canonical's prerogative to decide which kind of support model for stable releases it's willing and able to fund. So community and TB discussions have to come to come to a conclusion which will actually work in practice under the boundary conditions of what and how much of the work gets funded. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Re: Flavor Review Request of UbuntuKylin
Hello Jack, Jack Yu [2013-02-21 21:26 +0800]: We updated the Wiki page according to your comments. Would you please check it? Thanks. see https://wiki.ubuntu.com/UbuntuKylin,. Thanks for the updates! Some comments: fcitx vs. ibus: * it provides more efficient and intelligent input experience .. compared to what? ibus with sunpinyin/googlepinyin etc.? This still doesn't describe how you want to fix the indicator, control-center, language-selector etc. wrt. input configuration, as they all assume ibus. * it provides skin options and more developing input engines, such as cloud-pinyin and google-pinyin This suggests that fcitx also just uses the various Pinyin input flavours, which ibus wraps as well? System assistant: * show processes of system, show task list; show the running information, such as memory, CPU, disk, etc gnome-system-monitor does all that and is installed by default. So perhaps this just reduces to making this more discoverable? * manage tasks that auto-booting, to speed up booting time We once had a GUI for this, but it got removed because too many users wrecked their system with it. With both my TB and Desktop hats on I would not recommend adding an UI to manage upstart jobs, it's a guarantee for people to shoot themselves into the foot. If there are particular bottlenecks during boot, they should be fixed instead of switching off potentially crucial functionality IMHO. * scan and remove garbage files As already discussed, having a GUI like computer-janitor would be highly useful indeed. * mount/unmount/manage mobile devices Not sure what this is about, but for creating, formatting, mounting etc. there is GNOME disks already installed by default. mobile devices should be covered by gvfs mostly (PtP, MtP, UMS). These details don't necessarily all need to go to the main UbuntuKylin page of course. Do you have some subpages for the individual goals, or perhaps LP blueprints/bugs? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Minutes of the Technical Board meeting 2013-02-18
Hello Steve, all, Steve Langasek [2013-02-22 1:11 -0800]: On Tue, Feb 19, 2013 at 10:46:09PM +, Colin Watson wrote: On Tue, Feb 19, 2013 at 01:02:02PM -0800, Steve Langasek wrote: * The TB recognizes that requiring already existing upload rights is not * something we can enforce in this case, and that developer merits * should be acquired while working on Kylin instead. This should be * reviewed in six months, until then the Foundations team has agreed to * be formally responsible for the flavour and help out with mentoring, * sponsoring, and release engineering. So the actual quote during the meeting appears to have been: stgraber I guess I'll be talking with slangasek on whether he'd be happy to be a temporary flavour lead for Kylin (or have Foundations do that) until they are familiar enough with everything and have upload rights to do all that themselves As he and I haven't had that conversation yet, I don't think this has actually been agreed so far. :-) Can you clarify what it would mean to be formally responsible here? Speaking for Foundations we are interested in helping the UbuntuKylin team get up to speed and integrated into the Ubuntu developer community so they can be self-sustaining. That's indeed how I understood it as well -- not being a temporary team lead, but helping them with building the first set of images, release engineering, and give them guidance how to become developers, etc. Sponsoring packages in particular can be fanned out to the general sponsoring process, thus should not be limited to Foundations team members. I had a follow-up conversation with Stéphane on IRC, where we concluded that the next steps for getting UbuntuKylin on its feet should probably be: 1) get the correct uploader dev team created in launchpad 2) add ubuntu-core-dev to it as the only member (for now) 3) ask the DMB for a packageset with this new dev team as its uploading group 4) (Foundations) help the UbuntuKylin developers prepare for applying for PPU rights for this package set once it exists Would this plan meet with the TB's approval? That seems straightforward to me, +1. Likewise, my understanding is that we don't have approval yet from the TB to begin building daily images of UbuntuKylin. What further steps are necessary before we begin doing so? I don't think we need TB approval for this. However, I suggest to ensure with IS that we have enough storage space on the various cdimage hosts for an additional flavour. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU Minor Release Exception for Ceph
Hello James, James Page [2013-02-08 14:47 +]: I'd like to apply for a Minor Release Exception for the Ceph package. Thanks for the detailled testing plan. This seems quite appropriate to me in general, I just have some further questions: LTS release updates are made after some time has passed (to allow testing) or if a particularly critical bug needs to get out to users. Updates to LTS releases are numbered with a minor point release Argonaut: 0.48.1, 0.48.2, (0.48.3 released but pending SRU) Bobtail: 0.56, 0.56.1, 0.56.2 So quantal ships the argonaut series, raring the bobtail series. To which Ubuntu releases does this MRE apply to? Ubuntu 12.04 LTS ships 0.41 -- is that also an upstream supported release, or do you propose to update precise to 0.48? (That would then not be a microrelease any more). Proposed SRU Approach - - SRU updates for Ceph in Ubuntu will be aligned to the associated LTS release of Ceph: 12.10 - Argonaut 0.48.x 13.04 - Bobtail 0.56.x This seems to indicate that you don't plan on updating 12.04 LTS. That's fine, I'd just like some confirmation as Ubuntu 12.04 seems to be a much more popular server target than quantal or even raring at this moment? Assuming that you really only want to update to the new upstream microreleases, +1 from me for a provisional MRE (i. e. doing a test run with an SRU to a new upstream microrelease). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Flavor Review Request of UbuntuKylin
Hello Jack, all, Jack Yu [2013-02-18 23:45 +0800]: I'm Jack Yu from UbuntuKylin team. We are applying to be an official recognition as a formal member of the Ubuntu family, commencing with UbuntuKylin 13.04. I have added an review request in the Technical Board agenda and you can find the detail of UbuntuKylin at https://wiki.ubuntu.com/UbuntuKylin. Thanks for taking the (rather inconvenient for you) time to show up at today's Tech Board meeting and discuss some details! The discussion left a few things to clarify and change, please see the meeting log: https://wiki.ubuntu.com/TechnicalBoard/TeamReports/13/February Can we follow up on this either by email or on the next meeting on March 4? Thank you! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Reg Call for new ARB members
Stéphane Graber [2013-01-15 10:19 -0500]: If the rest of the Technical Board agrees, I'd be happy to simply re-enable Jonathan's membership on the ARB without doing the whole vote setup thing. +1 from me. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Brainstorm review: Warn users about attached external drives before installing Ubuntu
Hello Dmitrijs, Dmitrijs Ledkovs [2012-12-29 23:55 +0200]: I have been requested below, to respond to the brainstorm idea Warn users about external drives that are mounted before installing Ubuntu http://brainstorm.ubuntu.com/idea/29984/ Thank you! I forwarded your response to the brainstorm idea. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Brainstorm review: Reinstate option not to install bootloader during installation
Hello Colin, Once you've read the details below, please respond with an acknowledgement and let me know if you can participate. The expected time investment should be about an hour over the next two weeks. The Ubuntu Technical Board has a regular program to respond to top voted topics on Ubuntu Brainstorm: https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview The current review cycle is being tracked at https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview/Dec2012 Our goal is to improve our responsiveness to the questions, concerns and suggestions we receive from the user community. Note that this does NOT mean that we will commit to following the suggestions, but we will evaluate and respond to them. By explaining what we will (or won't) do and why, we will show that we are paying attention and trying to make good decisions on behalf of our users. The way the program works is that the Technical Board identifies people within the Ubuntu project who are knowledgeable in the specific topics proposed in Brainstorm, and asks each of them to write a short response to one topic. One of the most popular topics in brainstorm at present is about reinstating the option not to install bootloader during installation: http://brainstorm.ubuntu.com/idea/29909/ Since you are well versed in this area, we would appreciate if you could spend a short time reading the Brainstorm content about it and writing a few paragraphs. You don't need to have all the answers, and I encourage you to ask for input from others who might have a view on the issue. This can be in the form of a detailed upstream bug report, a blog post, an email, or any other suitable format. It shouldn't take more than an hour or two to complete. Our goal is to have everything ready for publication by mid-January 2013. Can you confirm that you're willing and able to help with this? You can formulate your response as you see fit, but make sure that the tone is sympathetic. Many of the comments in Brainstorm take the form of demands or complaints: just treat these as if they were questions, and answer them politely. Try to listen to the *need* behind the suggestion, not just the suggestion itself, and connect with your audience by telling a story about it. Here are some example formulas which might be helpful to you: * It sounds like the problem described here is X. We address that in Ubuntu today by doing A, B and C. Maybe that's not working for everyone because of Y. We could improve this by doing Z. * I would love to see a new feature like that in Ubuntu. It's consistent with the way other parts of Ubuntu work, and seems genuinely useful. We're busy with some higher priority projects at the moment like X, but if someone is interested in writing a patch for this, I will help them get it into Ubuntu and upstream. * This is a really hard problem without an easy solution. It's complex because of X, Y and Z. It will take some time for this to be completely solved, but here are a few projects we're working on which will make things better, bit by bit. * That's an easy fix. I've written a patch and uploaded it to Oneiric. It will be in the 11.10 release! * That's a great idea, and we already thought of it! Here's the blueprint, and here's how you can follow along as this gets implemented in Natty. * I passed on your suggestion to the upstream developer of the software, and we had a conversation about it. Here's what we decided. * This seems like a genuine problem, but I'm not sure that's the right solution, because of X and Y. I asked our usability expert Jill about this, and here's what she suggested. * I didn't understand what the problem was here, so I had a conversation on IRC with Jamie, who submitted this topic to Brainstorm to understand better. Here's how it went: [...] In the end, we both decided that the best course of action is X. If you have any further questions about what is expected here, please let me know. Thank you in advance! Martin Pitt pp. Ubuntu Technical Board -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Brainstorm review: Warn users about attached external drives before installing Ubuntu
Hello Dmitrijs, Once you've read the details below, please respond with an acknowledgement and let me know if you can participate. The expected time investment should be about an hour over the next two weeks. The Ubuntu Technical Board has a regular program to respond to top voted topics on Ubuntu Brainstorm: https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview The current review cycle is being tracked at https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview/Dec2012 Our goal is to improve our responsiveness to the questions, concerns and suggestions we receive from the user community. Note that this does NOT mean that we will commit to following the suggestions, but we will evaluate and respond to them. By explaining what we will (or won't) do and why, we will show that we are paying attention and trying to make good decisions on behalf of our users. The way the program works is that the Technical Board identifies people within the Ubuntu project who are knowledgeable in the specific topics proposed in Brainstorm, and asks each of them to write a short response to one topic. One of the most popular topics in brainstorm at present is about preventing accidental installation of Ubuntu onto an attached USB drive: http://brainstorm.ubuntu.com/idea/29984/ Since you are well versed in this area, we would appreciate if you could spend a short time reading the Brainstorm content about it and writing a few paragraphs. You don't need to have all the answers, and I encourage you to ask for input from others who might have a view on the issue. This can be in the form of a detailed upstream bug report, a blog post, an email, or any other suitable format. It shouldn't take more than an hour or two to complete. Our goal is to have everything ready for publication by mid-January 2013. Can you confirm that you're willing and able to help with this? You can formulate your response as you see fit, but make sure that the tone is sympathetic. Many of the comments in Brainstorm take the form of demands or complaints: just treat these as if they were questions, and answer them politely. Try to listen to the *need* behind the suggestion, not just the suggestion itself, and connect with your audience by telling a story about it. Here are some example formulas which might be helpful to you: * It sounds like the problem described here is X. We address that in Ubuntu today by doing A, B and C. Maybe that's not working for everyone because of Y. We could improve this by doing Z. * I would love to see a new feature like that in Ubuntu. It's consistent with the way other parts of Ubuntu work, and seems genuinely useful. We're busy with some higher priority projects at the moment like X, but if someone is interested in writing a patch for this, I will help them get it into Ubuntu and upstream. * This is a really hard problem without an easy solution. It's complex because of X, Y and Z. It will take some time for this to be completely solved, but here are a few projects we're working on which will make things better, bit by bit. * That's an easy fix. I've written a patch and uploaded it to Oneiric. It will be in the 11.10 release! * That's a great idea, and we already thought of it! Here's the blueprint, and here's how you can follow along as this gets implemented in Natty. * I passed on your suggestion to the upstream developer of the software, and we had a conversation about it. Here's what we decided. * This seems like a genuine problem, but I'm not sure that's the right solution, because of X and Y. I asked our usability expert Jill about this, and here's what she suggested. * I didn't understand what the problem was here, so I had a conversation on IRC with Jamie, who submitted this topic to Brainstorm to understand better. Here's how it went: [...] In the end, we both decided that the best course of action is X. If you have any further questions about what is expected here, please let me know. Thank you in advance! Martin Pitt pp. Ubuntu Technical Board -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Brainstorm review: No way to control music while screen is locked
Hello Robert, Once you've read the details below, please respond with an acknowledgement and let me know if you can participate. The expected time investment should be about an hour over the next two weeks. The Ubuntu Technical Board has a regular program to respond to top voted topics on Ubuntu Brainstorm: https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview The current review cycle is being tracked at https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview/Dec2012 Our goal is to improve our responsiveness to the questions, concerns and suggestions we receive from the user community. Note that this does NOT mean that we will commit to following the suggestions, but we will evaluate and respond to them. By explaining what we will (or won't) do and why, we will show that we are paying attention and trying to make good decisions on behalf of our users. The way the program works is that the Technical Board identifies people within the Ubuntu project who are knowledgeable in the specific topics proposed in Brainstorm, and asks each of them to write a short response to one topic. One of the most popular topics in brainstorm at present is about controlling the music player while the screen is locked: http://brainstorm.ubuntu.com/idea/29852 Since you are well versed in this area, we would appreciate if you could spend a short time reading the Brainstorm content about it and writing a few paragraphs. You don't need to have all the answers, and I encourage you to ask for input from others who might have a view on the issue. This can be in the form of a detailed upstream bug report, a blog post, an email, or any other suitable format. It shouldn't take more than an hour or two to complete. Our goal is to have everything ready for publication by mid-January 2013. Can you confirm that you're willing and able to help with this? You can formulate your response as you see fit, but make sure that the tone is sympathetic. Many of the comments in Brainstorm take the form of demands or complaints: just treat these as if they were questions, and answer them politely. Try to listen to the *need* behind the suggestion, not just the suggestion itself, and connect with your audience by telling a story about it. Here are some example formulas which might be helpful to you: * It sounds like the problem described here is X. We address that in Ubuntu today by doing A, B and C. Maybe that's not working for everyone because of Y. We could improve this by doing Z. * I would love to see a new feature like that in Ubuntu. It's consistent with the way other parts of Ubuntu work, and seems genuinely useful. We're busy with some higher priority projects at the moment like X, but if someone is interested in writing a patch for this, I will help them get it into Ubuntu and upstream. * This is a really hard problem without an easy solution. It's complex because of X, Y and Z. It will take some time for this to be completely solved, but here are a few projects we're working on which will make things better, bit by bit. * That's an easy fix. I've written a patch and uploaded it to Oneiric. It will be in the 11.10 release! * That's a great idea, and we already thought of it! Here's the blueprint, and here's how you can follow along as this gets implemented in Natty. * I passed on your suggestion to the upstream developer of the software, and we had a conversation about it. Here's what we decided. * This seems like a genuine problem, but I'm not sure that's the right solution, because of X and Y. I asked our usability expert Jill about this, and here's what she suggested. * I didn't understand what the problem was here, so I had a conversation on IRC with Jamie, who submitted this topic to Brainstorm to understand better. Here's how it went: [...] In the end, we both decided that the best course of action is X. If you have any further questions about what is expected here, please let me know. Thank you in advance! Martin Pitt pp. Ubuntu Technical Board -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Brainstorm review: Check the ink level of printers
Hello Till, Once you've read the details below, please respond with an acknowledgement and let me know if you can participate. The expected time investment should be about an hour over the next two weeks. The Ubuntu Technical Board has a regular program to respond to top voted topics on Ubuntu Brainstorm: https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview The current review cycle is being tracked at https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview/Dec2012 Our goal is to improve our responsiveness to the questions, concerns and suggestions we receive from the user community. Note that this does NOT mean that we will commit to following the suggestions, but we will evaluate and respond to them. By explaining what we will (or won't) do and why, we will show that we are paying attention and trying to make good decisions on behalf of our users. The way the program works is that the Technical Board identifies people within the Ubuntu project who are knowledgeable in the specific topics proposed in Brainstorm, and asks each of them to write a short response to one topic. One of the most popular topics in brainstorm at present is about checking the ink level of printers in Ubuntu: http://brainstorm.ubuntu.com/idea/30099 Since you are well versed in this area, we would appreciate if you could spend a short time reading the Brainstorm content about it and writing a few paragraphs. You don't need to have all the answers, and I encourage you to ask for input from others who might have a view on the issue. This can be in the form of a detailed upstream bug report, a blog post, an email, or any other suitable format. It shouldn't take more than an hour or two to complete. Our goal is to have everything ready for publication by mid-January 2013. Can you confirm that you're willing and able to help with this? You can formulate your response as you see fit, but make sure that the tone is sympathetic. Many of the comments in Brainstorm take the form of demands or complaints: just treat these as if they were questions, and answer them politely. Try to listen to the *need* behind the suggestion, not just the suggestion itself, and connect with your audience by telling a story about it. Here are some example formulas which might be helpful to you: * It sounds like the problem described here is X. We address that in Ubuntu today by doing A, B and C. Maybe that's not working for everyone because of Y. We could improve this by doing Z. * I would love to see a new feature like that in Ubuntu. It's consistent with the way other parts of Ubuntu work, and seems genuinely useful. We're busy with some higher priority projects at the moment like X, but if someone is interested in writing a patch for this, I will help them get it into Ubuntu and upstream. * This is a really hard problem without an easy solution. It's complex because of X, Y and Z. It will take some time for this to be completely solved, but here are a few projects we're working on which will make things better, bit by bit. * That's an easy fix. I've written a patch and uploaded it to Oneiric. It will be in the 11.10 release! * That's a great idea, and we already thought of it! Here's the blueprint, and here's how you can follow along as this gets implemented in Natty. * I passed on your suggestion to the upstream developer of the software, and we had a conversation about it. Here's what we decided. * This seems like a genuine problem, but I'm not sure that's the right solution, because of X and Y. I asked our usability expert Jill about this, and here's what she suggested. * I didn't understand what the problem was here, so I had a conversation on IRC with Jamie, who submitted this topic to Brainstorm to understand better. Here's how it went: [...] In the end, we both decided that the best course of action is X. If you have any further questions about what is expected here, please let me know. Thank you in advance! Martin Pitt pp. Ubuntu Technical Board -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request to add cinder and quantum packages to existing OpenStack MRE
Kees Cook [2012-12-03 12:54 -0800]: I'd be in support of a provisional MRE for these two as well. I updated https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions accordingly. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: confirming results of ARB elections
Hello Allison, Allison Randal [2012-10-15 17:26 -0700]: If (as I expect) there are no concerns, could someone with access make the necessary changes to: https://launchpad.net/~app-review-board/+members I added Andrew and Alessio to the team. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: confirming results of ARB elections
Hello Allison, Allison Randal [2012-10-15 12:53 -0700]: The ARB election poll will close a few hours after this week's TB meeting. Would you all be comfortable confirming the results by email tomorrow? In the sense of making the actual changes to the team? I can do that. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
New script to control LP builders
Hello LP buildd admins, I'm often asked to build a package on a particular builder; mostly because only a subset of the PPA buildds are able to build LibreOffice, and sometimes we also want to pick the fastest builder available for an urgent build. I was getting sick of doing the clickery-doo on https://launchpad.net/builders, so I wrote a silly little script to show builders and their state, and set them to manual/auto: $ control-builders list rossdistro activeauto ok sulfur distro activeauto fail (RT#53942) dryad ppa activeauto fail (Resuming failed:) [...] $ control-builders list manual ross dryad You can also grep list and re-use its output: $ control-builders list | grep manual | control-builders auto - to set all manual builders back to auto. It's in lp:ubuntu-archive-tools: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive- tools/trunk/view/head:/control-builders Perhaps it's useful for someone else as well. Thanks, martin -- This message was sent from Launchpad by Martin Pitt (https://launchpad.net/~pitti) to each member of the Build Daemon Maintainers team using the Contact this team link on the Build Daemon Maintainers team page (https://launchpad.net/~launchpad-buildd-admins). For more information see https://help.launchpad.net/YourAccount/ContactingPeople -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: nvidia/fglrx expedited SRUs
Hello Bryce, Bryce Harrington [2012-09-03 17:24 -0700]: Historically, this is how testing has worked: Thanks. This gives me sufficient confidence that major packaging errors and upgrade failures are being spotted. As for broad hardware compatibility, I guess we have to leave that to NVidia's QA, but it seems that in the PPA we should get at least a decent selection of cards already? 1. The SRU bug report is a packaging request. So there really isn't a defined test case. (I guess we could say, Yes, after uploading x.y.z to -proposed, x.y.z is available in -proposed but that seems silly.) In this case it should be a regression test -- does the driver install, upgrade, and build against all supported kernel pacakges that we have, and does Unity still start? 2. The driver changelog tends to be terse 1-2 sentences per fix. So reproducing the original issues can be challenging. I don't think we need to be too focussed on bug verification, given that we just have the option between taking the full package and doing nothing anyway. For this reason we have the -updates package in the first place, so that we can always ship the latest one without having to do extensive bug fix verification and hardware covering. But we should still make sure that it's properly packaged of course. If it fails to build/link against our current kernel, releasing that would indeed be pretty shameful. 3. Invariably someone will comment on the SRU bug that they have a regression with the update, that they don't have with stock. Who knows if they do or not, or even if they're testing the right thing. But this stops the process cold. It should indeed for ordinary packages. I still think cases where your computer suddenly doesn't boot at all should be investigated, and the update delayed; but if the perceived regression is non-fatal, such as a slight drop in framerate etc., I see no reason to not move it to -updates, given the purpose of the package. A. Immediately after release we have the same major versions in nvidia-current and nvidia-current-updates. In this situation, we allow the SRU team to expedite the upload without needing to wait for testing in -proposed. One thing we should keep in mind is that we have had n-c-updates for several releases now. So if people installed -updates in e. g. oneiric, upgraded to precise, quantal etc., they will have -updates from day one. I think for this case, as well as making the process have fewer variables, I'd skip this part and only do B. So that I understand correctly you're suggesting that A be dropped from the proposal? Right. If we move people from the -experimental beta driver back to stock on upgrade (which I think we might want to do), maybe it would be worth considering moving people from -updates back to stock on upgrade as well? That would resolve this use case, and enable us to do the quicker release to -updates? That works for me as well. But I'm not sure whether it's semantically the right thing: I do agree for the -experimental use case after your latest reply, but I'm not sure whether the selection of the -updates driver should be regarded a permanent choice? But either way, I'm fine with either A and move to standard driver on dist-upgrade or only B and always keep -updates. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Meeting time
Hello all, as you undoubtedly noticed, I have some serious trouble making it to the 23:00 CEST meeting these days. When we set up the meeting time, we agreed on adjusting it to summer time, and indeed we did in the first couple of weeks, but these days it seems the meeting has been put to 21:00 UTC again. Any chance we can move it back to 20:00 UTC, or doing another doodle for the current members? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Build Daemon Maintainers
Hello Ehsan, you just sent some log without any additional comments or questions. EhsanJebeli [2012-07-01 11:13 -]: bzr: ERROR: No control file to take the package name from, and --package not specified. That's the only thing that looks like an error. This looks more suitable to discuss in the Launchpad Answer tracker, not here on the Tech Board list. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro release exception for Nova, Glance, Horizon, Keystone
Chuck Short [2012-06-22 10:48 -0400]: We also run a couple of exercises agaisnt the deployment when it happens in the lab. Where deployment is packages from -proposed, or images that were built using the actual packages from -proposed? We need to ensure that there have not been any misbuilds or regressions in the packaging part; i. e. they did not accidentally drop files or put them into a wrong place, or the postinst fails on upgrade, and similar problems which upstream tests do not cover. A deployment test which covers these, together with the continuous upstream integration testing certainly seems adequate for an MRE to me. The feedback about that deployment (or other system integration) test needs to go to the SRU tracking bug (like update nova to 1.2.3 in precise) to let the SRU team know when an update has been rubber-stamped as good to go. This did not happen to any of the bugs in the previous nova SRU and was the main case of why it got stalled. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: GNOME MRE exception
Hello Sebastien, Sebastien Bacher [2012-06-05 16:02 +0200]: The SRU team suggested that the desktop team should apply for a SRU MRE for GNOME to ease SRU work for precise (and other series) so there we go. GNOME used to have a standard feature freeze exception in Ubuntu and got granted MRE for lucid. Their schedule is reliable and they have ui, string and feature freezes on stable series. We got three +1, and actually one would have been enough as per SRU policy. However, for such large projects I appreciate having had a few more opinions here. I added it to the MRE page now: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diffrev2=22rev1=21 I hope I caught the difference between what is released with GNOME in the usual cadence and what is hosted on gnome.org, as we want the former, but certainly not the latter. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro Release Exception request for ubuntuone package set
Hello Rodney, Rodney Dawes [2012-06-14 10:01 -0400]: Ditën e Tue, 05/06/2012 më 17.25 +0200, Martin Pitt ka shkruar: In the first case you should point out how you can verify the actual .debs in -proposed, in a full Ubuntu environment (as that can/will look differently than sandboxes during package build, and packages in PPAs). In the second case you'd keep the individual bug verification, but should justify why UI/feature changes are necessary. We have our own QA resources on Ubuntu One, and have them install all the -proposed packages in a full Ubuntu in a VM to test. We generally do this anyway, as waiting for original reporters to verify fixes may never happen. Based on this, a successful history of new microreleases in -proposed, and a working QA process in U1 (which I have experienced myself during my time in ~ubuntu-sru) I +1 this. I just learned that a single +1 from any TB member is sufficient to grant an MRE. I was not aware of that before, and was waiting for the next TB meeting to finish this. Sorry for the delay! Wiki updated: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diffrev2=21rev1=20 Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: GNOME MRE exception
Hello Sebastien, Sebastien Bacher [2012-06-05 16:02 +0200]: The SRU team suggested that the desktop team should apply for a SRU MRE for GNOME to ease SRU work for precise (and other series) so there we go. GNOME used to have a standard feature freeze exception in Ubuntu and got granted MRE for lucid. Their schedule is reliable and they have ui, string and feature freezes on stable series. Kees pointed out some troubles with hardy GNOME SRUs. I do not actually remember those, perhaps Kees can point to an example? Anyway, almost all GNOME point release packages were quite decent and worthwhile to have, so in general I am in favor of this based on a good multi-year track record. The one exception that comes to my mind is the fairly recent glib change that deprecated something in gsettings. However, this was not actually policy fail, just process fail: the developer did not actually mean to commit this for the stable release and just assumed master would already be for the next major development series. So in sum, I agree to you that desktop and SRU team members should still review NEWS very carefully, and checking that the (filtered) diff looks reasonable. But that is true for all other MREs as well, so I don't consider that a special case. So +1 from me as well. We have three +1 now and an yet undecided from Kees; Soren, Stephane, any opinion? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: micro release exception for LibreOffice
Bjoern Michaelsen [2012-06-13 23:57 +0200]: Playing it by the (current SRU/MRE) book would make it easy for me: I would never touch LibreOffice once it is released with Ubuntu. Strictly speaking I would even leave the cherry-picking of security-fixes to the security team. That's indeed what it comes down to: Either the changes to the microreleases are confined to regression proof bug fixes only (which are SRUable without an MRE even), then we should upload them to stable Ubuntus. Or they continue to introduce regressions (as they repeatedly did in the past), we just don't do them and cherrypick security fixes only. I fully agree to you that it makes no sense to try and pick apart the changes from upstream in most cases, if we don't even have a Launchpad bug report about them. Based on some mails you sent me it seems to me that microreleases of current LibO series should be a lot better than in the past, so I hope that we can upload them. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: micro release exception for LibreOffice
Replying to Kees' answer, as I didn't get Sebastien's answer. Kees Cook [2012-06-13 13:13 -0700]: On Wed, Jun 13, 2012 at 10:05:03PM +0200, Sebastien Bacher wrote: - we have regression in precise and some unfixed data loss bugs - we have a SRU ready to address those (new upstream point release) - the SRU team is not wanting to review that update since we don't have SRU rules compliant tracking for every single commit in the update and they suggested to apply for MRE If that is the only reason why it's not accepted, then I think it should be accepted. The SRU team did accept LibO microreleases in the past, but judging case by case, not by a MRE. As I pointed out in my other reply, and Kees seems to agree, it is premature to grant an MRE for LibO given it's (for SRU standards) rather poor SRU history. Bjoern said that future releases should behave better, so let's give it a chance to prove itself. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro Release Exception request for ubuntuone package set
Hello Rodney, Rodney Dawes [2012-05-30 14:54 -0400]: I would like to request a Micro Release Exception for the ubuntuone package set in Ubuntu, so that we may more efficiently release SRUs to users. A more recent new microrelease in -proposed [1] was in line with thet normal SRU policy, and all the bugs there got properly verified. So my main question is, what is the reason why you ask for an MRE? Usually there is two reasons: * You want to do a large number of bug fixes which already get regression tested through a process other than the current call for testing during an SRU. Prime examples here are landscape-client and nova. * You want to introduce changes in those microreleases which are are not covered by the usual SRU policy, like new features or UI changes. Prime example here is Firefox. In the first case you should point out how you can verify the actual .debs in -proposed, in a full Ubuntu environment (as that can/will look differently than sandboxes during package build, and packages in PPAs). In the second case you'd keep the individual bug verification, but should justify why UI/feature changes are necessary. [tests] I have fairly high confidence in the existing test machinery of U1, and are not particularly worried about regressions there. Thanks! Martin [1] https://launchpad.net/ubuntu/+source/ubuntuone-client/2.0.1-0ubuntu1 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: micro release exception for LibreOffice
Hello Bjoern, Bjoern Michaelsen [2012-06-01 12:07 +0200]: I would like to apply for a micro release exception for LibreOffice. In general I think it does make sense to use the new upstream microreleases, to benefit from their QA process and from the testing that happens in PPAs. However, I still have some concerns/questions: Is there a written policy what kind of changes are permitted in stable upstream branches? How does that compare to our SRU policy? We did have more than one attempted LibO (and OO.o back then) SRU which never made it to -updates because the new microrelease introduced a regression (e. g. #919659, #623267). Can we do, or have there been, policy changes or test improvements to prevent these? How we make sure that the changes also work on ARM platforms? What is the main motivation to ask for a MRE? Are there usually/often too many changes, or fixes which do not have corresponding LP bugs to verify them individually? Or do the stable branches get new features, UI changes, or invasive changes which carry a high risk of regressions? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Giving the SRU team the power to review bugs fixes upstream updates?
Sebastien Bacher [2012-06-04 11:58 +0200]: I've been talking to Steve Langasek about that and he said those happened to be ok before just because Martin by its TB membership had the power to accept those but the non-TB members of the SRU team can't because the TB didn't grant the SRU team the rights to take those decisions. That's not how I perceived it. As an individual TB member I don't have the formal power to change Ubuntu policies, only as part of a voting of the TB. I usually review the diff of microreleases, read changelogs, the patches etc., and then accept (or not) the update based on my gut feeling/experience how regression prone they are, how many bugs it fixes, whether there are a lot of users subscribed to the fixed LP bugs, i. e. about the risk/benefit ratio. I just happened to review most of the GNOME updates because I had spent the most time on SRU reviewing out of the SRU team members, and probably also because e. g. Clint rightly prefers the desktop guys to review GNOME related uploads, just as I defer to Dave or Clint to judge about intrusive server-side SRUs. In practice it means that updates like libreoffice 3.5.3 to 3.5.4 have no chance to go in as a stable update under the current rules, I reviewed a recent LibO point release, and the changes were not actually that dramatic. There was an order of 10 bug fixes, and perhaps some translation updates, not much different from the average GTK microrelease update. Quite a lot of them also had real LP bugs with lots of users subscribed. It's certainly far away from the scale of changes that Firefox or new Nova versions introduce. - open 15 bugs for SRU tracking, which is tons of work, will probably lead to a high number of unverified bugs (who is going to verify all those that's not an issue in practice but we need to create a bug for the upstream commit) This is indeed not a practical solution at all. The point of SRUs is mostly to fix already existing bug reports, not reports that we synthetically create -- there are no affected users subscribed to the latter who could confirm that a fix works, or who we even reach with a general call for testing. It might make sense to open one or three synthetic bug reports for an upstream update if we can reproduce the problem easily and consider it important to fix in stable. If not, then don't SRU really does seem like the most adequate option to me. I would like to suggest that the TB should give the rights to the SRU team to review and accepted updates on those relaxed basis, what would be the right medium to start this discussion? (this email? a meeting agenda? a discussion on one of the project's list?) It has always been my practice (with my former SRU hat on) to not treat the SRU policy strictly to the letter, but apply them with the right amount of common sense to a particular update. We select people into the SRU team whom we trust to be able to make a decision about the risk/benefit factor of a particular update, and whether a new version has a chance of being sufficiently verified. Sometimes SRU team members require additional testing and feedback on particular bugs, etc. IMHO the nature of changes introduced in our SRUs, as well as them being highly dependent on the current circumstances (point in the release cycle, interactions with particular upstreams, customer requests, etc.) is way too complex anyway to put it into a concise and precise policy; I see no way around human interpretation here. If the current SRU team feels differently about this now, and they want to be more strict about what they accept, then I suggest to discuss the consequences of that with the SRU team, preferably with some actual cases of SRUs that are now being rejected, but should go in. With my TB hat on I had no problem with the previous and more relaxed application of the SRU policy, but I realize that due to my double role I might have been biased there. What do the other TB team members think? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro release Exception for Nova, Swift, Glance, and Keystone
Hello Clint, Clint Byrum [2012-05-06 12:12 -0700]: Excerpts from Martin Pitt's message of Sat May 05 12:52:34 -0700 2012: The current SRU has been in -proposed for 5 months now, without any feedback about formal testing, and has been supeseded by a security update months ago as well. So based on this I think we'll need a few more trial runs before I agree to a general microrelease exception. I'm not so sure I agree that there has been no feedback. There are certainly verified bugs, but I meant feedback in the sense of we ran these test suites and these regression tests with the proposed version and they all succeeded. The nova SRU fixed *38* bugs. Our usual SRU verification process is mostly cumbersome red tape compared to the review process that the stable updates team for OpenStack used to get these fixes in. 8 of the 38 bugs were verified. Exactly, MREs with new upstream versions are usually like that: We don't verify that every single of many bugs is actually fixed, but we have a plan for regression tests with good coverage (which is the more important part for these updates). The whole point of these types of exceptions is that we get more fixes shipped to users when an upstream project takes sufficient steps to reduce regression potential. I agree. But I haven't seen any regression testing, so I was wondering what happened behind the scenes there. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Extension of postfix microversion exception
Scott Kitterman [2012-05-01 12:48 -0400]: Given the successful trial, I would like to get general approval for this going forward. +1 from me based on the previous successful trial, the existance of upstream regression tests, and a qa-regression-tests integration test. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Extension of postfix microversion exception
Scott Kitterman [2012-05-01 12:48 -0400]: Roughly half a year ago, I asked for a microversion exception for postfix and the tech board agreed to give it a trial: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011- October/000902.html As requested, we did a trial run of this in Natty and it went well (and then I got busy with some other things): https://launchpad.net/ubuntu/natty/+source/postfix/2.8.5-2~build0.11.04 Given the successful trial, I would like to get general approval for this going forward. Enough +1'es now, added to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: tmpfs for /tmp
Hello Phillip, Phillip Susi [2012-01-13 15:39 -0500]: Bug #18661 has been requesting that /tmp be mounted as a tmpfs since 2005. Either this should finally be done, or marked as wontfix. I would like the TB to decide if this should be done or not. If not, please mark the bug as wontfix with the rationale, if yes, then it should be as simple as changing the default fstab file in the mountall package from fs type none to tmpfs for /tmp. Now that precise is out of the door, I think we should revisit this question. A tmpfs /tmp/ is much more efficient for the bulk of stuff that goes to /tmp than a real hard disk file system, as it avoids disk wakeups, unnecessary IO, etc. The regression potential with that change is that there are programs which assume that they have plenty of space in /tmp; e. g. Firefox downloads things there, unless you use Save as... There might also be CD burning programs, video encoders etc. which try to place huge files there. So we need to identify those and fix them to put large stuff into /var/tmp/ instead. In practice it doesn't seem to be so bad, though. I've been running with a tmpfs /tmp for quite some months now without problems, but then again my computer usage habits are fairly regular and presumably much different from the average user (e. g. I don't do video editing or CD/DVD burning at all). I think early quantal would be a great time to enable this, so that we have some time to identify problematic programs. I heard that Fedora plans to enable this as well, so there's some potential for collaboration and sharing results, too. What do others think? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Won't be attending today's meeting - me too
Hello all, I'm travelling back from a family event tonight, and won't be able to join the meeting either. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
