| highvoltage | good morning | 13:10 |
|---|---|---|
| highvoltage | wendar: so all new apps that are submitted now are assumed to be for precise, right? | 13:10 |
| dholbach | hiya | 13:18 |
| dholbach | I'd appreciate if you all could have a look at https://wiki.ubuntu.com/OptRequirement and tell me what you think :) | 13:18 |
| dholbach | ajmitch, dpm, highvoltage, lfaraone, mhall119, stgraber, wendar: ^ :) | 13:21 |
| mhall119 | dholbach: regarding the FHS, IMHO the fact that *we* are shipping the packages makes them less "third party" | 13:27 |
| highvoltage | dholbach: I've always been a big supporter of the "dev release + backports" idea, I think that's preferred to "Expiring apps". | 13:27 |
| mhall119 | highvoltage: the problem with that is you have to work with the dev release | 13:27 |
| mhall119 | so in order to get a Unity 4 lens into Oneiric, it would have to work on Unity 5 in Precise first, which isn't backwards compatible | 13:28 |
| highvoltage | mhall119: the problem with not doing that is that you to do the work with the dev release when it becomes stable anyway | 13:28 |
| highvoltage | (and the next one, and the next one, and the next one) | 13:28 |
| mhall119 | thats not really so much a "problem" as it is an annoyance | 13:29 |
| highvoltage | mhall119: yes, where compatibility becomes problematic, it would certainly be an exception. I think there's more than one right way to approach it, and using a combination of things might be the best way | 13:29 |
| highvoltage | mhall119: it's a problem when it takes up time that could be better used otherwise. | 13:29 |
| mhall119 | that's up to the app developer to decide how to best spend their time | 13:29 |
| highvoltage | ah ok. Well if we could just blame everything on the app developers then we have absolutely no problems currently. | 13:30 |
| highvoltage | (sorry I'm still waking up... coffee time) | 13:30 |
| mhall119 | I'm not blaming, I saying we shouldn't try and enforce optimal time-management skills on developers | 13:31 |
| * highvoltage isn't saying that either | 13:31 | |
| mhall119 | what we should be doing is reducing the barrier to getting apps in | 13:31 |
| highvoltage | I'm saying that if we can get it into the archives and backport it, then we should. | 13:31 |
| dholbach | mhall119, I mentioned the lens example indirectly | 13:31 |
| mhall119 | and, IMO, targetting a development release in order to deploy to a stable release is an unnecessary barrier | 13:32 |
| highvoltage | mhall119: in some ways it would reduce the barrier, because doing it otherwise just won't scale | 13:32 |
| mhall119 | it would reduce future barriers, yes, but by increasing the initial ones | 13:33 |
| highvoltage | mhall119: re-reviewing hundreds of apps (or even thousands) will be a huge amount of work compared to doing it properly once | 13:33 |
| dholbach | mhall119, I wasn't suggesting that we tell app developers to target the dev release - but it'd be just implemented that way | 13:33 |
| dholbach | mhall119, so the ARB would do a test-build, etc | 13:33 |
| mhall119 | and if it didn't build on the development release? | 13:34 |
| highvoltage | mhall119: ah yes, I guess it's worth mentioning (after reading what dholbach said), that I wouldn't expect app developers to do it themselves | 13:34 |
| dholbach | then that'd be a problem we'd need to solve | 13:34 |
| mhall119 | okay, so I have an app, hello-unity, I want to submit to Precise, how would that work *today* if we had the backports method | 13:35 |
| highvoltage | I guess in that case it's fine if we do it like it works currently, and then in that case an app developer would have to re-submit on the next release | 13:35 |
| highvoltage | mhall119: it sounds logical that for *today*, it would go through the extras ppa like all the current arb apps. | 13:36 |
| dholbach | mhall119, look, I'm trying to solve the problem - I don't want things to be harder - I don't have it all figured out yet, but I'm trying to think of using processes and tools we already have, because I feel there will be less objections because problems on those paths are things we know about already | 13:36 |
| dholbach | mhall119, I would expect the submission process to be the same | 13:36 |
| mhall119 | highvoltage: yes, I'd be all for making app developers re-submit for each release, it's not that much more work for an actively developed app | 13:36 |
| dholbach | upload source package to ppa, state which release you want it in, the rest is taken care of | 13:37 |
| mhall119 | dholbach: I'm not criticizing, I know we're all trying to make things better, just offering real examples to see how the proposed processes would support them | 13:37 |
| * dholbach nods | 13:37 | |
| dholbach | ok | 13:37 |
| mhall119 | these are my "user stories", so to speak | 13:38 |
| dholbach | maybe we need some kind of mixture of the processes to accomodate your use case - like the package would be just uploaded to -backports | 13:39 |
| dholbach | I'll flesh out the dev-release incompatibility bit again | 13:39 |
| dholbach | and state that we want the submission process to be the same | 13:39 |
| dholbach | mhall119, I know you've been bitten by other "simple upload processes" before :) | 13:40 |
| highvoltage | mhall119: I'm not always sure what the goal is for add-on apps in Ubuntu. Apple has half a million *apps* in its app store, (Debian has somewhat over 35 000 packages (not even apps), I'm sure you'd want something that can at least scale *somewhat*, and for that we'd have to cut out repetitive work, even if it's just 5 minutes per package per release. at some point, when it's appropriate to do so, we'll have to encourage, help or insist | 13:40 |
| highvoltage | mhall119: as for the use cases, yes it would be appreciated if you could put some together | 13:40 |
| mhall119 | dholbach: do you want me to put these user stories on the wiki page you linked to? | 13:41 |
| dholbach | yeah, why not | 13:41 |
| dholbach | highvoltage, I hope that at some stage we will just use PPAs where we see if things build and then put work into lint tools to check for all the stuff we know might be broken | 13:42 |
| dholbach | then we could automate lots of the work and spend time on the truly important stuff | 13:43 |
| highvoltage | dholbach: just read through AppArmorEasyprof, sounds nice | 13:43 |
| dholbach | highvoltage, did you find anything missing on the page? or unclear? | 13:43 |
| highvoltage | dholbach: I think it sums things up (regarding the opt requirement) nicely | 13:45 |
| dholbach | ok cool | 13:45 |
| dholbach | highvoltage, is there any different solution you could see? | 13:45 |
| highvoltage | dholbach: well, I'm still a bit concerned about files that may overwrite each other if there won't be dedicated namespaces for apps, but there's probably a solution for that | 13:46 |
| dholbach | highvoltage, it's a general problem we have and we don't do much about it - it's a bit unfair that we let app developers (and the ARB) pay for it :-/ | 13:47 |
| highvoltage | dholbach: perhaps myapps could warn when a file in a package is already installed via another package already (not that I want to pile more work on myapps developers :) ) | 13:47 |
| highvoltage | (and sorry for the general unparsability of that sentence) | 13:48 |
| dholbach | I mean we could at least add some functionality to an arb-lint tool to check against a current Contents.gz | 13:48 |
| highvoltage | ah right, yes | 13:48 |
| dholbach | and we could check the list of installed files for "general purpose names" | 13:48 |
| dholbach | but the ideal solution would be for package management to deal with issues like that | 13:49 |
| dholbach | or some clever confinement technique | 13:49 |
| dholbach | but now I feel we sacrifice the success of apps in Ubuntu because we choose to selectively deal with the problems just in new apps and not in general | 13:50 |
| highvoltage | what do you mean? | 13:51 |
| dholbach | we generally don't do much about file overwrites | 13:51 |
| dholbach | we choose to just enforce such a special rule on apps | 13:51 |
| highvoltage | ah right | 13:51 |
| dholbach | and the apps submitters and arb people suffer because of that :) | 13:52 |
| dholbach | but I tried to keep fiery rhetoric out of the document, I hope I succeeded with that ;-) | 13:52 |
| highvoltage | I'm a bit too scared to talk to them but I'd actually like some opinions from dpkg/apt developers | 13:52 |
| dholbach | mvo largely agrees :) | 13:53 |
| highvoltage | specifically, if there's any plans (or objection) on changing/adding functionality when a file is about to be overwritten | 13:53 |
| dholbach | he suggested moving to backports completely :) | 13:53 |
| highvoltage | like, it could ask "Do you want to divert this file to the newly installed package or use the file from the existing package?" or I don't know, just something better than "NO!!! I REFUSE TO DO ANYTHINIG FURTHER YOU MORON!!!!111cos(0)!!" | 13:54 |
| dholbach | yes, it'd be nice if apt/dpkg/software-center understood what was happening and would tell you "package A and B clash, B is just Prio:extra, shall I remove it or do you want to rollback the upgrade"? | 13:55 |
| dholbach | but I assume that's mountains of work | 13:55 |
| highvoltage | yesh | 13:56 |
| highvoltage | *yeah | 13:56 |
| mhall119 | dholbach: highvoltage: added 4 use cases that concern me | 13:58 |
| dholbach | cool, I'll have a look in a bit | 13:58 |
| mhall119 | please add any that concern you guys (obviously my concerns were all about backports) | 14:01 |
| highvoltage | mhall119: the user stories themselves are good but it seems to try to build an arguement against backports (we acknowledge that backports isn't the answer for everything) | 14:01 |
| mhall119 | highvoltage: it points out the problems that would need to be address if we go with backports | 14:02 |
| highvoltage | mhall119: backports would be /one/ possible solution for packages. so it's not a case of "going with backports or not" | 14:02 |
| mhall119 | right, so whatever we decide to do, we will need to make sure each of these use cases is addressed | 14:03 |
| mhall119 | even if we go with multiple paths to accomplish that | 14:04 |
| highvoltage | sure. | 14:04 |
| highvoltage | mhall119: I recomment you take out the "backports" sub-bullets then and just keep them as use cases | 14:04 |
| highvoltage | (because those arguments against backports are all irrelevant) | 14:04 |
| mhall119 | highvoltage: my idea was that we would have a bullet for each option, pointing out whether it would support the use case or not | 14:05 |
| highvoltage | mhall119: ok. | 14:06 |
| mhall119 | that way, as long as each use case had a "supported" bullet, we know they're all covered | 14:06 |
| ajmitch | dholbach: I'm about +100 on not requiring /opt, and using backports more | 14:50 |
| dholbach | ajmitch, anything the page is missing? | 14:50 |
| ajmitch | in some cases we've been encouraging people to use backports instead | 14:51 |
| * ajmitch has only quickly read it so far | 14:51 | |
| ajmitch | lifeless had a file conflicts checker, fwiw | 14:51 |
| ajmitch | & this is timely, as one of the submissions in the last couple of days is for a nautilus extension | 14:52 |
| ajmitch | opening backports prior to release helps with some of the issues mentioned in the user stories - afaik it was requiring a LP change | 14:53 |
| ajmitch | dholbach: I also know this'd reduce some of the friction around extras.ubuntu.com being considered not part of ubuntu :) | 14:54 |
| dholbach | ajmitch, so as part of opening Q+1 we'll open backports earlier on? | 14:54 |
| dholbach | ajmitch, will we allow uploads to only -backports? | 14:55 |
| ajmitch | dholbach: right, precise-backports was originally going to open at feature freeze, the TB signed off on it | 14:55 |
| dholbach | gotcha | 14:55 |
| ajmitch | https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-backports-bof is light on details but has the general plan | 14:56 |
| dholbach | hum, I'm wondering where in the wiki doc we could plug this | 14:57 |
| ajmitch | maybe the session at UDS about hacking launchpad could be used to help make sure quantal-backports can be opened at feature freeze | 14:58 |
| dholbach | ok, we have another session at UDS called "unblocking developer" which will be all about bottlenecks | 14:59 |
| dholbach | maybe that'd be a good place | 14:59 |
| ajmitch | do you have a blueprint link so I can subscribe? | 14:59 |
| dholbach | I just think we should mention it in OptRequirement somewhere too | 14:59 |
| ajmitch | yeah | 14:59 |
| dholbach | as it will mitigate some of the concerns | 14:59 |
| * ajmitch hasn't liked /opt for a long time | 15:00 | |
| dholbach | can you plug it into the wiki while I look for the blueprint link? ;-) | 15:00 |
| ajmitch | I think the others know my feelings on this :) | 15:00 |
| dholbach | https://blueprints.launchpad.net/ubuntu/+spec/community-q-unblocking-developers | 15:00 |
| ajmitch | http://conflictchecker.ubuntu.com/possible-conflicts/ doesn't look like it's been run for awhile, but I can ask lifeless about it | 15:01 |
| dholbach | nice | 15:01 |
| dholbach | ok team call - brb | 15:02 |
| ajmitch | ok | 15:02 |
| ajmitch | mm, uds update, I suppose I should find a US power adaptor for my laptop :) | 15:31 |
| wendar | dholbach: I wouldn't say we spend the vast majority of our time on the /opt requirement, certainly not 90% | 15:43 |
| wendar | dholbach: we spend the vast majority of our time educating developers, that's true, but only a tiny part of that has anything to do with /opt | 15:43 |
| wendar | dholbach: more of the education is really basic stuff like how to package in the first place | 15:44 |
| wendar | dholbach: or, how to even create a tarball/layout that can be packaged. | 15:44 |
| dholbach | is that for the old packages or the newer ones as well? | 15:45 |
| wendar | dholbach: I'd estimate the cost of /opt at closer to 10% of total effort | 15:45 |
| dholbach | really? | 15:46 |
| dholbach | and with requiring ppa submissions, how much do you think it'd be? | 15:46 |
| wendar | no change with ppa submission, the same work has to be done | 15:47 |
| wendar | on backports, I'm generally in favor | 15:48 |
| wendar | the resistance in the past was more from the backporters | 15:48 |
| wendar | it won't work for everything | 15:48 |
| wendar | like, lenses and scopes | 15:48 |
| wendar | (where the code is completely different on Oneiric and Precise) | 15:48 |
| wendar | and, note that it would still block us at feature freeze | 15:48 |
| wendar | while this cycle we were still launching apps on Oneiric right up to a week before the Precise release | 15:49 |
| wendar | and, would expect that to continue | 15:49 |
| wendar | so, we might need a special exception that says we can backport some apps that aren't in the current development release, but are expected to be in the *next* development release | 15:50 |
| wendar | e.g. last week we might have backported an app to Oneiric that wasn't in Precise, but plan to submit it to the Q dev release | 15:51 |
| wendar | the backporters might consider that a lesser evil than continuing to operate extras.ubuntu.com, hard to tell | 15:51 |
| dholbach | right mhall119 mentioned the lens case as well | 15:52 |
| dholbach | maybe we can have a chat about your time estimation generally | 15:52 |
| wendar | maybe for Q we could do both extras and backports? and do some apps in each? | 15:52 |
| dholbach | I assumed that the opt requirement took the majority of time | 15:52 |
| wendar | basically just add backports as another publishing channel | 15:52 |
| dholbach | I'm happy with that - we should talk to the TB or whoever else could make a decision | 15:52 |
| * dholbach nods | 15:53 | |
| wendar | then dev release + backports would not use /opt | 15:53 |
| wendar | and extras would keep using /opt | 15:53 |
| wendar | and we could compare time to review, time to launch, etc | 15:53 |
| wendar | and review burden on backports team, and on MOTU, reviewing the new apps | 15:54 |
| wendar | We've mostly got the /opt install down to a set of formulas now | 15:54 |
| dholbach | right, that's all relevant | 15:54 |
| * ajmitch thinks that could be good | 15:54 | |
| ajmitch | /opt works if it's a very standard installation, like distutils or automake | 15:55 |
| wendar | Especially for python apps, it's a pretty straightforward set of tweaks | 15:55 |
| dholbach | hum, I'm still a bit surprised that the /opt requirement accounts for so little of your time - I thought it was the major blocker | 15:55 |
| ajmitch | when apps have paths hardcoded, it takes a bit more work | 15:55 |
| wendar | aye, the stranger toolsets are undiscovered country | 15:55 |
| ajmitch | I don't know if it's only 10% as you said, since it generally can involve adding patches | 15:56 |
| wendar | dholbach: nah, most of the time is spent communicating with developers, especially about buggy code | 15:56 |
| ajmitch | like the fun with harmonyseq I need to resolve | 15:56 |
| dholbach | ok, buggy code we will need to discuss in any case - so that can't be optimised away | 15:57 |
| wendar | it'd be nice to chat with new developers, and ask how much time they spend digesting the /opt requirement | 15:57 |
| dholbach | or let's say... easily optimised away | 15:57 |
| wendar | because now that we've pushed the PPA requirement, the effort of /opt is more on the developer | 15:57 |
| ajmitch | still plenty of work in the actal reviewing what the app does | 15:57 |
| * ajmitch doesn't know if the PPA requirement is very clear to people submitting still | 15:58 | |
| wendar | AFAICT, no one gets it right on first submission | 15:58 |
| wendar | but then, it hasn't been well documented until a couple weeks ago | 15:59 |
| wendar | and, that documentation still isn't linked from developer.ubuntu.com | 15:59 |
| wendar | so, they probably never see it | 15:59 |
| ajmitch | I'd rather see the submission form require picking a PPA & a package from that PPA, but that probably takes a bit of work | 16:00 |
| dholbach | ajmitch, yes, that'd be ideal in my mind too | 16:00 |
| wendar | but, at least we can respond to the first submission with links to the docs, that helps | 16:00 |
| ajmitch | yep | 16:00 |
| wendar | and yes, if all apps with "no cost" and "FLOSS license" required a valid PPA link, that would help enormously | 16:01 |
| wendar | (and blocked uploading any files) | 16:01 |
| ajmitch | I think one I looked at today just had a .dsc | 16:01 |
| wendar | I've seen a lot of those | 16:02 |
| wendar | or just .deb | 16:02 |
| ajmitch | just .deb is very common | 16:02 |
| dholbach | so looking ahead, fixing glitches in MyApps, using&improving automatic tools (once we have stuff in PPAs) and the /opt requirement would speed things up | 16:02 |
| dholbach | I'm somehow trying to estimate how big a problem /opt really is | 16:03 |
| dholbach | as I said above, I assumed that it was one of the biggest stumbling blocks | 16:03 |
| dholbach | (and sources of frustration) | 16:03 |
| ajmitch | I can understand why it's there, but it still does feel like a bit of work for anything remotely non-standard | 16:03 |
| wendar | I was concerned ahead of time, but in actual practice pushing apps through, it hasn't been a huge time-suck | 16:04 |
| ajmitch | & it means that I should reject submissions like forgetbox, since I don't think a nautilus extension can live outside /usr | 16:04 |
| wendar | and, the more apps I do, the easier it gets, because I've worked out the tricks, and can reuse them | 16:05 |
| wendar | ajmitch: I'd say a nautilus extension should be main archive and backports anyway | 16:05 |
| wendar | ajmitch: so, that's probably a good thing | 16:05 |
| wendar | dholbach: the current approval/publishing process is very fast | 16:06 |
| wendar | we can stage an app, vote on it, and get it live in the current release in a single day | 16:06 |
| wendar | dholbach: we often take ~3 days to vote, but it could go faster | 16:07 |
| dholbach | sure, I can't see how that could be much more efficient | 16:07 |
| wendar | dholbach: I don't see anyway we could get archive admin approval, publish in dev release, backport approval, and publish in backports in a single day | 16:07 |
| ajmitch | if it's the same person doing backport & archive admin duties, that's not too hard, but I don't know if that's allowed | 16:08 |
| ajmitch | it'd mostly depend on time of day & availability of source/binary NEW reviews | 16:08 |
| dholbach | right, archive admin approval might be the biggest blocker | 16:08 |
| dholbach | for 1 or 2 members of the ARB to join the backports team to do their work might mitigate the concern a bit | 16:09 |
| ajmitch | helpign out backports has been one of those "I'll get around to it soon" things for me :) | 16:09 |
| wendar | yes, I think that would be essential, but I imagine the backporters would want new members to build up some experience before they start launching apps on their own | 16:10 |
| wendar | I think they have their own voting/approval process? | 16:10 |
| dholbach | I'm not sure - usually the requirement to get something backported are quite low | 16:11 |
| dholbach | I could imagine that every additional hand on deck would be appreciated | 16:11 |
| wendar | build, install, run is their mantra | 16:12 |
| ajmitch | because they're working from a known good starting point | 16:12 |
| wendar | yup, it allows for some simplifications | 16:13 |
| wendar | another issue is that backports isn't visible by default | 16:13 |
| wendar | people have to take a manual step to enable it for specific packages | 16:13 |
| mhall119 | wendar: can you give me the link to whatever documentation we should point to from developer.u.c? | 16:14 |
| mhall119 | 12:06 < wendar> but then, it hasn't been well documented until a couple weeks ago | 16:14 |
| mhall119 | 12:06 < wendar> and, that documentation still isn't linked from developer.ubuntu.co | 16:14 |
| wendar | so, it would be nice to have a feature that allows us to set certain packages as always visible in backports (for a specific release) | 16:14 |
| wendar | mhall119: https://wiki.ubuntu.com/AppReviewBoard/Submissions | 16:14 |
| wendar | mhall119: that has a nice overview, and links to all the other detailed help we offer | 16:15 |
| mhall119 | wendar: thanks | 16:15 |
| mhall119 | I'll get that added | 16:15 |
| wendar | dholbach: expiring apps isn't a big deal, as long as the dev release has a higher version number than the backports release | 16:16 |
| wendar | dholbach: does backports do archive copies to new dev releases like the main archives do? | 16:16 |
| dholbach | wendar, I'm not quite sure | 16:17 |
| wendar | dholbach: with extras it's just a natural side-effect of starting each release with an empty archive | 16:17 |
| dholbach | wendar, "expiring apps" was about removing apps from the next release, so they don't get copied over and over again (and we have bitrot in the archive, which was one concern) | 16:17 |
| ajmitch | not currently, because they're always copied from the dev release | 16:17 |
| wendar | dholbach: right, that's why extras doesn't copy | 16:18 |
| ajmitch | so if an app is currently in oneiric-backports, it's because it's available in precise | 16:18 |
| wendar | ajmitch: yes, that's the current backports policy | 16:18 |
| ajmitch | the suggested change for opening it pre-release, I think it was going to be a semi-automated copy into that development release | 16:19 |
| dholbach | wendar, yes, I just mentioned it in the doc that we could emulate something like the "expiring apps" if deemed necessary | 16:19 |
| ajmitch | so a new source package could go into precise-backports, then when quantal opened it would have been copied in (with a different version number) | 16:19 |
| wendar | copied from backports->dev release? | 16:20 |
| wendar | I thought they only allowed the other way | 16:20 |
| wendar | dev release->backports | 16:20 |
| ajmitch | wendar: afaik, yes, because this is a special case | 16:20 |
| ajmitch | I don't know where that part is documented, I'll need to look it up | 16:21 |
| ajmitch | https://lists.ubuntu.com/archives/technical-board/2011-November/001122.html has the proposal to the TB | 16:22 |
| wendar | ah, yes | 16:23 |
| ajmitch | https://lists.ubuntu.com/archives/technical-board/2012-March/001224.html has followups from march | 16:23 |
| wendar | so, what they're talking about is opening P-backports at P-feature freeze | 16:23 |
| ajmitch | yep | 16:23 |
| wendar | we'd need an extra allowance | 16:23 |
| wendar | allowing O-backports to accept packages that are only in P-backports, and not in P-main archive yet | 16:23 |
| ajmitch | I'm guessing that we'd probably still have this dual-track of extras.ubuntu.com & backports, since using backports runs counter to having the myapps process for apps that aren't included as part of ubuntu itself | 16:26 |
| ajmitch | more of a definition problem of what it's meant to be | 16:26 |
| wendar | there's also the fact that the recommended path for totally new packages in Ubuntu is generally to go through Debian | 16:27 |
| ajmitch | yeah | 16:27 |
| wendar | we have redirected some submissions to Debian already | 16:27 |
| dholbach | alright, for me it's time to call it a day | 16:30 |
| dholbach | if you want to make changes to the wiki page, please do :) | 16:30 |
| wendar | thanks dholbach! | 16:30 |
| dholbach | have a great weekend everyone | 16:30 |
| * ajmitch doesn't want to look at the clock | 16:30 | |
| dholbach | big hugs! | 16:31 |
| ajmitch | 4:30AM... | 16:31 |
| dholbach | ugh, nuts | 16:31 |
| wendar | ajmitch: go to bed! | 16:31 |
| * dholbach hugs ajmitch | 16:31 | |
| * ajmitch hugs back | 16:31 | |
| ajmitch | I'll be up for the meeting in a few hours :) | 16:31 |
| ajmitch | anyway, 'night' :) | 16:32 |
| wendar | ajmitch: night! | 16:34 |
| wendar | ajmitch, highvoltage, lfaraone, stgraber: anything to meet about this month? I figure we'll have a more detailed catchup at UDS. | 20:09 |
| highvoltage | wendar: there's a lot we could talk about, but indeed, UDS is around the corner :) | 20:14 |
| wendar | highvoltage: the big thing is "how many UDS sessions do we want?" | 20:15 |
| wendar | I'm thinking of scheduling just one on Monday, and adding more later in the week if needed | 20:15 |
| highvoltage | wendar: for me personally... as few as possible, but not less than that. | 20:15 |
| highvoltage | wendar: that sounds good | 20:16 |
| wendar | I'm thinking of scheduling just one on Monday, and adding more later in the week if neededarb | 20:17 |
| wendar | blurg, shift and up arrow are right next to each other on this tiny netbook keyboard | 20:17 |
| wendar | meant to type: agreed, I don't want to go in with sessions scheduled for ARB every day | 20:18 |
| wendar | one or two (if some piece needs more followup) will probably be plenty | 20:19 |
| ajmitch | wendar: happy to meet at UDS rather than on irc | 20:51 |
| ajmitch | though I did just manage to wake up for this one ;) | 20:53 |
| wendar | and after so little sleep too! | 20:57 |
| wendar | ajmitch: I'm here if you want to go ahead and run | 20:57 |
| wendar | ajmitch: or want me to | 20:57 |
| wendar | we can at least get the blueprint in | 20:57 |
| ajmitch | in terms of stuff to talk about, I think we can just leave it for UDS | 20:58 |
| ajmitch | sorry for not writing up the meeting minutes from last time | 20:58 |
| ajmitch | I was going to check up on some bugs, which I did, and had positive progress on all of them | 20:59 |
| ajmitch | the python-distutils-extra bug was fixed in debian & subsequently in precise | 20:59 |
| wendar | that's great! | 21:00 |
| wendar | I need to go back and summarize a few months of minutes | 21:01 |
| ajmitch | yep, it made me happy to be to close it | 21:01 |
| ajmitch | s/to be/to be able/ | 21:01 |
| ajmitch | you'll be at UDS for the week? | 21:01 |
| wendar | yes, arrive on sunday, leave on saturday | 21:02 |
| ajmitch | great, seems like we'll have a few of us there | 21:02 |
| wendar | maybe we should do a BOF night | 21:02 |
| wendar | or, head out for pizza :) | 21:03 |
| ajmitch | I like that idea | 21:03 |
| * highvoltage too | 21:03 | |
| ajmitch | just looking at the blueprints registered so far, I hope we can get the ARB discussions out of the way in a session or two | 21:07 |
| wendar | up to 118 blueprints already, that's great! | 21:08 |
| ajmitch | https://blueprints.launchpad.net/ubuntu/+spec/community-q-upstream-myapps is mostly relevant to us, do we need to register another? | 21:08 |
| * ajmitch isn't sure if the discussion is meant to be around process on the upstream developer side, or reviewing | 21:09 | |
| wendar | That's more apps in general, though the ARB is part of it | 21:12 |
| wendar | it'd be worth having our own session, where we plan out the next cycle | 21:12 |
| ajmitch | ok | 21:12 |
| wendar | for us, that's mostly clearing old submissions, and building up volunteer reviewers | 21:13 |
| wendar | it might be a good chance to invite the MyApps developers in to talk through the bug list | 21:16 |
| ajmitch | that could be good, then we can explain what we'd like in terms of requiring a PPA for submissions | 21:17 |
| wendar | aye | 21:18 |
| wendar | This one may be interesting to attend: https://blueprints.launchpad.net/ubuntu/+spec/community-q-app-promotion | 21:19 |
| ajmitch | I think I've signed up for most of the 3rd party app sessions now | 21:19 |
| wendar | I'll be traveling tomorrow, but will be back on after that | 21:31 |
| wendar | do you want to put in the first rough cut of the blueprint? | 21:31 |
| ajmitch | it'll need to be after I wake up properly | 21:31 |
| wendar | monday will fill up fast | 21:31 |
| wendar | oh, yeah | 21:31 |
| wendar | getting it in Sunday or Monday would probably even be fine. | 21:32 |
| * ajmitch isn't looking forward to the travelling | 21:32 | |
| wendar | heh, yeah, you've got a *long* trip | 21:32 |
| wendar | mine is only one direct 9-hour flight | 21:32 |
| ajmitch | not quite as long as your trip for LCA | 21:32 |
| wendar | cheesecake compared to yours :) | 21:32 |
| wendar | yup | 21:32 |
| ajmitch | ~12 hours from auckland | 21:32 |
| wendar | that's pretty good | 21:33 |
| wendar | still long and boring, of course | 21:33 |
| ajmitch | I need to find a local pub in dunedin so we can have a last minute release party tonight, too :) | 21:33 |
| wendar | ah, sweet! | 21:33 |
| ajmitch | since a couple of the others here are going to oakland prior to UDS | 21:34 |
| wendar | Ubuntu Oregon is doing one on Sunday, so I'll be back in time for it | 21:34 |
| wendar | hopefully they'll visit around, Oakland isn't the most exciting part of the San Francisco Bay Area :) | 21:34 |
| ajmitch | I think it's up to 3 canonical people in dunedin now | 21:35 |
| wendar | wow | 21:35 |
| wendar | I should go get some sleep before the flight | 21:43 |
| ajmitch | ok, I'll try & write up a quick blueprint & submit it | 21:43 |
| wendar | leds for precise is building, and will hopeful get copied from the PPA to live tonight | 21:43 |
| wendar | cool, thanks! | 21:43 |
| wendar | ttys | 21:44 |
| ajmitch | I'm guessing it'll be 'community-q-app-review-board'? | 21:44 |
| wendar | yeah, that sounds good | 21:44 |
| ajmitch | ok then | 21:44 |
| ajmitch | enjoy your flight :) | 21:44 |
| ajmitch | (if that's possible) | 21:44 |
| wendar | will do | 21:44 |
| wendar | It is pretty much the only time I watch movies, so that's a pluss | 21:45 |
| * wendar waves off | 21:45 | |
| ajmitch | bye | 21:45 |
| highvoltage | bye wendar | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!