19:58 <mdz> #startmeeting
19:58 <meetingology> Meeting started Mon Jul  8 19:58:35 2013 UTC.  The chair is mdz. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
19:58 <meetingology> 
19:58 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
19:59 <soren> o/
20:00 * stgraber waves
20:01 <mdz> #topic action review
20:01 <mdz> I don't see any actions recorded from the previous meeting. correct?
20:01 <mdz> #topic Discussion and vote on the development series alias name
20:02 <mdz> following up from the previous meeting
20:02 <mdz> current proposals are "rolling" (preferred by Rick) and "next' (preferred by the TB)
20:02 <stgraber> I don't think we gave any direct action indeed, though there's a sort of action for cjwatson to implement the LP code for the series alias
20:02 <mdz> Rick doesn't seem to be around
20:02 <mdz> IIRC the reason we deferred was to get his input
20:02 <cjwatson> I mailed him earlier today, but he's just back from holiday and may be snowed under still
20:02 <cjwatson> I don't think there's a point in revisiting without him, since the point was indeed to reconcile
20:03 <mdz> ok
20:03 <cjwatson> perhaps we should try mail
20:03 <cjwatson> in any case:
20:03 <stgraber> I also directly Cced him on the minutes but I haven't heard anything back from him either
20:03 <mdz> I recommend that if the topic comes around again in 2 weeks and he's not here, we proceed anyway
20:03 <cjwatson> there's an implementation issue wgrant raised when I started trying to get database changes made in support of this, with respect to PPAs
20:03 <cjwatson> I need to hash that out with him
20:03 <cjwatson> however William is now himself off on holiday
20:03 <cjwatson> so this is blocked for a while in any event
20:04 <cjwatson> I have the rest of the code written, so will be pretty close once that's sorted
20:04 <mdz> ok
20:04 <mdz> even if it's not blocking, it's not good to keep this open for too long
20:04 <mdz> so I'd like to wrap it next time regardless
20:04 <mdz> fair?
20:05 <cjwatson> agreed
20:06 <mdz> #topic Discussion and vote on OpenSSL as a system library
20:06 <stgraber> fine with me, I'll be at a sprint in London for our next meeting, but should still be able to attend
20:06 <mdz> thread: https://lists.ubuntu.com/archives/technical-board/2013-June/001653.html
20:06 <mdz> previous thread: https://lists.ubuntu.com/archives/technical-board/2013-May/001602.html
20:06 <cjwatson> so, I haven't had a chance to reply properly to kees on this, but I finally managed to articulate my objection to his line of argument just now when preparing for this meeting
20:08 <cjwatson> it is this: his line of argument could be used to justify constructing derived works that combine the GPL with any other free-but-GPL-incompatible licence, as long as it's far enough embedded into our system
20:08 <cjwatson> and I just can't reconcile that with my understanding of the spirit of the GPL, as presented by the FSF
20:09 <mdz> I think in many cases there's a divergence between the intent of the FSF and the intent of the copyright holder
20:09 <mdz> and it seems fair to favor the latter
20:09 <cjwatson> sure, and I'm happy to accept an explicit statement from the licensor, as I've mentioned before
20:09 <cjwatson> however, we are talking here about the fallback case where there isn't an explicit statement
20:10 <mdz> we're talking about GPLv2, yes?
20:10 <cjwatson> v2 in one case, v3 in the other.  I forget which was which.
20:10 <cjwatson> if mongodb/squid/whatever issue an explicit statement clarifying the intent of their licence, and that covers the GPLed code involved, I'm more than happy to honour that
20:10 <cjwatson> that much I think is not in dispute
20:11 <mdz> agreed
20:11 <mdz> so there seems to be no practical problem on the table (anymore)?
20:11 <cjwatson> but, for the rest, an interpretation where it can be freely linked with openssl is not within *my* understanding of the spirit of the GPL, so I couldn't vote for allowing that
20:12 <cjwatson> well, except that neither has actually got round to issuing such a statement AFAIK
20:12 <mdz> ScottK requested a statement on this regardless of any specific case
20:12 <soren> mdz: I understand there's a decent chance the copyright holder didn't intend to prevent us from linking their code with openssl. However, if our reading of the license says that it's not permitted, I think we're in very dangerous territory by wholesale assuming that the copyright holder didn't mean to have that particular bit of their license to us apply.
20:12 <cjwatson> my understanding was that mongodb said they were planning to but hadn't yet, and some squid developers had been making vague noises, but nothing determinative
20:12 <mdz> soren, agreed
20:13 <cjwatson> I respect the alternate readings that Dave and Kees and others have put forward; I just don't agree with them :)
20:13 * kees is here, sorry I'm late
20:14 <cjwatson> http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv2-incompatible_licenses explicitly lists the FSF's opinion that the OpenSSL licence is incompatible with the GPLv2
20:14 <cjwatson> so I have an extremely hard time saying that we could assume the contrary in the absence of an explicit statement
20:15 <mdz> I'm inclined to agree
20:15 <kees> hm, given openssl is explicitly called out there, then yeah.
20:15 <cjwatson> similarly on http://www.gnu.org/licenses/license-list.html
20:15 * soren too
20:15 <mdz> but I'm willing to be pragmatic with the statement from the copyright holders
20:15 <cjwatson> sorry, http://www.gnu.org/licenses/license-list.html#OpenSSL
20:15 <cjwatson> mdz: right, me too, absolutely
20:15 <mdz> e.g. an email is fine, I don't see it as necessary to have them change all of the copyright notices
20:15 <soren> I wish it weren't so, as it obviously is a pain in the "#¤%, but that's just how it is.
20:15 <kees> my rationale was mostly from the perspective of "since this is vague"... but that would make it NOT vague. :P
20:15 <kees> although, I still wonder one thing...
20:16 <cjwatson> soren: Yep, I entirely agree that this position is inconvenient - I just don't think we get to read licences for our convenience
20:16 <kees> there's no question it is incompat... but can it be dynamically linked?
20:16 <soren> cjwatson: Precisely.
20:16 <kees> i.e. clearly can't _include_ openssl in a piece of software. but link?
20:16 <mdz> kees, that comes down to the interpretation of a derived work
20:16 <cjwatson> kees: The FSF's position on that is clear elsewhere; dynamically linking forms a derivative work of the two
20:16 <cjwatson> Again, I would be happy to accept the overriding opinion of a licensor (copyright holder)
20:17 <cjwatson> But it makes sense to me that if you've written software such that it requires dynamically linking against OpenSSL to actually work, then it's a derived work ...
20:17 <kees> how can linking be derived? the point of shared objects was to create API boundries.
20:17 <soren> Naturally. The license is the copyright holder's terms for other people's use of their software. Their interpretation will always take precedence.
20:18 <kees> derived is "and then I added a new encryption scheme to openssl" not "and then I opened an https connection"
20:18 <cjwatson> https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
20:18 <soren> kees: When you consume libraries, your work builds on top of their functionality.
20:18 <cjwatson> I *think* this has been tested in court although [citation needed]
20:18 <kees> so "combined work" != "derived work"
20:18 <soren> kees: That constitutes "derived work" in my book.
20:19 <kees> so, "use LGPL" is the other answer, I guess.
20:19 <mdz> there is room for interpretation there, and maybe even different rulings in different jurisdictions
20:19 <kees> but what about the exceptions to this that were made for non-free libc?
20:19 <cjwatson> That was because you couldn't run anything on those platforms at all without using the non-free libc
20:20 <cjwatson> That being the point of the system library exception
20:20 <mdz> yes
20:20 <cjwatson> But there are alternatives to using OpenSSL ...
20:20 <mdz> FSVO "alternative" :-)
20:20 <kees> heh, so if we kick gnutls out of the archive, we can link against openssl? :P
20:20 <cjwatson> I've never been convinced by trying to expand the scope of the system library exception, partly because it doesn't seem to fit the historical context of that exception
20:21 <cjwatson> Also
20:21 <kees> I would argue that the context still holds: when all examples of using crypto references openssl, when is the defacto standard, that kind of makes it a system library, imo
20:21 <cjwatson> In the case of the system library exception, you're using interfaces that have both free and non-free implementations - nothing about your program is inherently derived from the non-free thing
20:22 <cjwatson> But in the case of the OpenSSL APIs (as opposed to the crypto standards they implement), those are very definitely proprietary (in the sense of ownership) to OpenSSL
20:22 <kees> I think that stands for openssl too -- there is no other interface to swap into place.
20:22 <cjwatson> So the C library and OpenSSL are not comparable here
20:23 <cjwatson> If the GnuTLS stub for the OpenSSL APIs ever reached reasonable completion, then you could swap them freely and I think that changes the argument, not to mention the pragmatics
20:23 * soren .oO{ What if all the time spent in different communities in different contexts discussing this particular problem had been put towards perfecting a libssl compatible wrapper for gnutls }
20:23 <kees> I disagree. All the examples and recommended implementations of crypto I've seen for new programmers, school texts, etc, all use openssl interfaces.
20:23 <cjwatson> But we just aren't there
20:23 <cjwatson> And those are therefore derivative of OpenSSL
20:23 <kees> soren: yeah, that would be nice, for sure.
20:24 <cjwatson> The OpenSSL people put substantial creativity into those interfaces - they aren't neutral things
20:25 <kees> I don't see libc being a neutral interface either. If "C Programming in the Unix Environment" shows me how to use "popen", and it's an exception, then I think "Secure Programming" showing how to use OpenSSL is very nearly the same.
20:25 <mdz> kees, I don't think the question is whether it's a de facto standard
20:25 <cjwatson> But popen has lots of implementations, many free
20:25 <kees> then why would there be an exception for the non-free ones?
20:25 <mdz> but whether it's a Major Component or part of a Major Component of Ubuntu
20:25 <cjwatson> If nobody else has managed to produce a sufficient replacement for OpenSSL, that *strengthens* OpenSSL's claim to have its licence respected properly
20:26 <kees> mdz: right, and I view crypto as an OS primitive.
20:26 <cjwatson> I do not
20:26 <cjwatson> It is not a required element
20:26 <mdz> The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a m
20:26 <mdz> ajor essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
20:26 <mdz> (GPLv3)
20:27 <cjwatson> mdz: (the wording is importantly different between v2 and v3; I analysed both in my original mail to the list about this)
20:27 <mdz> yes, just adding some context here
20:28 <kees> right, so that's why we differ in our conclusions. I believe crypto to be a Major Component, with OpenSSL being the defacto standard interface.
20:28 * soren idly wonders how amazingly amputated Ubuntu would be without libssl
20:28 <cjwatson> In GPLv2, the business about "major components" pertains to distributing source, section 3, but does not affect the requirement to distribute the work as a whole under the same licence, section 2
20:28 <kees> soren: I'll let you know right after I sniff all your traffic.
20:28 <mdz> A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. [GPLv3]
20:28 <cjwatson> So IMO even invoking the system library exception does not save you for GPLv2
20:28 <soren> kees: *rimshot*
20:29 <kees> mdz: exactly. I actually think GPLv3 is MORE supportive of it.
20:29 <mdz> kees, yes, I agree there is more wiggle room in v3
20:29 <kees> soren: but that's one of many reasons I think it's a critical piece of the OS.
20:29 <mdz> in that particular definition
20:29 <mdz> but as cjwatson says, that's not the main issue in v2
20:30 <soren> I don't really think it matters whether it's an implementation of an official standard.
20:30 <mdz> that's one of two conditions, only one of which needs to be met
20:30 <soren> If there were some esoteric operating system whose basic API was entirely homegrown, I could write GPL software that runs on there without problems.
20:30 <kees> I absolutely understand where cjwatson is coming from. I just don't come to the same conclusions.
20:31 <mdz> can we defer to someone with the requisite legal expertise here, rather than armchairing it?
20:31 <soren> mdz: But it's fun!
20:31 <cjwatson> mdz: The FSF have published their analysis
20:31 <mdz> we're all clearly capable of putting forth coherent, logical arguments which contradict each other
20:31 <cjwatson> I don't see what we gain from trying to rebut the authors of the licence
20:32 <mdz> cjwatson, what are you referring to? something other than the license itself?
20:32 <kees> cjwatson: though I don't think they have published a statement that openssl is not a major component of ubuntu.
20:33 <cjwatson> kees: OpenSSL would have to be "included in the normal form of packaging a Major Component, but which is not part of that Major Component" to qualify
20:33 <cjwatson> mdz: Things like the license-list above
20:33 <mdz> despite the long, proud Debian tradition of debating license interpretations, I don't see this as part of the tech board's charter
20:34 <cjwatson> Well, I tried to reject it for ubuntu-archive, which is the normal body to interpret such things
20:34 <soren> mdz: Can you think of a more suitable, existing governing body for this?
20:34 <cjwatson> But it's been escalated
20:34 <stgraber> agreed, the FSF clearly lists the OpenSSL license as being incompatible without the extra clause so unless the copyright holder says otherwise (which they can and we should encourage them to when possible), I believe we should respect the license's author's interpretation
20:35 <mdz> so I don't think we'll come to a unanimous agreement here today
20:36 <cjwatson> Can we dispose of part of it?  I had the sense we were (mostly?) agreed that the situation with GPLv2 was clear
20:36 <stgraber> the TB is the normal escalation path from ubuntu-archive, so I have no problem with us making a call here, not sure what we'd gain in postponing it some more or trying to find somebody else to delegate to
20:36 <mdz> cjwatson, good point
20:36 <mdz> kees, can you concede the v2 piece?
20:36 <mdz> stgraber, this is a technical matter, but not within the discipline where we have expertise
20:37 <mdz> (with all due respect for cjwatson's experience with licensing)
20:37 <cjwatson> oh, merely an *experienced* armchair lawyer :P
20:37 <mdz> we are fundamentally reliant on third party analysis to make a reasonable call here
20:37 <cjwatson> no need for due-respect qualifiers :)
20:38 <mdz> whereas for technical matters pertaining to software engineering and suchlike, I would be comfortable with us being a primary source
20:38 <kees> mdz: I don't think I do, since GPLv3 was meant to clarify GPLv2, and GPLv3 (to me) supports OpenSSL being a Major Component.
20:38 <stgraber> mdz: sure, and I believe the various documents that have been linked and the various analysis on our mailing-list and others is sufficient for us to make a reasonable call
20:38 <cjwatson> kees: What about my point that the major component bit of GPLv2 is not sufficient to permit what people are trying to do?
20:38 <kees> stgraber: I don't disagree that trying to release KeesSSL (forked from OpenSSL) would mean it's not GPL compat.
20:39 <cjwatson> kees: It's confined to the source-distribution bit in section 3, while the must-distribute-work-as-a-whole-under-this-licence thing is in section 2 with no mention of the system library exception ...
20:39 <kees> cjwatson: I'm not sure I understood what you meant with it.
20:40 <mdz> kees, he means that there's no such exception which enables the distribution of the software under the terms of the GPL
20:40 <cjwatson> My objection to linking GPLv2 with OpenSSL is that I believe that forms a derived work as a whole, and v2 s. 2 says that the work as a whole must be licensed under the terms of the GPL
20:40 <mdz> there's only an exception to allow those components to be excluded from source code distribution
20:40 <kees> mdz: "the software" being OpenSSL or thing-dyn-linking-to-openssl ?
20:40 <cjwatson> And that the system library bit is an exception for s. 3 not s. 2
20:40 <mdz> kees, the derived work
20:42 <kees> I suck at arm-chair lawyering
20:42 <mdz> ok, so the options seem to be: 1. vote here and now, or 2. defer to an expert opinion
20:42 <mdz> any other options to put on the table?
20:42 <mdz> "keep arguing" is excluded ;-)
20:43 <mdz> it's been a month and no consensus has emerged
20:43 <kees> cjwatson: where in GPLv2 is the linking bit?
20:43 <stgraber> I unfortunately fear that 2. is == "keep arguing" and I agree we've argued enough about this :)
20:44 <mdz> stgraber, how so? I think we could easily agree on a law firm we could trust to give us an informed opinion
20:44 <mdz> but we have another topic on the agenda and only 15 minutes left
20:44 <mdz> I for one have a meeting directly after
20:44 <cjwatson> kees: v2 doesn't specify, it relies on copyright law interpretation to define what's a derived work
20:45 <cjwatson> kees: v3 clarified this to "Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, ..."
20:46 <kees> cjwatson: the faq seems to imply v2 has a system library exception. https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
20:46 <cjwatson> covering source code distribution
20:46 <cjwatson> oh, found another interesting thing
20:46 <cjwatson> http://www.lawseminars.com/materials/08OPSMA/opsma%20m%20fontana%2010-29%20new%20up.pdf
20:46 <cjwatson> from one of the authors of the GPLv3; says 'Debian unsuccessfully sought FSF opinion that OpenSSL was a GPLv3 "System Library"'
20:47 <kees> interesting
20:47 <mdz> #vote +1 means vote here and now, -1 means defer to an expert third party opinion, +0 means do nothing and leave things as they are (i.e. somewhat ambiguous)
20:47 <meetingology> Please vote on: +1 means vote here and now, -1 means defer to an expert third party opinion, +0 means do nothing and leave things as they are (i.e. somewhat ambiguous)
20:47 <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
20:47 <meetingology> +1 means vote here and now, -1 means defer to an expert third party opinion, +0 means do nothing and leave things as they are (i.e. somewhat ambiguous) received from mdz
20:47 <ScottK> FWIW, right now we have at least two archive admins with a different view of what's permissible and if something is accepted into the archive shouldn't depend on who does the review.
20:48 <stgraber> +1
20:48 <meetingology> +1 received from stgraber
20:48 <kees> +1
20:48 <meetingology> +1 received from kees
20:48 <mdz> weird, meetingology seems to have interpreted my vote request as a vote
20:48 <cjwatson> and has the context that the v3 redraft of the system library exception was motivated by making Nexenta legal
20:48 <soren> +1
20:48 <meetingology> +1 received from soren
20:48 <mdz> -1
20:48 <meetingology> -1 received from mdz
20:48 <cjwatson> +1   I feel I have *read* enough expert third party opinions and would rather get it over wish
20:48 <meetingology> +1   I feel I have *read* enough expert third party opinions and would rather get it over wish received from cjwatson
20:48 <cjwatson> *with
20:48 <mdz> #endvote
20:48 <meetingology> Voting ended on: +1 means vote here and now, -1 means defer to an expert third party opinion, +0 means do nothing and leave things as they are (i.e. somewhat ambiguous)
20:48 <meetingology> Votes for:4 Votes against:1 Abstentions:0
20:48 <meetingology> Motion carried
20:48 <mdz> ok, so we vote
20:49 <mdz> so what do we specifically want to decide? whether an exception is required to have GPL (v2 or v3) software link with OpenSSL in Ubuntu?
20:50 <kees> I think that summarizes it, yes.
20:50 <cjwatson> we should vote on our interpretation of v2 and v3 separately IMO
20:50 <kees> agreed
20:50 <mdz> we're all in agreement that it's cool with an exception, and that the exception doesn't need to be shipped with the software, correct?
20:50 <kees> shouldn't the exception be in debian/copyright though?
20:50 <soren> Yes.
20:50 <cjwatson> I'd say the packager ought to put it in debian/copyright, but I'm willing to trust an e-mail, yes
20:50 <cjwatson> (plenty of precedent for that, including at least one of my own packages ;-) )
20:51 <mdz> proposed motion to vote on: An explicit exception is required in order for GPLv2 licensed software to link (statically or dynamically) with OpenSSL in Ubuntu
20:51 <mdz> ?
20:51 <kees> seems like having the exception living somewhere in HEAD is sufficient, in the source better, in debian/copyright best.
20:51 <stgraber> yep, I'm fine with that, it's how we've mostly been doing things and what the license author recommends (not the separate e-mail part, but I'm fine with that if it's in debian/copyright)
20:51 <soren> mdz: Sounds good to me.
20:52 <cjwatson> Is there any dispute about the static case?
20:52 <kees> mdz: yeah, wording on that vote seems good
20:52 <kees> I don't dispute the static case at all
20:52 <cjwatson> We didn't discuss that above
20:52 <mdz> ok, removing that then
20:52 <mdz> #vote An explicit exception is required in order for GPLv2 licensed software to dynamically link with OpenSSL in Ubuntu
20:52 <meetingology> Please vote on: An explicit exception is required in order for GPLv2 licensed software to dynamically link with OpenSSL in Ubuntu
20:52 <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
20:53 <soren> +1
20:53 <meetingology> +1 received from soren
20:53 <stgraber> +1
20:53 <meetingology> +1 received from stgraber
20:53 <mdz> I didn't want the vote to imply that static linking was OK
20:53 <mdz> +1
20:53 <meetingology> +1 received from mdz
20:53 <kees> -1
20:53 <meetingology> -1 received from kees
20:53 <cjwatson> +1
20:53 <meetingology> +1 received from cjwatson
20:53 <mdz> #endvote
20:53 <meetingology> Voting ended on: An explicit exception is required in order for GPLv2 licensed software to dynamically link with OpenSSL in Ubuntu
20:53 <meetingology> Votes for:4 Votes against:1 Abstentions:0
20:53 <meetingology> Motion carried
20:53 <mdz> #vote An explicit exception is required in order for GPLv3 licensed software to dynamically link with OpenSSL in Ubuntu
20:53 <meetingology> Please vote on: An explicit exception is required in order for GPLv3 licensed software to dynamically link with OpenSSL in Ubuntu
20:53 <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
20:53 <mdz> (s/2/3/)
20:54 <kees> -1
20:54 <meetingology> -1 received from kees
20:54 <stgraber> +1
20:54 <meetingology> +1 received from stgraber
20:54 <mdz> +0 I don't think I have studied this one enough
20:54 <meetingology> +0 I don't think I have studied this one enough received from mdz
20:54 <cjwatson> +1 - kees did come close to persuading me to at least abstain, but the presentation from Red Hat's counsel has re-convinced me
20:54 <meetingology> +1 - kees did come close to persuading me to at least abstain, but the presentation from Red Hat's counsel has re-convinced me received from cjwatson
20:54 <soren> +1
20:54 <meetingology> +1 received from soren
20:54 <mdz> #endvote
20:54 <meetingology> Voting ended on: An explicit exception is required in order for GPLv3 licensed software to dynamically link with OpenSSL in Ubuntu
20:54 <meetingology> Votes for:3 Votes against:1 Abstentions:1
20:54 <meetingology> Motion carried
20:54 <mdz> ScottK, satisfactory?
20:54 <ScottK> mdz: Definitely.  I think that's quite clear.
20:54 <mdz> #topic Review our current "provisional" Micro Release Exceptions
20:55 <ScottK> Thanks for taking on this difficult issue.
20:55 <kees> while those slides were very interesting, I still feel that we're a different distro from both RH and debian.
20:55 <mdz> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
20:55 <cjwatson> Thanks; and hope nobody was offended by robust debate :-)
20:55 <mdz> Provisional exceptions:
20:55 <mdz> Nova, Glance, Horizon, Keystone (to unblock SRU on 2012-06-25)
20:55 <mdz> Cinder, Quantum on 2012-12-03
20:55 <mdz> LibreOffice (2012-06-25)
20:55 <mdz> Mesa (2012-07-23 - SPECIAL CASE: piglit test suite is not in-tree, needs to be run on real hardware)
20:55 <mdz> vlc (2012-07-23)
20:55 <mdz> ceph for Ubuntu >= 12.10 and ceph upstream LTS releases 2013-02-25
20:55 <mdz> libdrm for Ubuntu 12.10. Backport of the 13.04 version to match that backported in 12.04 as part of lts-raring enablement.
20:55 <kees> yeah, thanks for this. I never expected to convince everyone, but I'm glad to have had the chance to lay out my thoughts. :)
20:56 <stgraber> so I granted the libdrm one as a one-time thing, I believe mlankhorst did that backport and so we can now remove it from the list
20:56 <cjwatson> The server MREs seem to be going fairly smoothly from what I've seen
20:56 <kees> to review the pMRE list, I'd be curious to see how many times they've been SRUed since the pMRE, and how many regressions were seen.
20:56 <mdz> stgraber, agreed, you can go ahead and remove that if you like
20:57 <mdz> kees, yes, that would be useful
20:57 <mdz> I don't have that information to hand
20:57 <mdz> and suspect it would take some legwork to assemble
20:57 <stgraber> mdz: done
20:57 <kees> bdmurray: do you happen to have any off-the-top-of-your-head thoughts on these pMRE packages's SRU behavior so far?
20:58 <cjwatson> Should be minable easily out of /ubuntu/+source/foo/+publishinghistory
20:58 <cjwatson> There've certainly been "some" of each of the server ones; I don't immediately recall regressions there ...
20:58 <bdmurray> kees: with my work on phasing updates I have a report of possible regressions about packages released to -updates
20:58 <cjwatson> bdmurray++
20:59 <bdmurray> however, since some of the packages are server related and those don't automatically go to errors it may not very helpful
20:59 <bdmurray> here is the report
20:59 <bdmurray> http://people.canonical.com/~brian/tmp/phased-updates.html
21:00 <mdz> we're out of time
21:01 <mdz> I don't recall the reason for reviewing these; presumably just general housecleaning?
21:01 <mdz> seems like we could take the analysis offline and probably resolve these by mail
21:01 <kees> mdz: yes
21:01 <cjwatson> I think so; it ought to be done every so often
21:01 <kees> mdz: agreed, thanks!
21:01 <mdz> so someone could cross-reference bdmurray's analysis with the list of pMREs and send the results to the mailing list
21:01 <cjwatson> mail> agreed
21:01 <mdz> any volunteers?
21:01 <kees> mdz: I will do that
21:01 <mdz> kees, thank you
21:01 <cjwatson> thank you!
21:02 <stgraber> thanks!
21:02 <mdz> #action kees to cross-reference phased-updates.html with pMREs and send analysis to technical-board@
21:02 * meetingology kees to cross-reference phased-updates.html with pMREs and send analysis to technical-board@
21:02 <mdz> #topic next chair
21:02 <mdz> so stgraber and I swapped
21:02 <cjwatson> I guess that means it's probably me?
21:02 <mdz> pitti? soren?
21:02 <cjwatson> 22nd - I'll be at the releng sprint in London
21:03 <cjwatson> not totally sure I'll be around
21:03 <mdz> pitti would be next in nick order
21:03 <mdz> oh, sorry, confused
21:03 <mdz> I was going to be last time, right?
21:03 <mdz> and stgraber filled in
21:03 <stgraber> yep
21:03 <cjwatson> oh, that would still make it pitti then I guess
21:03 <mdz> so I think pitti next, then soren, then cjwatson
21:03 <cjwatson> right
21:03 <mdz> #action pitti to chair next meeting
21:03 * meetingology pitti to chair next meeting
21:03 <cjwatson> if we remember
21:03 <mdz> #topic EOB
21:03 <mdz> anything incredibly urgent?
21:03 <mdz> er AOB
21:04 <cjwatson> sleep
21:04 <mdz> once
21:04 <cjwatson> :-)
21:04 <mdz> twice
21:04 <mdz> thrice
21:04 <mdz> thanks, all
21:04 <mdz> #endmeeting