| === neversfelde_ is now known as neversfelde | ||
| carlos_ | j | 01:44 |
|---|---|---|
| === greeneggsnospam is now known as jsgotangco | ||
| DPic | why is the default background image in hardy the png version of the image when the svg isn't even as big? | 06:23 |
| === \sh_away is now known as \sh | ||
| === cjwatson_ is now known as cjwatson | ||
| === dholbach_ is now known as dholbach | ||
| === thekorn_ is now known as thekorn | ||
| === ubotu changed the topic of #ubuntu-meeting to: Current meeting: MOTU Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 05 Mar 07:00 UTC: Platform Team | 08 Mar 11:00 UTC: Kubuntu Developers | ||
| sistpoty|work | hi folks | 12:06 |
| * Hobbsee waves | 12:08 | |
| sistpoty|work | hi Hobbsee | 12:08 |
| * persia had expected to be late, but given the traffic wonders if the meeting perhaps hasn't started yet. | 12:08 | |
| persia | OK. Roll call. Who's here for the MOTU Meeting? | 12:10 |
| * Hobbsee is causing trouble, as usual | 12:10 | |
| * Mithrandir tickles the noisemaker, then runs off and levitates out of Hobbsee's reach. | 12:11 | |
| persia | #startmeeting | 12:11 |
| MootBot | Meeting started at 12:11. The chair is persia. | 12:11 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 12:11 |
| persia | [LINK] https://wiki.ubuntu.com/MOTU/Meetings | 12:11 |
| MootBot | LINK received: https://wiki.ubuntu.com/MOTU/Meetings | 12:11 |
| * Hobbsee levitates too, and tickles Mithrandir back | 12:11 | |
| sistpoty|work | who'll do the minutes? | 12:11 |
| persia | Welcome to the MOTU Meeting. The agenda is above. First item of business: | 12:12 |
| persia | [TOPIC] Who does minutes? | 12:12 |
| MootBot | New Topic: Who does minutes? | 12:12 |
| sistpoty|work | heh | 12:12 |
| Hobbsee | whoever's latest | 12:12 |
| sistpoty|work | given that there are logs, I guess I'd volunteer | 12:12 |
| persia | Anyone else? | 12:13 |
| persia | [AGREED] sistpoty does minutes | 12:13 |
| MootBot | AGREED received: sistpoty does minutes | 12:13 |
| persia | [TOPIC] Should Ubuntu Membership be a general requirement for MOTUship? | 12:13 |
| MootBot | New Topic: Should Ubuntu Membership be a general requirement for MOTUship? | 12:13 |
| persia | This topic was raised without attribution: who is the champioon? | 12:14 |
| persia | I think it was LaserJock, but he seems to be away. Does anyone else want to lead this? | 12:15 |
| persia | Does anyone have any opinion about this? Shall we defer for the next meeting? | 12:17 |
| * sistpoty|work doesn't have a strong opinion, but didn't really think about this tightly though | 12:18 | |
| sistpoty|work | hence I guess deferring makes the most sense to me, other opinions? | 12:18 |
| persia | Any other opinions? | 12:19 |
| persia | [AGREED] Defer discussion of Ubuntu Membership as a requirement for MOTU to the next meeting | 12:20 |
| MootBot | AGREED received: Defer discussion of Ubuntu Membership as a requirement for MOTU to the next meeting | 12:20 |
| persia | [TOPIC] Feature freeze policy. See ScottK's email and FeatureFreeze for details | 12:20 |
| MootBot | New Topic: Feature freeze policy. See ScottK's email and FeatureFreeze for details | 12:21 |
| persia | ScottK and LaserJock are both not here, so again, would anyone else like to lead this discussion? | 12:21 |
| sistpoty|work | Hobbsee: would you? ;) | 12:21 |
| Hobbsee | hm, I could be coerced | 12:22 |
| persia | Hobbsee: You do seem to be the representative of motu-release at the meeting... | 12:22 |
| Hobbsee | So, we have a feature freeze. Hopefully this should not be a surprise | 12:22 |
| Hobbsee | The policy is currently a feature freeze exception for all packages with new features. | 12:23 |
| Hobbsee | this includes native packages, as far as i'm aware. any disagreements so far? | 12:23 |
| sistpoty|work | well, as stated in my reply, I think native packages are some special thingy imho | 12:23 |
| Hobbsee | sistpoty|work: what are you thinking? | 12:24 |
| persia | I personally think native packages should have slightly different rules, but I'm opposed to native packages in general, so may not be an ideal spokesman for that viewpoint. | 12:24 |
| Hobbsee | this isn't getting onto native packages that are bugfix only - that's for later. | 12:24 |
| sistpoty|work | well, I can't say I know a sure answer, but my suggestion was that it should be left to whoever uploads a native package to decide if he/she needs an exception or not | 12:25 |
| sistpoty|work | *shrug* | 12:25 |
| Hobbsee | sistpoty|work: fair call. I'd hope we'd get to that point, for all packages. | 12:25 |
| persia | There are still different sorts of packages, whether native or not. Should mythbuntu-themes have different rules than xubuntu-themes just because it's not native? | 12:25 |
| Hobbsee | (that's been one of my dreams since UDS sevilla, in fact) | 12:26 |
| Hobbsee | persia: that's why i'd be leaning to the "any new package that introduces a feature needs a ffe" | 12:26 |
| Hobbsee | makes it fairly explicit, and easy to follow | 12:26 |
| sistpoty|work | persia: well, mythbuntu-themes was granted a general FFe (due to being limited by artwork deadline rather than FF) iirc | 12:26 |
| persia | Hobbsee: That makes sense. | 12:26 |
| Hobbsee | right, so does anyone either a) disagree with my proposal, or b) have a better solution? | 12:27 |
| persia | sistpoty|work: Yes, my point was about native vs. non-native, rather than the specific package. | 12:27 |
| sistpoty|work | Hobbsee: sounds pretty reasonable to me | 12:27 |
| persia | Hobbsee: How do we define "new feature"? | 12:27 |
| Hobbsee | persia: uh...however we usually do? | 12:27 |
| sistpoty|work | e.g. new binary packages from same source package would be an indication | 12:27 |
| Hobbsee | persia: do people have trouble figuring what a new feature is? | 12:28 |
| persia | [IDEA] any new package that introduces a feature needs a ffe | 12:28 |
| MootBot | IDEA received: any new package that introduces a feature needs a ffe | 12:28 |
| persia | Hobbsee: Based on traffic discussing FFe requests in #ubuntu-motu, I'd have to say "Yes". | 12:28 |
| Hobbsee | persia: what would be your idea for determing what a feature is? | 12:29 |
| Hobbsee | it could be a) "anything that doesn't fix a bug", b) something that creates new functionality | 12:29 |
| Hobbsee | iv'e always thought it was option b. This is not clear enough? | 12:29 |
| persia | "Provides additional functionality not available in the current package, for which the lack of functionality is not a regression from a previous release". | 12:29 |
| Hobbsee | persia: +1 | 12:29 |
| Hobbsee | anyone disagree with persia's definition for new feature? | 12:30 |
| Hobbsee | persia: [idea] that please | 12:30 |
| sistpoty|work | +1 | 12:31 |
| Hobbsee | okay. done. | 12:31 |
| persia | [idea] A feature is defined as something that "Provides additional functionality not available in the current package, for which the lack of that functionality is not a regression from a previous release" | 12:31 |
| MootBot | IDEA received: A feature is defined as something that "Provides additional functionality not available in the current package, for which the lack of that functionality is not a regression from a previous release" | 12:31 |
| Hobbsee | is there anything else we need to cover with packages that need a ffe? | 12:31 |
| Hobbsee | are the procedures not clear? is anyone lost? | 12:32 |
| Hobbsee | <echoing silence> | 12:32 |
| Hobbsee | right, so | 12:32 |
| sistpoty|work | maybe we should add the requirement to need a motu sponsor before asking for a FFe first? | 12:32 |
| persia | My understanding was that we were currently working in a somewhat grey zone, and Scott and Jordan wanted MOTU approval for process change allowing new upstreams not introducing new features, etc. | 12:32 |
| Hobbsee | sistpoty|work: ah yes, i've been wondering that for a while. | 12:33 |
| persia | Speaking as a sponsor, I'd like to see an approved FFe before it gets in the sponsors queue. | 12:33 |
| Hobbsee | is it better for our release people to see all the bugs first, or the sponsors, who there are more of? | 12:33 |
| persia | There aren't terribly many more sponsors, but I guess it's about even. | 12:33 |
| Hobbsee | my problem with sponsors first is that then the release people should upload, or bugs go thru 3 queues. | 12:34 |
| sistpoty|work | hm... imho the "i don't know what I'm doing" FFe's (which were quite some in the beginning) dropped in rate | 12:34 |
| Hobbsee | sistpoty|work: ok, good | 12:34 |
| persia | [IDEA] maybe we should add the requirement to need a motu sponsor before asking for a FFe first? | 12:34 |
| MootBot | IDEA received: maybe we should add the requirement to need a motu sponsor before asking for a FFe first? | 12:34 |
| sistpoty|work | and otoh some good ones need sponsors, so it might not be a problem of motu-release atm | 12:34 |
| sistpoty|work | I do see a problem with new packages from non-motus though, as currently we defer them to get the package reviewed first, which doesn't always happen | 12:35 |
| Hobbsee | my gut feeling is that it's still better for the release team to go through first, and sponsors second. sponsors should remember that the release people have checked for hte feasibility of the change, not necessarily whether it's correct or not. | 12:35 |
| Hobbsee | the release people are going to see fairly quickly if hte bugs are wrong/incomplete, and mark them that wya | 12:35 |
| persia | That sounds like it will work better for also handling cases where a MOTU requests a freeze exception. | 12:36 |
| sistpoty|work | yeah, I guess unless we're really getting flooded with bad FFe's let's keep the current model | 12:36 |
| Hobbsee | sistpoty|work: this is true. revu still appears to be disaster-land for getting stuff reviewed. | 12:36 |
| Hobbsee | i dont' think that's going to be an easy one to solve, nor one that we have to solve now (fortunately) | 12:37 |
| persia | It was pretty good up through FF, at which point it went sour again. Should get better after a new REVU Coordinator is selected in two weeks. | 12:37 |
| Hobbsee | yeah, hopefully | 12:37 |
| Hobbsee | if we could make sure all the good minds actually get to UDS - in person, or by mic, and discuss togehter, that would be good | 12:38 |
| sistpoty|work | well, there are a few good candidates imho (e.g. gnome-lirc-properties)... maybe we could ask the requestor to send a mail to -motu or s.th. to get the package reviewed? | 12:38 |
| Hobbsee | sistpoty|work: that's another can of worms - want to get thru the release stuff before deciding revu things? | 12:38 |
| persia | Does that work? It doesn't seem to be doing much for glassfish. I think it's better for any interested reviewer to help find a second advocate | 12:39 |
| persia | OK. Back to release stuff. Do we have enough yet to agree on something, or are there more components of the policy to be discussed? | 12:39 |
| Hobbsee | i've not been watching REVU, so i can't comment | 12:39 |
| Hobbsee | persia: we can, and have, agreed on the first half, i think | 12:39 |
| * persia is waiting for the rest of the policy to make minutes more readable | 12:40 | |
| Hobbsee | the ffe for new features, what a feature is, and to go to release first, then sponsors for nonMOTUs | 12:40 |
| Hobbsee | this is all good, i haven't heard objections. | 12:40 |
| sistpoty|work | Hobbsee: for me it would make sense to have -release sort out the "we don't want this" packages and give a final ack after the package is reviewed... how could we achieve this? | 12:40 |
| Hobbsee | <cue rest of preformatted text> | 12:40 |
| sistpoty|work | (still thinking of new packages) | 12:40 |
| Hobbsee | sistpoty|work: er...i would have thought they should be doing that *first*, to show what to give reviewer priority for | 12:41 |
| persia | sistpoty|work: Isn't that covered by the "please get two advocates on REVU and revisit this bug" note? | 12:41 |
| Hobbsee | it's an awful lot of resources to do full reviews and acks, just to be told "this is unsuitable" | 12:41 |
| Hobbsee | an "i agree with this package in principle, as soon as it gets done soon" | 12:41 |
| sistpoty|work | persia: apart from that it's not really working, I guess so | 12:41 |
| persia | sistpoty|work: True. Hmm... Might it make sense to raise "How to manage new packages after FF" as a new topic later? | 12:42 |
| sistpoty|work | persia: ok | 12:42 |
| Hobbsee | in general, the ideal way of making this stuff work is getting things through the conceptual stage first (do we want this in hardy, or not? for eg), then get onto the technical side | 12:43 |
| Hobbsee | as the first is quicker than the second | 12:43 |
| persia | Hobbsee: Do you have anything else for non-new package FFe policy items? | 12:43 |
| Hobbsee | yes | 12:43 |
| Hobbsee | However, this time, we've had a new procedure that we have to file bugs for bug-fix only releases. A lot of people, myself included, have complained about the paperwork. | 12:43 |
| Hobbsee | it's also made it more complex than main, which suggests we have a problem with too many processes, or bad people. | 12:44 |
| Hobbsee | now, out of these, id' hope it was the people | 12:44 |
| persia | [idea] dispense with filing bugs just to close them in the next upload | 12:44 |
| MootBot | IDEA received: dispense with filing bugs just to close them in the next upload | 12:44 |
| Hobbsee | so, we've had FF for a couple of weeks - have we actually found *any* bugfix only releases that shouldn't have gone through? | 12:44 |
| persia | Personally, I'm in favor of having bugs for anything being done, just to advertise work-in-progress and avoid package interference. | 12:44 |
| sistpoty|work | well, there have been at least two syncs given back to motu-release, which were declared as bug fix (but are missing info still, so I can't say if these should go through yet) | 12:45 |
| Hobbsee | persia: things tend to get uploaded quickly for MOTU's, and non-MOTUs have already got bugs | 12:45 |
| persia | (unless it's ~15 minutes of work, but that's not typically the case for a new upstream version) | 12:45 |
| Hobbsee | persia: have you had conflicts of work with bugs recently? | 12:45 |
| persia | Hobbsee: I'd claim that the MOTU ought be looking at those as well. | 12:45 |
| Hobbsee | sistpoty|work: right. by MOTU's or non-motus? | 12:45 |
| Hobbsee | persia: oh, sure, no question there. | 12:46 |
| sistpoty|work | Hobbsee: motus (the same one actually) | 12:46 |
| persia | Not when there is a bug filed, but sistpoty|work & I played ping-pong with a package recently when making quick changes, and we ought have discussed it more rather than each uploading. | 12:46 |
| Hobbsee | sistpoty|work: have you spoken to the MOTU in question about it? | 12:46 |
| sistpoty|work | persia: heh, but it did work out at least, didn't it? ;) | 12:46 |
| Hobbsee | sistpoty|work: if it's only one person, then resolving that with them might be more effective than giving rules for everyone | 12:47 |
| persia | sistpoty|work: I think so. At least it works for us :) | 12:47 |
| sistpoty|work | Hobbsee: not yet, wasn't online when I saw it | 12:47 |
| Hobbsee | sistpoty|work: right. can you do so at some point in the future please? | 12:47 |
| sistpoty|work | Hobbsee: sure | 12:47 |
| Hobbsee | sistpoty|work: thanks | 12:47 |
| Hobbsee | again, i suspect that checking that the last uploader isn't already working on something is a good idea for new versions, etc | 12:48 |
| sistpoty|work | generally, I still believe that it makes sense to have bugs (1-> think before uploading, 2-> motu-release can see the state of the package better, if there should later be trouble)... | 12:48 |
| Hobbsee | sistpoty|work: for 1, why not encourage people to think before *signing*, so it works all cycle? | 12:48 |
| sistpoty|work | however I must admit that I'd currently drop that bug requirement, merely because it's just not getting done by the majority, and it's different from main | 12:49 |
| Hobbsee | sistpoty|work: what, it's documented "new upstream release"? :) | 12:49 |
| persia | It need not be a new bug: there's often upgrade bugs lying about for many packages. | 12:49 |
| sistpoty|work | Hobbsee: 2) it's documented what bug(s) have been there | 12:49 |
| Hobbsee | sistpoty|work: what do you mean? | 12:49 |
| sistpoty|work | Hobbsee: well, I'd like to see for example oh, now we have a new feature version, and there have been 10 bugs in the past, one being a new upstream bugfix version which solved lots of bugs | 12:50 |
| sistpoty|work | s.th. like that... | 12:51 |
| sistpoty|work | but as I wrote earlier, currently I'd drop that requirement to file bugs | 12:51 |
| Hobbsee | sistpoty|work: arent' people supposed to be listing bugs being closed in debian/changelog? | 12:51 |
| persia | sistpoty|work: Where there are existing bugs, is it not better to close those than to open a special new bug? | 12:51 |
| sistpoty|work | Hobbsee: not if there are no bugs in bts (but known only be the maintainer for example) | 12:51 |
| Hobbsee | sistpoty|work: that *should* give us the documentation advantage, of <list of bugs> being fixed with this upload, with the new version | 12:51 |
| === mrevell is now known as mrevell-lunch | ||
| * persia thinks a special new bug should only be required when there are no other open bugs being fixed by the new upstream | 12:52 | |
| Hobbsee | sistpoty|work: i dont' see how that helps with bugs that are only known to the maintainer | 12:52 |
| Hobbsee | if others have noticed, then they'll have filed a bug. clearly tehy haven't, so why would htey now notice, or care, that a bug htey didn't know about before has been fixed? | 12:53 |
| Hobbsee | i don't think i'm seeing your point here | 12:53 |
| persia | Hobbsee: "Maintainer"? We're talking about universe here. | 12:53 |
| Hobbsee | persia: sistpoty|work's definition. | 12:54 |
| sistpoty|work | Hobbsee: then why should such a new upstream version get uploaded in the first place? | 12:54 |
| Hobbsee | sistpoty|work: if it fell under the bugfix only rules? | 12:54 |
| sistpoty|work | Hobbsee: but what bug fixes it? (that's what I like to know) | 12:54 |
| Hobbsee | upstream bug number blah? | 12:54 |
| persia | sistpoty|work: Might be a new upstream that upstream reported as "bugfix", or that someone thought might just be bugfix from review from a more general upstream announcement. | 12:55 |
| Hobbsee | bugs don't fix versions, last i checked. it's the other way aorund | 12:55 |
| Hobbsee | sistpoty|work: i may be misunderstanding you, but i don't see what the point of filing a bug is that contains effectively the same information as what should be in debian/changelog | 12:55 |
| sistpoty|work | it's easier to lookup, and it too often is *not* part of debian/changelog :( | 12:56 |
| sistpoty|work | anyway how about voting to still have the requirement of filing a bug? | 12:56 |
| Hobbsee | sistpoty|work: ugh. others of us do not share your love of launchpad :) | 12:56 |
| persia | sistpoty|work: Perhaps having it be part of debian/changelog should be part of FF requirements, and anything not meeting that requirement should get email from motu-release asking for details? | 12:57 |
| sistpoty|work | heh | 12:57 |
| Hobbsee | sistpoty|work: instead of filing a bug, i'd like to make it mandatory to list the changes, or the main changes (whichever), in debian/changelog | 12:57 |
| Hobbsee | persia: +1 | 12:57 |
| Hobbsee | (for non-ffe's | 12:57 |
| sistpoty|work | sure, that makes sense | 12:57 |
| Hobbsee | (that's the eventual point i was getting at) | 12:57 |
| Hobbsee | right, so any dissentions? | 12:58 |
| Hobbsee | <pause> | 12:58 |
| Hobbsee | <pin drop> | 12:58 |
| Hobbsee | for consistancy, and general use, can we make it mandatory to list the upstream changes, or the more important ones in the changelog for both bugfix and feature releases? | 12:59 |
| Hobbsee | that would be really useful. | 12:59 |
| persia | Perhaps something like http://paste.ubuntu.com/5137/ ? | 12:59 |
| persia | [IDEA] make it mandatory to list the upstream changes, or the more important ones in the changelog for both bugfix and feature releases | 13:00 |
| MootBot | IDEA received: make it mandatory to list the upstream changes, or the more important ones in the changelog for both bugfix and feature releases | 13:00 |
| Hobbsee | persia: yeah, exactly | 13:00 |
| sistpoty|work | +1 | 13:00 |
| Hobbsee | i know seb128, etc, tends to do that with his gnome releases, which works well | 13:01 |
| Hobbsee | right. | 13:01 |
| persia | I think those are sometimes a little extra-wordy, but it's some help. | 13:01 |
| Hobbsee | so, at the end, we have covered: | 13:01 |
| Hobbsee | the ffe for new features, what a feature is, and to go to release first, then sponsors for nonMOTUs | 13:01 |
| Hobbsee | bugfix only releases | 13:02 |
| Hobbsee | what needs to be in debian/changelog for ALL new upstream releases. | 13:02 |
| persia | My list has "require a bug for new upstream" rather than "bugfix only releases". | 13:02 |
| Hobbsee | persia: new upstream release *with features* | 13:02 |
| persia | (or rather "dispense with filing bugs just to close them in the next upload") | 13:02 |
| sistpoty|work | persia: can we get an agreed to drop it? | 13:02 |
| Hobbsee | sistpoty|work: we just did. this is the summary, afaik. | 13:03 |
| persia | sistpoty|work: I suppose. I wanted to make sure we got all the FF bits discussed, and then propose a summary. | 13:03 |
| persia | Hobbsee: Just to confirm, are there any more components? | 13:03 |
| Hobbsee | persia: just did that. i can email the list about the new policy if you want | 13:03 |
| sistpoty|work | kk | 13:03 |
| Hobbsee | persia: only new packages post-ff | 13:03 |
| Hobbsee | my current proposal for that was listed above: | 13:03 |
| persia | Should that be part of this topic, or the next? | 13:04 |
| Hobbsee | mmm, the next. | 13:04 |
| Hobbsee | ie, the one that starts now :) | 13:04 |
| persia | I'm thinking it's more about mechanics and procedure than policy, and would like to go ahead with this if we can. | 13:04 |
| Hobbsee | right | 13:04 |
| Hobbsee | so if we want a new, post-ff package in ubuntu | 13:04 |
| Hobbsee | then the user files a bug (likely already done), lists why it should be a part of ubuntu, even though it's late. <include all the whiny excuses about disorganisation, etc, here> | 13:05 |
| Hobbsee | subscribes motu-release | 13:05 |
| Hobbsee | motu release says yay/nay for the release. | 13:05 |
| persia | wait... | 13:05 |
| Hobbsee | then reviewers look | 13:05 |
| Hobbsee | that's my scarecrow proposal. tear apart as you wish | 13:06 |
| sistpoty|work | ooops, I'm totally sorry, but I gotta rush to a meeting right now | 13:06 |
| persia | [AGREED] Any new package or new upstream version that introduces a feature needs an approved FFe prior to upload. | 13:06 |
| MootBot | AGREED received: Any new package or new upstream version that introduces a feature needs an approved FFe prior to upload. | 13:06 |
| Hobbsee | oh, sorry. trying to get this over quickly, as we're already late | 13:06 |
| persia | [AGREED] Any upload post-feature freeze must contain full details of the bugs fixed in debian/changelog | 13:06 |
| MootBot | AGREED received: Any upload post-feature freeze must contain full details of the bugs fixed in debian/changelog | 13:07 |
| persia | [TOPIC] Handling new packages after Feature Freeze | 13:07 |
| MootBot | New Topic: Handling new packages after Feature Freeze | 13:07 |
| persia | Sorry. Just catching up. | 13:07 |
| Hobbsee | no problem | 13:07 |
| persia | OK. Proposal is that motu-release approves a bug, it gets reviewed on REVU, and uploaded, right? | 13:08 |
| Hobbsee | yes | 13:08 |
| persia | Should it involve universe sponsors for attention, as REVU is fairly quiet these days? | 13:09 |
| Hobbsee | so, if MOTU-release approves the bug, they know that it's going to take an archive admin's time, and think that they'll have the time | 13:09 |
| Hobbsee | that would be a good idea | 13:09 |
| persia | Any other suggestions, opinions, comments? | 13:09 |
| Hobbsee | only that if it is too late, and the archive admins don't have time, then tehy won't review anyway. | 13:10 |
| Hobbsee | so any packages which *do* have good reasons to get an ack, but are still very late, may not get in just due to timing. | 13:10 |
| persia | That sounds like a footnote for policy. Maybe a hard freeze on new packages for BetaFreeze or something? | 13:10 |
| Hobbsee | *shrug* | 13:11 |
| mok0 | It would be useful to get the revu workflow merged into the one being discussed at the moment | 13:11 |
| Hobbsee | i'd prefer to keep it open for some mega-mega-shiny-extra-special-zomg-the-sky-is-falling package. everything else -release will reject. | 13:11 |
| persia | Hobbsee: Makes sense | 13:11 |
| Hobbsee | mok0: not with this many people, i suspec.t | 13:11 |
| Hobbsee | persia: right, so +1? | 13:12 |
| persia | mok0: Probably best to work on getting https://wiki.ubuntu.com/Spec/ReviewProcessConvergence as a UDS discussion topic | 13:12 |
| Hobbsee | please make sure you do that over VOIP | 13:12 |
| persia | Hobbsee: Works for me. | 13:12 |
| Hobbsee | i didn't get an invite, probably due to inactivity and causing hell, but i'd still like to be there and contribute | 13:13 |
| persia | Any disagreement with the proposed workflow for new packages after feature freeze? | 13:13 |
| Hobbsee | nope | 13:13 |
| persia | Hobbsee: VoIP, email, IRC, and sleeping in UDS timezone goes a long way :) | 13:13 |
| Hobbsee | yeah, true | 13:13 |
| Hobbsee | i know - iv'e been there, and contributed from the outside before. it's tough. | 13:14 |
| persia | [AGREED] New source packages proposed after FeatureFreeze require motu-release approval for the package inclusion bug prior to upload. motu-release will subscribe the sponsors when approving to request review and processing of the REVU candidate. | 13:15 |
| MootBot | AGREED received: New source packages proposed after FeatureFreeze require motu-release approval for the package inclusion bug prior to upload. motu-release will subscribe the sponsors when approving to request review and processing of the REVU candidate. | 13:15 |
| persia | OK. Any other topics? | 13:15 |
| Hobbsee | hm | 13:15 |
| Hobbsee | none from me, i don't think | 13:15 |
| persia | Anyone else? | 13:15 |
| Hobbsee | getting more people to proxy for meetings might be a good one, though | 13:16 |
| mok0 | I'd like to ask what happened to ubuntuwire | 13:16 |
| persia | mok0: not really a MOTU thing, but there's an authentication issue with modifying DNS to use alternate hosts. | 13:16 |
| Hobbsee | is imbrandon here? | 13:16 |
| mok0 | qa, that is. It is detrimental to debugging work that it is not up | 13:16 |
| Hobbsee | ah | 13:16 |
| persia | mok0: Agreed. It's about half-on topic :) | 13:17 |
| mok0 | There are a lot of MOTU resources on that machine | 13:17 |
| Hobbsee | i guess that's a topic for #ubuntuwire | 13:17 |
| persia | #ubuntuwire can't really do anything now, but yes, that is where it belongs. | 13:18 |
| mok0 | Well, I think it is a problem at a critical time when we are trying to get hardy in shape | 13:18 |
| Hobbsee | mok0: and you're talking to the wrong people about it, i think | 13:18 |
| persia | mok0: Well, we didn't have it for the last 7 releases, so we'll get by... | 13:18 |
| persia | Anyway, back on the meeting so we can end it. | 13:19 |
| mok0 | That's a poor argument, persia | 13:19 |
| Hobbsee | interesting. you can ssh into your own machine. i didn't know that. | 13:19 |
| mok0 | Another thing: | 13:19 |
| Hobbsee | meeting closed. any objections? | 13:19 |
| mok0 | never mind | 13:19 |
| persia | mok0: What's the other thing? | 13:20 |
| Hobbsee | mok0: go ahead, if it's a MOTU thing | 13:20 |
| mok0 | I'd like to suggest that we have a logo contest for a new Universe logo | 13:20 |
| persia | [TOPIC] logo contest for a new Universe logo | 13:21 |
| MootBot | New Topic: logo contest for a new Universe logo | 13:21 |
| persia | "New" logo? I didn't know we had one. | 13:21 |
| mok0 | Well, theres the ubuntu logo with a big fat U on top of it | 13:21 |
| persia | Do you have a link? | 13:21 |
| * mok0 thinks | 13:22 | |
| mok0 | I've seen it on a list of packages | 13:22 |
| === allee_ is now known as allee | ||
| === mrevell-lunch is now known as mrevell | ||
| mok0 | Anyway, perhaps it would be good to profile the community part of Ubuntu a bit more | 13:23 |
| mok0 | and a logo would be a good thing for that | 13:23 |
| Hobbsee | mok0: want to email the list about it? | 13:23 |
| mok0 | Sure. It can be discussed there | 13:23 |
| persia | Also, it seems more a marketing / advocacy thing than a development thing. Might be good to cc: those groups. | 13:23 |
| mok0 | ok | 13:24 |
| persia | [AGREED] mok0 to lead logo discussion on the mailing lists | 13:24 |
| MootBot | AGREED received: mok0 to lead logo discussion on the mailing lists | 13:24 |
| persia | Anything else? | 13:24 |
| Hobbsee | nope | 13:24 |
| Hobbsee | persia: are you emailing the list about the freeze stuff as part of your minutes, or am i doing the minutes as part of the motu freeze stuff? | 13:25 |
| === Pricey is now known as PriceChild | ||
| persia | Hobbsee: sistpoty is doing minutes (as agreed above). If you'd be willing to update the wiki to indicate the new freeze rules, that would be great. | 13:26 |
| Hobbsee | oh, i thought you were | 13:26 |
| Hobbsee | hmm, i'll try | 13:26 |
| persia | [ACTION] Hobbsee to update the wiki with the agreed freeze rules | 13:27 |
| MootBot | ACTION received: Hobbsee to update the wiki with the agreed freeze rules | 13:27 |
| persia | As a last note, the next MOTU Meeting will be 14th March, 20:00 UTC. Anyone willing to notify the fridge and send annoucements to the mailing list? | 13:27 |
| persia | [ACTION] persia to send announcements for the next meeting | 13:29 |
| MootBot | ACTION received: persia to send announcements for the next meeting | 13:29 |
| persia | Thanks everyone for joining the meeting. See you next time. | 13:29 |
| persia | #endmeeting | 13:29 |
| MootBot | Meeting finished at 13:29. | 13:29 |
| persia | sistpoty|work: http://kryten.incognitus.net/mootbot/meetings/ubuntu-meeting.20080229_1211.html | 13:30 |
| persia | http://kryten.incognitus.net/mootbot/meetings/ubuntu-meeting.log.20080229_1211.html | 13:30 |
| === ubotu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 05 Mar 07:00 UTC: Platform Team | 08 Mar 11:00 UTC: Kubuntu Developers | ||
| === asac_ is now known as asac | ||
| === dholbach_ is now known as dholbach | ||
| === greeneggsnospam is now known as jsgotangco | ||
| === j_ack__ is now known as j_ack | ||
| === \sh is now known as \sh_away | ||
| === leonel_ is now known as leonel | ||
| === alleeHol is now known as allee | ||
| === doko_ is now known as doko | ||
| === \sh_away is now known as \sh | ||
| === neversfelde_ is now known as neversfelde | ||
| emgent | @schedule | 19:22 |
| ubotu | Schedule for Etc/UTC: 05 Mar 07:00: Platform Team | 08 Mar 11:00: Kubuntu Developers | 19:22 |
| === \sh is now known as \sh_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!