Re: Setting NotAutomatic for hirsute+1-proposed
On Tue, Nov 01, 2022 at 12:22:00PM +0100, Steve Langasek wrote: > Unfortunately this discussion foundered on lack of consensus about whether > to make this change after the fact for stable series; which resulted in both > jammy and kinetic going out without this being set. > > I have set the flag now for lunar as it came up in discussion with > Foundations. The question of whether to change this for stable series is > still open (now with some further series that are stable) but can be > discussed separately. Cool, thanks. > Colin, will this flag be inherited in the future at series opening? Yes. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Setting NotAutomatic for hirsute+1-proposed
On Mon, Dec 13, 2021 at 08:32:53AM -0500, Dan Streetman wrote: > Just to clarify, people won't need to manually specify all > dependencies, right? For example, if testing the 'systemd' package > from -proposed, simply doing 'apt install systemd/jammy-proposed' > would install the proposed version of systemd *and also* the proposed > version of libsystemd0? That's how it behaves in my tests, yes - if a dependency imposes a version constraint requiring a lower-priority version, then apt tries to satisfy it. > Also, is this really needed? Is it really so hard for people to just do: > > $ sudo add-apt-repository -p proposed > > ...install proposed package(s) normally and do tests... > > $ sudo add-apt-repository -r -p proposed This has been an issue on and off for at least a decade, so my impression is that we have solid empirical evidence that this is indeed too hard for many testers in practice. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Setting NotAutomatic for hirsute+1-proposed
On Wed, Feb 03, 2021 at 11:12:57AM +, Iain Lane wrote:
> I think the Launchpad support is still missing, although we started on
> this several years ago. That will need to be picked up and finished off:
>
> https://bugs.launchpad.net/launchpad/+bug/1016776
>
> That bug report talks about doing it pre-release (for devel only) but I
> think I'm now in favour of doing it always, and the proposed
> implementation in there would allow that. For devel, the main reason is
> that I frequently come across users who have misunderstood what proposed
> is for and manually enabled it themsleves, resulting in various degrees
> of brokenness on their systems and bug reports that take developers'
> time to triage and eventually close. These are not (always) people who
> have updated from a previous release, where we could have had tools
> disable -proposed for them, but also people who have explicitly turned
> it on after installing a daily out of an attempt to help test the
> upcoming release.
>
> On the client side, as Robie says, we will at least need to update
> documentation. I'm also not sure what update-manager will do if there
> are NotAutomatic updates present. It might need some tweaking to show
> them differently. This could be checked by looking at something in
> -backports, which is already present with these flags set.
>
> And finally, there's some implication for package builds; both Launchpad
> buildds and other builders would need to ignore this. Launchpad does
> this for -backports currently, i.e. -backports builds get Build-Depends
> from -backports wholesale; hoepfully that means the buildd side isn't
> too hard because we can reuse that.
This is now ready to use from the Launchpad point of view. There's a
"proposed_not_automatic" flag on distro series exported over the API; if
this is set to True, Launchpad writes "NotAutomatic: yes" and
"ButAutomaticUpgrades: yes" to the Release file. We've also arranged
for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad
builds will ignore this; I can't speak for other build environments.
Thus, from the Launchpad point of view this is ready to use, although
somebody may want to check the behaviour of things like sbuild and
pbuilder first.
Somebody in ~techboard would need to make the actual change, if you
think it's appropriate. For example, the following in "lp-shell
production devel" would do it for all supported Ubuntu series:
for name in ("bionic", "focal", "hirsute", "impish", "jammy"):
series = lp.distributions["ubuntu"].getSeries(name_or_version=name)
series.proposed_not_automatic = True
series.lp_save()
--
Colin Watson (he/him) [cjwat...@ubuntu.com]
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: techboard deactivated by cjwatson
On Wed, Nov 04, 2020 at 05:35:42PM -, Ubuntu Package Archive Administrators wrote: > The membership status of Ubuntu Technical Board (techboard) in the team > Ubuntu Package Archive Administrators (ubuntu-archive) was changed by > Colin Watson (cjwatson) from Administrator to Deactivated. > <https://launchpad.net/~ubuntu-archive> Apologies if this caused any alarm or confusion. What happened here was: * José Antonio Rey pointed out to me that it was a bit odd for ~ubuntu-archive to be owned by me (which was for ancient historical reasons) rather than being properly part of the Ubuntu governance structure and owned by ~techboard. I agreed and reassigned its ownership to ~techboard. * As a result of the change of ownership, Launchpad implicitly added ~techboard as an Administrator to ~ubuntu-archive. * It seems more appropriate for ~techboard to be a non-member owner: that's used for cases where the owner should be able to exercise governance authority over the team, e.g. recovering it if all its admins go AWOL, but where members of the owning team aren't intended to be able to exercise the direct powers of the team as a matter of course or by accident. I therefore removed ~techboard from ~ubuntu-archive's membership list again, which resulted in the email above. Perhaps unfortunately, no email is sent on reassigning ownership or for the resulting implicit membership change, so it looks like something odd happened, but the net change is just that the owner of ~ubuntu-archive used to be ~cjwatson and is now ~techboard. Hope this is marginally clearer than mud now! -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Help Getting Bug Reports in Issue Tracker
On Fri, May 26, 2017 at 02:42:06PM +, Mingyue Yang wrote: > I am currently looking into bug reports in the issue tracker of your > project: https://bugs.launchpad.net/ubuntu/. However, crawling the > bug tracking repository may not be the best thing to do, as it may > be harmful to the website. Thus I am wondering if it is possible to > obtain the entire bug tracking database including information for > all bug reports? We won't provide dumps of the database, as it contains a great deal of private data. Please use the Launchpad API for this sort of thing: https://help.launchpad.net/API/launchpadlib Regards, -- Colin Watson [cjwat...@ubuntu.com] -- 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
On Wed, Nov 12, 2014 at 07:53:13AM -0500, Marc Deslauriers wrote: On 2014-11-12 05:43 AM, Martin Pitt wrote: 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. Perhaps blacklisting for new releases by default should be added to the procedure? We can always remove a package from the blacklist if someone steps up and volunteers to support it. If a package has previously been in Ubuntu and has been removed, then it won't be auto-synced (although it will show up in the output of auto-sync for manual resolution; currently only I see that). It normally isn't necessary these days to preemptively blacklist things when you remove them. If a package actually reappears, it might still be worthwhile to blacklist it then in order to quieten auto-sync, but you don't need to do that preemptively. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Fwd: [Bug 1289977] Re: Ubuntu 14.04 Update breaks grub, resulting in error: symbol 'grub_term_highlight_color' not found
On Thu, May 29, 2014 at 09:40:34AM -0400, Phillip Susi wrote: Indeed, part of the problem is that everyone piled into the same bug with several different issues rather than troubleshooting it on a case by case basis. This certainly happens, and I realise that's annoying; any bug like this is likely to be only partially fixed, and at some point people who still have problems will need to be directed to file new bugs rather than continuing to comment on the closed bug. However, closing the bug without making any technical changes is likely to be read as blowing *everyone* off, no matter the good intentions, and just compounds the problem. It wasn't a starting point for a conversation; I had tried dozens of times for weeks to get more information, identify the cause(es), and explain why it was a result of incorrect action on the user's part. That statement was made in direct response to someone saying that as a user they felt they needed to reopen it ( yet again ) without understanding why I had closed it, or offering any real counter-argument. By that point I was throwing my arms in the air. When people repeatedly reopen a bug, it's often worth considering whether it was actually the right thing to do to close it in the first place. The sheer number of people affected by this class of bugs is an indication that we shouldn't be closing it out of hand, even if you don't immediately see what we can do about it. Given that we have extensive maintainer script code for dealing with situations like this, there's clearly scope for further improvement. It would be helpful if you would comment if you think there actually is something that might be done. Since this had gone on for some time without any comment from you, I assumed you were ignoring it as just another kvetch fest. I certainly would be interested in any ideas you might have. I'm afraid I don't have time to read more than a tiny fraction of the bug mail I get, although this had been escalated to me by several folks in my management chain and I'd put it on my to-do list for 14.04.1; I'd just been heads-down in the image build infrastructure changes I'm currently doing, so hadn't emerged for long enough to dig through the bug. I don't yet have specific fixes in mind, but there is certainly plenty of fodder for investigation here. For example, skimming through the bug log, I see an instance (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977/comments/207) where somebody swapped disks and then the maintainer scripts didn't realise that they needed to install GRUB to the new disk. This situation is *specifically* intended to be handled by the maintainer script code I wrote some time ago (and wrote up in http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-06-21-grub2-boot-problems.html), so if it's failing then I need to investigate that, not discard it as a situation we can't fix. This is a long-standing class of bug, although the precise details have varied over time. The reason it's so difficult to address is that the root causes are often far removed in time: if you get your configuration wrong then you often don't find out about it until the next upgrade. That makes this very challenging to deal with, although not impossible. In many cases this is user error, narrowly defined (that is, the user did not do the right thing, but perhaps we didn't do much to help them know what the right thing would be). Still, it's still sometimes possible to detect it heuristically and offer to correct the situation on upgrade: given that the result of failure is a failed boot, it's worth going beyond what we would ordinarily do to handle user error. For example, I'm considering approaches such as looking for binary signatures which would serve to identify GRUB across a wide range of versions, or patching grub-install to leave a note for future grub-pc.postinst runs, or going through my existing detection code again to try to find paths where it's supposed to ask questions but fails to do so. The other strand of investigation is to try to track down reasons why this happened in the first place. For example, I suspect that there may be some paths where installing Ubuntu leaves the wrong thing in grub-pc/install_devices. I'd also like to go through some of our user-facing documentation such as https://help.ubuntu.com/community/Grub2, and try to cut it down a bit and review closely for any inaccuracies. If I find time I'd also like to review tools such as boot-repair and see if I can make sure that they don't fix immediate problems while leaving future timebombs around (which might relate to patching grub-install). That's a rough idea of what I plan to look at here. As you can see it's extensive and will require a good deal of continuous concentration; I expect to have to carve out at least three solid days to work on this. -- Colin Watson [cjwat...@ubuntu.com
Re: [Fwd: Bug 1223199 - Unnecessary deps on packages that lock in things like Mir when not wanted.]
On Tue, Oct 01, 2013 at 01:04:31AM +0100, Phil Wyett wrote: Forwarded Message From: Phil Wyett one.u...@gmail.com Reply-to: one.u...@gmail.com To: technical-board@lists.ubuntu.com Subject: Bug 1223199 - Unnecessary deps on packages that lock in things like Mir when not wanted. Date: Wed, 25 Sep 2013 14:42:37 +0100 Dear Technical Board, I a have a concern regarding deps being added to certain packages that are not really needed. My specific concern is the adding of Mir related dev packages to Mesa packages. Please could you look at the following bug. https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1223199 The Mesa packaging in Ubuntu enables the Mir EGL display, and as a result this dependency is unsurprising to me: it seems likely that it's required for reverse-dependencies to behave properly. The dependencies of -dev packages typically reflect the configure options found in their source packages. In general it is standard practice in both Debian and Ubuntu to configure packages with all reasonable and non-conflicting options enabled, in order to maximise the usefulness of the pre-built binaries we supply. (I recall that there used to be a general statement about this in the Debian Policy Manual many years ago, although I can't find it just now.) On occasion it is necessary to run separate build passes with different feature sets, but this is expensive in various ways and has never been the default practice: we only do this when there is no reasonable alternative. In this case, libegl1-mesa-dev only pulls in the Mir client libraries, for a total .deb size of around 270KiB plus a few generic odds and ends like libboost-system1.53.0 and libprotobuf7. Their presence has no effect on the host system's behaviour and doesn't enable the Mir compositor itself. Regardless of whether this was Mir or something entirely different, this isn't something I would consider it appropriate to split into a separate package; leaving aside emotional arguments about Mir, I can see no strictly rational reason to avoid this dependency. A package split without good reason would contribute further to bloating the Packages file, which has incremental costs all over the place. Furthermore, this is only a dependency from a -dev package, and therefore it seems unlikely that it would pull even this relatively modest set of library packages into any images. I don't see how this has an effect on other flavours or derivatives; it should principally affect package builds, which should be performed in clean chroots anyway. If it does affect other flavours or derivatives, please provide specific technical details, rather than fairly general comments about bloat and pollution; when bringing a dispute to a body such as the Technical Board it will help your case if you try to avoid polemic language. At this point I see no cause for concern; I am confident that the analysis above is objective enough that I would not see a cause for concern if this were a change introduced by somebody outside Canonical, nor if I did not work for Canonical. I'm willing to look at it again if shown further technical argument. I am also concerned with many bugs these days are getting marked as they are with no justification or explanation. I agree that it was not particularly helpful to mark the bug as Won't Fix without explanation, and I think that practice should generally be deprecated. You seem to have escalated to the Technical Board rather rapidly without first trying to find common ground on the bug report, so I infer (I may be wrong) that perhaps there is some history of disagreement between you and Timo; even so, at least a copied-and-pasted explanation of the status change would have been usual. CCing Timo to suggest this for the future. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: provisional MRE review
On Mon, Aug 19, 2013 at 01:27:09PM -0700, Kees Cook wrote: On Mon, Aug 19, 2013 at 12:49:07PM -0700, Kees Cook wrote: 2012-07-23 vlc 0 So, this one seems easy: in a year, there have be 0 MREs of VLC. I say we eliminate this from pMRE status, since there's been no history at all. Are you sure? https://launchpad.net/ubuntu/+source/vlc/+publishinghistory suggests otherwise. I think perhaps there was something wrong with the script used to generate this. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: UDS Organizers Team Review
On Mon, Sep 02, 2013 at 06:40:14PM +0200, Martin Pitt wrote: 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 Also: Hugh Blemings (was here due to being temporary Foundations manager) Michael Hope (Linaro) -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: ubuntu-devel posts from non-developers
On Mon, Jul 08, 2013 at 08:18:24PM -0400, Scott Kitterman wrote: On Monday, July 08, 2013 04:56:40 PM Jono Bacon wrote: Quite some time ago (2006 I believe), we instituted a policy that only members of ubuntu-dev could post to ubuntu-devel without express moderator approval. Recently I have been noticing quite a few non-developers posting to the list - was this policy changed? I have just been noticing that the discussion has become a little less focused than it used to be. I also appreciate the irony of this as I am not an ubuntu-dev, but my concern is not about rejecting all non ubuntu-dev folks, just that it seems a greater regularity of non ubuntu-dev posts of late. Posts have from non-developers have always been allowed, they are just moderated and released after moderator review. AIUI, moderators have also whitelisted some non-developers after a good experience of valuable contribution. I don't think that should change. Yep. We do continue to reject posts that are unsuitable or more suitable elsewhere, too. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies
On Mon, May 27, 2013 at 04:27:20PM +0200, Martin Pitt wrote: 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). I suspect that is at least in part overtaken by events anyway, since I hear MongoDB upstream has added / is adding an exception. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies
On Fri, May 10, 2013 at 02:53:39PM -0700, Matt Zimmerman wrote: I won't be able to make it to the meeting Monday due to another commitment at work. I'm afraid I won't either; I'm very tired from considerable travel over the weekend and have family-related stress at the moment in conjunction with vUDS coming up, so another evening meeting is rather too much for me right now. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: openssl as a system library
one choice of many that plug into the same generic slot, then it doesn't matter - but the problem at hand here only arises because it hasn't been made to work with GnuTLS!). Secondly, we need to consider whether OpenSSL meets the requirements of general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. The example that follows appears to suggest that this is for things you use using narrow arm's-length interfaces, for example forking sed and reading its output, and it specifically calls out shared libraries ... that the work is specifically designed to require as cases that still fall under Corresponding Source. Again, if MongoDB were not specifically designed to require OpenSSL - if it were possible to plug in something like GnuTLS - then we wouldn't be having this discussion in the first place. So I'm afraid that, while the reasoning does seem to differ for the GPLv3, I think the general position still stands. In fact, since it isn't grounded in a dispute about whether two packages we ship accompany each other, the argument seems if anything stronger for the (A)GPLv3. One of the common bug and feature requests we get is squid to support SSL[0][1]. We know that a significant volume of openssl users, take the source package and make minimal modifications to rebuild it locally, with openssl support. Judging from the bug reports, this also seems to affect ubuntu.com’s services that use SSL (ie, the Ubuntu packages are not even fit for Ubuntu infrastructure). In this specific case, at least one squid upstream developer has explicitly stated fairly recently that it's a violation to distribute squid linked against OpenSSL, so I have an extremely hard time seeing how we could possibly start doing so without a similarly explicit statement of permission, regardless of any unilateral decision about how we interpret the system library exception: http://www.squid-cache.org/mail-archive/squid-dev/201206/0075.html Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Builders problem
On Thu, Apr 11, 2013 at 10:18:59AM -, LocutusOfBorg wrote: Hi Admin, I'm contacting you since I see two builders stuck since a while https://code.launchpad.net/ubuntu/+archive/test- rebuild-20130329/+build/4443615 https://code.launchpad.net/ubuntu/+archive/test- rebuild-20130329/+build/4443613 It's better to post on https://answers.launchpad.net/launchpad for this kind of thing; contact this team's admins has various problems that make it not very useful for this, and in this case your message ended up in a moderation queue for ages. (The builds in question appear to have been dealt with by now.) Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: aatxe builder locked
On Sat, Apr 06, 2013 at 09:57:55AM -, dino99 wrote: the libgearman package seems to fail to terminate, so locking that builder This seems to have been dealt with. Contacting the buildd-admins via the LP web UI is not really a good way to report this kind of thing. Firstly, it hits moderated mailing lists in at least one case which results in delays. Secondly, contact this team's admins has the problem that admins don't get to see if other admins have already replied, so it wastes people's time. You'd be better off using the ask a question interface on Launchpad instead, and that's monitored by people who can do something about this kind of problem: https://answers.launchpad.net/launchpad/+addquestion -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: more engineering management to add to UDS Organizers
On Wed, Mar 27, 2013 at 01:39:16PM -0700, Steve Langasek wrote:
Echoing Kevin's request, here is another batch of engineering managers that
we would like added to the UDS Organizers team for blueprint management:
Pat McGowan: pmcgowan
appears to be pat-mcgowan instead
Bill Filler: bfiller
Michael Frey: mfrey
Zoltan Balogh: bzoltan
Done.
--
Colin Watson [cjwat...@ubuntu.com]
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Builders problem
On Tue, Mar 12, 2013 at 09:09:20AM -, LocutusOfBorg wrote: How do you feel about cancelling this build [1]? it is private, but 27 days is a little too much for a build... [1] https://code.launchpad.net/builders/musimon Thanks for the note. I've asked the operators to cancel this. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: panlong builder hanging
On Mon, Mar 18, 2013 at 03:27:48AM -, dino99 wrote: ...three days later, that Panlong builder still has not killed the python2.7 i386 built. It seems to have been sorted out now. each built should be associated to a timeout script that automatically kill the failing compilation sbuild will normally kill the build after 150 minutes of no output. I'm not sure why that didn't happen here; without the +build URL for the individual build in question it's hard to be sure. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Publish summary of decisions from March 18 meeting?
On Tue, Mar 19, 2013 at 11:09:02AM -0700, Elizabeth Krumbach wrote: Tech Board, News outlets have begun covering the votes from your meeting[0] yesterday: http://www.h-online.com/open/news/item/Ubuntu-to-halve-support-length-for-non-LTS-releases-1825716.html http://www.webupd8.org/2013/03/ubuntu-technical-board-meeting.html As a result, questions have started popping up about whether these decisions are final, specifics of what they mean and more. Would it be possible for someone to send me a more official summary of what was decided that we can post on the Ubuntu News site fridge.ubuntu.com? Thanks for your help, on behalf of the news team. [0] http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-03-18-21.01.moin.txt Yeah, I assumed Matt was going to do this as part of meeting-chair duties. Matt, do you have time for this, or do you need somebody else to sort it out? -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies for this evening
With vUDS coming up, I'm going to have my fill of evening meetings this week; and furthermore I have some fairly ugly ADSL bandwidth problems at the moment which mean that I can barely load wiki pages while doing anything else at all bandwidth-intensive, like, you know, being on IRC, so checking any references during a meeting is likely to be unconscionably painful. I will check the IRC logs afterwards to see if anything interesting happened ... -- Colin Watson [cjwat...@ubuntu.com] -- 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
this in six months' time. My understanding is that formally responsible in Martin's minutes should be read as something like responsible but only for form's sake. A better phrasing would be to say something along the lines of indicating that the Foundations team has agreed to support the flavour until such time as they can fend for themselves. Would you be OK with that? -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MAAS SRU
On Tue, Jan 29, 2013 at 07:40:03PM -0500, Andres Rodriguez wrote: Request an exception to SRU MAAS to both Precise (and its required dependencies) and Quantal. Thanks for raising this. You can find our decisions from yesterday's meeting here: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-February/001012.html -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MAAS SRU
On Tue, Jan 29, 2013 at 07:40:03PM -0500, Andres Rodriguez wrote: [SUBJECT] Request an exception to SRU MAAS to both Precise (and its required dependencies) and Quantal. (Added for discussion to the agenda) Thanks. [PROBLEM] MAAS in Precise is obsolete and prevents users from having a full experience of what MAAS is and brings to the deployment of bare metal with Juju. When MAAS was first developed, as the successor of Orchestra, it heavily depended on Cobbler to perform the operations it was designed for. The first release of MAAS (released in Precise) depended on it (Cobbler) as the 'maas-provision' package. However, due to several concerns about the maintainship of Cobbler by upstream, as well as some security issues it was decided that MAAS should drop the usage of Cobbler eventually. Indeed - I've understood this as the plan of record for some time. When we first filed the MIR for MAAS in Precise, the MIR team review pointed out various issues. After addressing all but three, we were granted conditional MIR acceptance. The issues remaining were: - Remove Cobbler copy (maas-provision) [1] - Remove raphael from MAAS source (and use package) [2] - Remove yui3 from MAAS source (and use package) [2] These issues were resolved, and released in Quantal. Quantal MAAS no longer depends on Cobbler (maas-provision), and it now utilizes the JS libraries from packages in the archive, rather than shipping them along with MAAS source. Because the new MAAS release dropped the usage of Cobbler and introduced new features to replace the latter, it was decided not to SRU MAAS from Quantal to Precise until MAAS matured, and several of the possible (and actual) issues were resolved. Throughout the Quantal cycle, the MAAS team and the Ubuntu Server Team worked together to resolve various issues and make sure that the user experience is great. I agree with Steve's position on this. In order for us to ensure that MAAS provides a great user experience, and a critical bug free software, it is important that we SRU MAAS [3] to both Quantal and Precise. The SRU involves: With Steve's amendments, I'm happy with this. I'd still welcome comments from others on the board. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: launchpad-buildd-admins
On Wed, Jan 16, 2013 at 01:06:35PM -0800, Kees Cook wrote: On Mon, Jan 14, 2013 at 06:35:58PM +, Laura Czajkowski wrote: I am requesting I be added to the launchpad-buildd-admins team please. I fee it is necessary so I am able to deal with ppa build priorities when we get the requests from users ( canonical employees mostly). Launchpad has been reduced to two members of maintenance and are in the AU time zone. It would be be beneficial to my role to be able to deal with requests when they come in rather than waiting till they come online or poking webops so I can deal with requests in a timely fashion. This seems fine to me. Can other buildd-admins speak up in support too? This is fine by me too. In the absence of any other objections, I've gone ahead and added Laura to launchpad-buildd-admins. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MRE for SSSD
On Mon, Jan 07, 2013 at 04:48:15PM +0200, Timo Aaltonen wrote: On 07.01.2013 16:19, Colin Watson wrote: I probably don't have much in the way of objection. However, the only SRU for sssd that's ever made it as far as -proposed was for bug 585885, which failed the SRU process due to a lack of testers. Do you have plans for marshalling efforts to verify SRUs under an MRE such as this? Well, I do get asked about the new versions every now and then, so expect the folks requesting these to test them. So yes, after a new bugfix release has been released and pushed to the team PPA, it would get pushed as an official update if no issues have been found and tested again by those who need it. Things have changed a bit since the old, rejected SRU bug :) OK, this seems fine then. I've edited the MRE page to record that this is an approved standing MRE. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Meeting time
On Tue, Nov 13, 2012 at 09:19:52AM +0100, Martin Pitt wrote: As this keeps causing confusion, and there is very little rationale for binding our meeting time to UTC (given that we are all on the Northern hemisphere), can we agree to always have the meeting at 21:00 London time? I have no problem with sticking to 21:00 London time. If nothing else it might render Google Calendar that little bit less confused. The worst case is that we have a week or two of confusion per year when North America and Europe change DST at different times. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
I just got the calendar notification for tonight's meeting; I'm afraid I'll be travelling and won't be able to make it. Sorry. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Added Kubuntu folks to ~uds-organizers
Hi TB, At Scott's request, I've added Jonathan and Scott (CCed) to ~uds-organizers in order that they can manage Kubuntu blueprints at UDS without having to sink time into proxying through somebody else. This seemed like a reasonable thing to ask for forgiveness rather than permission on, but let me know if you object. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Minutes from the Technical Board meeting, 2012-09-17
On Tue, Sep 18, 2012 at 11:44:22AM +0100, Colin Watson wrote:
* Transferring the kernel package set
* https://lists.ubuntu.com/archives/technical-board/2012-August/001363.html
* Launchpad API limitations mean that we cannot currently change the
owner of the current kernel package set, but there is a branch in
progress to fix this. Once that branch is deployed, we will change
the owner to developer-membership-board.
Now that Stefano's branch has landed, I've changed the owner of
kernel/{hardy..quantal} to developer-membership-board.
Cheers,
--
Colin Watson [cjwat...@ubuntu.com]
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: nvidia/fglrx expedited SRUs
On Mon, Sep 03, 2012 at 05:24:40PM -0700, Bryce Harrington wrote: 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. I guess I fall somewhere between Martin and ScottK on this. Regressions are supposed to prevent releasing an update, and it would be bad to release something when we had a warning that it made some systems worse; but we should also have some kind of get-out in case the regression can't be substantiated, because sometimes testers are just genuinely confused. I'm not fully comforted by the fact that it's opt-in, because the -updates package is only opt-in *once* and thereafter you get all updates to it. Perhaps there is some way we can break this deadlock? I can think of a few possibilities for discussion: * Make sure that testers know that they need to engage with the process and not just fire off an it's busted message without follow-up. We could establish something whereby, if somebody tells us about a regression with a low level of detail, we'll still do due diligence to try to make sure that this isn't something we missed and we'll ask them for more detail about it, but we won't consider it a hard blocker. * Issue more widespread calls for testing that we normally would in the event of a reported but unsubstantiated regression. (Do our QA labs get involved in testing updates of non-free drivers?) * As you suggest, change ubuntu-release-upgrader (or update-manager for upgrades to = precise) to drop nvidia-current-updates etc. on release upgrade in favour of nvidia-current etc. * Think of some way in which we can make the package management system consider nvidia-current-updates etc. as opt-in on every upgrade. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: nvidia-experimental package with expedited SRU process?
On Mon, Sep 10, 2012 at 03:14:49PM -0700, Kees Cook wrote: On Fri, Aug 31, 2012 at 10:49:36AM -0700, Bryce Harrington wrote: I think -updates should continue focusing on providing stable, _released_ drivers. For the beta drivers, we could add a third package, nvidia-experimental, which would be used when needed by specific games. -experimental would be marketed as bleeding edge / unstable but would be provisioned in much the same way as -updates. We would like to commit to an objective of a 3-day turn around from when the driver becomes available to when it is officially available for users to install. Would the tech board be open to allowing this specific package to follow an expedited SRU process? How I'm thinking it'd work in practice is, we would package and upload the driver to -proposed and file a minimal SRU bug report (basically just the Impact section; we're unlikely to know details). We'd then have the game vendor verify the driver from -proposed works with their game. The SRU admin would then be able to wave it through at that point. +1, I think this sounds good. I think the benefits outweigh the risk. The risk I see is in wondering what percentage of the install base will end up on it as a result of a game install. If it's large, we run a larger risk of breaking someone in the face of a update regression. I share this concern. The problem with introducing this kind of bleeding-edge, but important things may need it package is that over time enough important things need it that you find that it's become critical-must-not-break without you noticing, and then you end up back at the start of the cycle. Bryce, you mention used when needed by specific games above. I'm not really familiar with the details here and I'd like to ensure I know exactly what you mean. Is this something that's per-X-session, so we're talking about using it when any of a set of specific games are installed, or per-application, so you could run multiple games in the same session with different drivers? Even in the latter case, I can imagine an uncomfortable situation where we do an -experimental update for Important Game Vendor A and find that it breaks Important Game Vendor B's best-selling title from last month. Would we need to arrange testing with all sufficiently important vendors before releasing updates? (But then we have the problem where we can't release a fix for Important Game Vendor A because Important Game Vendor B hasn't responded, and the incentives here may well be perverse ...) -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Renewal of Ubuntu Kernel Uploaders, please?
On Sun, Sep 09, 2012 at 10:02:50AM +0200, Stefano Rivera wrote: Tech board: This message was sent from Launchpad by Steve Conklin (https://launchpad.net/~sconklin) using the Contact this team's admins link on the Ubuntu Developer Membership Board team page (https://launchpad.net/~developer-membership-board). Can you set our mailing list as our team e-mail address on LP, please? Done. An admin of that list will need to fish the confirmation message out of the moderation queue and use the token therein. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Killing unused packagesets
On Thu, Aug 30, 2012 at 10:15:10AM +0200, Martin Pitt wrote: Micah Gersten [2012-08-27 15:57 -0500]: for a list. I think that the following could go - unr - netbook - mobile I believe that all three of these aren't managed packagesets at all, but are packagesets generated from seeds. Quite likely. However, these were dropped from the seeds long ago, so if we delete them now they should not come back. Colin, would that be ok? Correct. Dropping these should be fine. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: uds-organizers membership
On Tue, Mar 06, 2012 at 09:57:07AM -0500, Michael Hall wrote: Please add steve-edwards (https://launchpad.net/~steve-edwards) to ~uds-organizers team on Launchpad. Done. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
I'm afraid I don't think I'll be able to make tonight's meeting; we're in last-minute baby preparation mode and I have some things to do that I really need the evening time for! I'll try to catch up with logs afterwards. Sorry, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Ubuntu Business Remix update
On Wed, Feb 01, 2012 at 09:02:26PM +, Mark Shuttleworth wrote:
On 31/01/12 09:55, Alan Bell wrote:
* Stuff gets added post-release with no pre-release testing, nowhere
to report bugs and contribute fixes on Launchpad etc. etc.)
Good point, I thought bug reporting should be normal, and if it isn't,
let's fix that.
I thought it was already, e.g.:
https://bugs.launchpad.net/ubuntu/+source/skype/+bugs
(Earlier in the thread, somebody referred to a bug about the namespacing
of this, which of course is tied into this thread. That bug also has a
two-year-old comment saying that partner was due to move into a PPA or
PPAs; if that happened, the positioning in the bug system would
presumably change somehow although I have no idea how.)
I don't know to what extent bug mail goes anywhere useful, gets acted
on, etc. However, ~canonical-partner-dev is subscribed:
ubuntu = lp.distributions[ubuntu]
skype = ubuntu.getSourcePackage(name=skype)
[s.subscriber.name for s in skype.getSubscriptions()]
[u'canonical-partner-dev', u'costamagnagianfranco']
It looks like ~canonical-partner-dev is subscribed to the majority of
packages in partner, although not quite all. Posting the full list here
wouldn't be terribly interesting, but something like this doesn't take
too long to run:
for series_name in ('hardy', 'lucid', 'maverick', 'natty',
... 'oneiric', 'precise'):
... print series_name
... series = ubuntu.getSeries(name_or_version=series_name)
... pubs = partner.getPublishedSources(
... distro_series=series, status=Published)
... source_names = sorted([pub.source_package_name for pub in pubs])
... for source_name in source_names:
... source = ubuntu.getSourcePackage(name=source_name)
... subs = source.getSubscriptions()
... print %s: %s % (
... source_name, .join([s.subscriber.name for s in subs]))
--
Colin Watson [cjwat...@ubuntu.com]
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Ubuntu Business Remix update
is not entirely free software (or similar wording) and that redistribution might involve special effort. (It isn't even terribly clear to me from the current guidelines that this would be prohibited, but obviously reasonable people currently disagree; and I do think it's important to require redistribution terms to be made crystal clear when they differ from those of the standard editions of Ubuntu, both for all the usual reasons and to avoid confusing the public into believing that restrictive terms might apply to Ubuntu as well.) Similarly, I don't see why remixes couldn't include packages from extras more or less at will. Extras didn't exist when the remix guidelines were formulated, but it has a clear technical policy attached to it, and it's already presented to Ubuntu users; by the same argument as above, it seems a perfectly reasonable thing for remixes to include packages from that extension repository. The guidelines already say straight out that remixes are not in fact Ubuntu as distributed by the Ubuntu project, so there's no issue of something that is Ubuntu including something that isn't, or any weird semantics like that. I think an approach like this could resolve the situation for this particular remix without having to go down a particular line of argument that obviously makes some Ubuntu contributors feel uncomfortable. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Mesa floting point patent enquiry - continued
On Tue, Jan 24, 2012 at 11:33:16AM +1100, Christopher James Halse Rogers wrote: Sorry for not following up on this sooner. I'd like to resolve this now that Mesa 8.0 is close to landing in Precise. The last status is ambiguous to me: Colin Watson's response[1] suggests against enabling the extensions, while Mark Shuttleworth's response[2] is for enabling them, and there doesn't appear to be a resolution of the two. I'm still unconvinced personally, but I'll defer to Mark. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Unable to make the meeting today
On Thu, Nov 17, 2011 at 11:51:38AM +0100, Soren Hansen wrote: As I mentioned a while ago, the current meeting time does not work for me, so I'm going to have to pass on our meeting today. I hope we'll decide on a better meeting time today. Sorry, I should have processed the Doodle poll before now. We clearly ought to stick to the advertised time for today's meeting at this point. For next time, there was only one slot that everyone said they could make: Mon 21:00 (cjwatson+pitti ifneedbe) The next most popular slots (which I appreciate I skewed a bit by only making choices available for 07:00-00:00), with only one person saying they were unavailable, were: Wed 21:00 (cjwatson no, pitti ifneedbe) Mon 20:00 (pitti no, cjwatson+kees ifneedbe) Mon 22:00 (pitti no, cjwatson+stgraber ifneedbe) Tue 18:00 (soren no, cjwatson+pitti ifneedbe) Tue 19:00 (soren no, cjwatson+pitti ifneedbe) Thu 18:00 (soren no, cjwatson+pitti ifneedbe) I therefore propose that we enact Mon 21:00 as our regular meeting time until the next DST change. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Patent enquiry - mesa floating point buffer support
On Fri, Jul 08, 2011 at 05:28:18PM +1000, Christopher James Halse Rogers wrote: I'd like to enable mesa's floating point buffer support in the Ubuntu packages (accomplished with the --enable-texture-float configure option). This allows mesa to provide additional functionality in the form of the GL_ARB_texture_float¹ and ARB_color_buffer_float² GL extensions. These are obviously not widely used in Ubuntu currently. As far as I'm aware, the most common user would be Wine, as DirectX provides equivalent functionality. The patent in question is linked to from the GL extension specifications, or can be found at ³. It's not clear to me whether or not enabling this code would actually infringe, as it seems that a hardware rasterisation circuit is integral to the claims. Mesa upstream has been cautious with implementing this support due to this patent, however. [1]: http://www.opengl.org/registry/specs/ARB/texture_float.txt [2]: http://www.opengl.org/registry/specs/ARB/color_buffer_float.txt [3]: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmr=1f=Gl=50s1=6,650,327.PN.OS=PN/6,650,327RS=PN/6,650,327 Hmm. I can confirm that we have received no other communication about this (but we wouldn't expect to have done, since it isn't currently enabled in Ubuntu). It is true that many claims of this patent are specific to hardware circuits. However, claims 9 to 24 do not specify the presence of any particular circuitry, and my reading of them is that they would cover software implementations. I am not sufficiently fluent in the language of OpenGL specifications to be able to tell whether those claims cover the two extensions in question, but they seem quite extensive. Unfortunately, in jurisdictions permitting software patents, I don't think that we can rely on the defence that these claims only cover hardware, unless you or a relevant expert can confirm that Mesa is only affected by the hardware-specific claims. The language in the IP Status sections of the OpenGL specifications is quite aggressive and explicit: SGI will not grant the ARB royalty-free use of this IP for use in OpenGL, but will discuss licensing on RAND terms, on an individual basis with companies wishing to use this IP in the context of conformant OpenGL implementations. SGI does not plan to make any special exemption for open source implementations. It would be interesting to know whether this patent is being actively enforced. However, given that it's referenced from the specifications, and given Mesa upstream's reticence, we might have a hard time arguing that we were unaware of it. What practical functionality do we lose out on by not having these GL extensions? I am neither a lawyer nor an OpenGL expert. Regards, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Help requested for Ubuntu Brainstorm response on new default sound pack
Once you've read the details below, please respond with an acknowledgement and let me know if you can participate. The expected time investment is on the order of a couple of hours over the next two weeks. Last November, the Technical Board recently began a new program to respond to top voted topics on Ubuntu Brainstorm: http://mdzlog.alcor.net/2010/11/03/weathering-the-ubuntu-brainstorm/ with the first two rounds of responses summarised here: http://mdzlog.alcor.net/2010/12/10/ubuntu-brainstorm-top-10-for-december-2010/ http://www.piware.de/2011/04/top-ideas-on-ubuntu-brainstorm-march-2011/ 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 a request for a new default sound pack: http://brainstorm.ubuntu.com/idea/27481/ We turn event sounds off by default for good reason, but I expect some people turn these on; so, while it may not be appropriate to apply the same level of effort to this as to artwork, there may be some untapped talent out there that could be harnessed. Since this has a significant community element and knowing your interest in music, 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 the 27th of September. 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! -- Colin Watson[cjwat...@canonical.com] pp. Ubuntu Technical Board -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Help requested for Ubuntu Brainstorm response on separate music and video player options
Once you've read the details below, please respond with an acknowledgement and let me know if you can participate. The expected time investment is on the order of a couple of hours over the next two weeks. Last November, the Technical Board recently began a new program to respond to top voted topics on Ubuntu Brainstorm: http://mdzlog.alcor.net/2010/11/03/weathering-the-ubuntu-brainstorm/ with the first two rounds of responses summarised here: http://mdzlog.alcor.net/2010/12/10/ubuntu-brainstorm-top-10-for-december-2010/ http://www.piware.de/2011/04/top-ideas-on-ubuntu-brainstorm-march-2011/ 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 a request for separate music and video player options: http://brainstorm.ubuntu.com/idea/27730/ To me, this appears to be fixed in Oneiric (System Settings - System Info - Default Applications has both Music and Video settings), but I suggest reviewing the comments to see if I'm missing something. 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 the 27th of September. 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! -- Colin Watson [cjwat...@ubuntu.com] pp. Ubuntu Technical Board -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [nore...@launchpad.net: Your membership in techboard is about to expire]
On Fri, Aug 26, 2011 at 12:36:13PM +0100, Mark Shuttleworth wrote: Colin and others gave me a heads-up on upcoming expirations of tech board positions. Time has flown by! I think (Daniel will correct me) that the right way is to call for nominations or applications. I agree. Should we implement a slight extension of expiring members' terms to account for us failing to notice this in time? I suggest perhaps one month, which would give us space for two weeks of nominations and two weeks of voting. Please let Daniel and I know if you are affected and your interest in continuing and standing in a confirmation vote. I'd be interested in standing in such a vote. My preference would be to have a few more candidates than seats, and have a condorset vote to determine the final list, but we can also nominate individuals for votes-of-confidence by the developer community. Agreed. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Brainstorm review preparation
Belatedly, here's my hit list for this quarter's brainstorm review. Please look it over and let me know if you have suggestions. Once it's stable (or if I don't get any feedback) I'll proceed with approaching the suggested representatives and ask around for suggestions where I'm unsure. 1. Unity Dash - Contact Lens http://brainstorm.ubuntu.com/idea/27584/ Suggested response type: Blueprint Suggested representative: Neil Patel 2. Brand new default sound pack http://brainstorm.ubuntu.com/idea/27481/ Suggested response type: Look into community participation programme? Suggested representative: Jono Bacon 3. Option for setting separate music and video player http://brainstorm.ubuntu.com/idea/27730/ Suggested response type: This appears to be fixed in Oneiric (System Settings - System Info - Default Applications has both Music and Video settings). Review comments and, if appropriate, describe the change and close the item. Suggested representative: Sebastien Bacher 4. Superuser windows should differ from user windows http://brainstorm.ubuntu.com/idea/27378/ Suggested response type: Blueprint Suggested representative: Otto Greenslade 5. Place for new users to see Ubuntu version http://brainstorm.ubuntu.com/idea/27460/ Suggested response type: Usability analysis Suggested representative: John Lea 6. Volume adjustments for headphone use http://brainstorm.ubuntu.com/idea/27275/ Suggested response type: Decide on the correct behaviour and what to do next Suggested representative: Luke Yelavich 7. Make it easier to find appropriate software to handle a file http://brainstorm.ubuntu.com/idea/28148/ Suggested response type: I believe this is on the roadmap (https://wiki.ubuntu.com/SoftwareCenter#Launching_via_file_of_unknown_type); refer to this and suggest how people might go about making this happen Suggested representative: Michael Vogt 8. Merge Jockey into Software Center http://brainstorm.ubuntu.com/idea/28205/ Suggested response type: Discuss how this might fit into the roadmap; blueprint? Suggested representative: Matthew Paul Thomas 9. Pop-up alert on low battery http://brainstorm.ubuntu.com/idea/28037/ Suggested response type: Find out if this is still applicable; if so, decide what to do next Suggested representative: Martin Pitt 10. Disk space remaining indicator in Unity launcher http://brainstorm.ubuntu.com/idea/28045/ Suggested response type: Ensure bug filed; mentoring opportunity? Suggested representative: Tim Penhey -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies for this evening
I'm afraid I won't be able to make this evening's meeting; my sister-in-law and her children are visiting. I've started off my belated brainstorm review (as seen in another mail) and will wait a week or so for feedback before starting to send out mails to representatives. Regarding my AOB item from last meeting, this is now settled: http://lists.debian.org/debian-devel-announce/2011/08/msg4.html -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Please add c2esp, ptouch-driver, and rastertosag-gdi to my upload rights into main
On Mon, Aug 15, 2011 at 11:23:49AM +0200, Till Kamppeter wrote: I have introduced three new printing-related package into main. They are all printer drivers: c2esp, ptouch-driver, and rastertosag-gdi Can you add these packages to the list of packages where I have upload rights on? Thanks. Done. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Please action bzr package set creation
On Thu, Jul 07, 2011 at 09:59:10PM +0100, Iain Lane wrote: We approved long ago[0] the creation of a bzr package set, but apparently nobody ever asked you for its creation. Sorry for the delay in processing this request, too. Please create a set 'bzr' (owned by ~developer-membership-board) with the following packages initially populating it: bzr bzr-svn bzr-git bzr-grep bzr-hg bzr-gtk qbzr bzr-cvsimport bzr-dbus bzr-email bzr-explorer bzr-fastimport bzr-loom bzr-pqm bzr-rewrite bzr-search bzr-stats bzr-upload bzr-xmloutput bzrtools trac-bzr wikkid Please grant upload access to the members of ~ubuntu-bzr-dev which I just created for this purpose. Please remove from ~jelmer and ~mbp any PPU permissions for these packages, and add them to the team. Done. Please check that I got everything right. p.s. shouldn't the DMB be given the LP permissions required to manipulate package sets and PPU privileges? Shall I file a Launchpad bug about this? I did so a while back: https://bugs.launchpad.net/launchpad/+bug/562451 -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies yet again
Once again I need to send apologies for today's TB meeting; apologies for my repeated absences here. This evening I'm acting as a teller (http://en.wikipedia.org/wiki/Teller_%28elections%29) at our local elections, and I committed to a time in my evening before realising that it clashed with the TB meeting. Sorry, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Please add pyppd to my upload rights into main
On Sat, Dec 18, 2010 at 07:01:15PM +0100, Martin Pitt wrote: Till Kamppeter [2010-12-18 14:07 +0100]: I have introduced the new printing-related package pyppd into main. pyppd compresses PPD files to save disk space. See http://pypi.python.org/pypi/pyppd Can you add this package to the list of packages where I have upload rights on? Thanks. Done. Martin, I happened to notice that you gave Till permission to upload 'pyppa' by mistake - I've corrected this to 'pyppd'. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: ARB legality checks
On Tue, Nov 16, 2010 at 07:02:58AM -0800, Allison Randal wrote: This is one of the topics we discussed at UDS, with the conclusion that while we may not be quite as strict as Debian, we will follow most of their guidelines, as a well-tested procedure for ensuring that the software is legally distributable. Ah, thank you. Do you have a reference to a gobby document or something like that? We're setting up a Security Checklist wiki page now, and may need a similar Legal Checklist, so it's completely transparent what we're accepting and rejecting. (We might be able to refer to the PackagingGuide's Copyright content instead, will re-review with an eye to how straightforward it is to apply it to our process.) Normally I'm a fan of incorporating things by reference, but I think it would be a little confusing in this case - you'd have to say this document, except for X, Y, and Z. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
