ubotuSchedule for Etc/UTC: 01 Feb 20:00: MOTU | 13 Feb 22:30: Forum Council | 20 Feb 01:00: TriLoCo-Midwest00:10
bmk789@schedule EST00:10
ubotuSchedule for EST: 01 Feb 15:00: MOTU | 13 Feb 17:30: Forum Council | 19 Feb 20:00: TriLoCo-Midwest00:10
=== Varka_ is now known as Varka
=== asac_ is now known as asac
=== Hobbsee_ is now known as Hobbsee
=== Hobbsee` is now known as Hobbsee
=== soren_ is now known as soren
=== txwikinger2 is now known as txwikinger
=== bmk789_ is now known as bmk789_brb
=== mvo__ is now known as mvo
=== bmk789_brb is now known as bmk789
=== alleeHol is now known as allee
leonelHow can I know  which messages are  or how can I  recover these 9  messages Setting DELETE status for deleted messages...15:11
leonelOk. [9] messages set for deletion.15:11
leonelsorry wrong window15:13
ubotuCurrent time in Etc/UTC: February 01 2008, 15:23:10 - Next meeting: MOTU in 4 hours 36 minutes15:23
=== bmk789 is now known as bmk789_brb
bmk789_brb@now EST17:54
ubotuCurrent time in EST: February 01 2008, 12:54:33 - Next meeting: MOTU in 2 hours 5 minutes17:54
=== bmk789_brb is now known as bmk789
shadowh511is there a meeting or something?18:39
protonchris@now MDT18:44
protonchris@now MST18:45
ubotuCurrent time in MST: February 01 2008, 11:45:33 - Next meeting: MOTU in 1 hour 14 minutes18:45
=== ubotu changed the topic of #ubuntu-meeting to: Current meeting: MOTU Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 13 Feb 22:30 UTC: Forum Council | 20 Feb 01:00 UTC: TriLoCo-Midwest
DktrKranznixternal, hi Richard, congrats :)19:57
nixternalhrmm, I wonder if persia will be around to speak about his agenda item20:00
ScottKShall we begin?20:02
nixternalwant to use MootBot?20:02
nixternalhiya sistpoty20:02
sistpotyhi nixternal20:02
* ScottK has no idea, just as long as he isn't stuck doing minutes.20:02
nixternalScottK: MootBot will take care of the minutes for us iirc20:03
* ScottK looks at nixternal and is glad he knows how to handle it then.20:03
nixternalshould we wait a couple of minutes for any stragglers?20:03
ScottKI'd say we already have.20:03
MootBotMeeting started at 20:04. The chair is nixternal.20:04
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]20:04
nixternal[TOPIC] Rename motu-uvf - ScottK20:04
MootBotNew Topic:  Rename motu-uvf - ScottK20:04
nixternalgo ahead ScottK, the floor is yours20:04
ScottKClearly since we no longer have uvf, we need a new name.20:05
ScottKmotu-ff, motu-release, motu-freeze have been suggested so far20:05
ScottKAny preferences from anyone?20:06
nixternal[IDEA]Clearly since we no longer have uvf, we need a new name.20:06
MootBotIDEA received: Clearly since we no longer have uvf, we need a new name.20:06
nixternal[IDEA] motu-ff, motu-release, motu-freeze have been suggested so far20:06
MootBotIDEA received:  motu-ff, motu-release, motu-freeze have been suggested so far20:06
* sistpoty thinks that motu-release would also shift the purpose of the team20:07
DktrKranzI'd say motu-release, just for mere assonance with ubuntu-release20:07
nixternalwell, since uvf is no longer around, then obvious a name change would probably make the teams goals a tad bit clearer20:07
ScottKWell sistpoty brings up an interesting question.20:07
geserbut wouldn't people expect from motu-release more than it really is?20:07
ScottKFor Gutsy, motu-uvf was active helping manage things up through release.20:07
ScottKNo one complained and I think it helped a lot with a good end game for Universe.20:07
* RainCT says hi. sorry, just remembered about the meeting.20:07
nixternalI thought motu-freeze sounded kind of cool and actually gets its point across a bit20:08
ScottKI'm good with either motu-freeze or motu-release.20:09
ScottKFF is the first step in release management for Universe.20:09
sistpotyScottK: so you think that (the team formerly known as) motu-uvf should in fact care with release matters?20:09
ScottKsistpoty: I do.20:09
ScottKsistpoty: We did it for Gutsy and it worked well.20:09
sistpotyhm... I guess the goals are quite similar in fact20:10
sistpoty(for a release team and handling uvf-requests)20:10
ScottKIt's really the same kind of risk/benifit tradeoff, just with different focus as the release gets closer.20:10
nixternalor what was formally called uvf-requests I guess20:10
sistpotyso I don't have any objections to motu-release20:10
ScottKAny objections to that?20:11
* RainCT likes it20:11
nixternalshould we take a vote on motu-release? if so I will set MootBot to record the votes20:11
* sistpoty likes votes20:12
ScottKnixternal: We can if you want, but no one objected.20:12
nixternal[VOTE] Do we change the name of motu-uvf to motu-release?20:12
MootBotPlease vote on:  Do we change the name of motu-uvf to motu-release?.20:12
MootBotPublic votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot20:12
MootBotE.g. /msg MootBot +1 #ubuntu-meeting20:12
MootBot+1 received from nixternal. 1 for, 0 against. 0 have abstained. Count is now 120:12
MootBot+1 received from ScottK. 2 for, 0 against. 0 have abstained. Count is now 220:12
MootBot+1 received from sistpoty. 3 for, 0 against. 0 have abstained. Count is now 320:12
MootBot+1 received from RainCT. 4 for, 0 against. 0 have abstained. Count is now 420:12
MootBot+1 received from DktrKranz. 5 for, 0 against. 0 have abstained. Count is now 520:12
nixternalis that everyone?20:12
MootBot+1 received from superm1. 6 for, 0 against. 0 have abstained. Count is now 620:13
nixternalany day now bot20:13
sistpotyhe, I guess you dislike votes from now, nixternal? *g*20:14
nixternalit seems he likes to hang when ending a vote, possibly because he can't do simple addition :)20:14
DktrKranzmh, probably when an new topic is set, endvote is called20:15
gesernixternal: simply change the topic and mootbot will close the vote20:15
sistpotynixternal: write what ScottK proposed20:15
nixternal[AGREED] motu-uvf to become motu-release20:15
MootBotAGREED received:  motu-uvf to become motu-release20:15
nixternal[TOPIC] Moving on...20:15
MootBotVote is in progress. Finishing now.20:15
MootBotFinal result is 6 for, 0 against. 0 abstained. Total: 620:15
MootBotNew Topic:  Moving on...20:15
nixternalthere you go20:16
nixternalsince persia isn't around to talk about his topic, does anyone else have anything to add?20:16
ScottKI'll speak on persia's topic since he's not hear.20:16
nixternalok...let me set that one up20:16
nixternal[TOPIC] Switch from Interdiff to diff.gz for new upstream candiadtes (EmmetHikory) - covered by ScottK20:17
MootBotNew Topic:  Switch from Interdiff to diff.gz for new upstream candiadtes (EmmetHikory) - covered by ScottK20:17
* sistpoty is glad to not have to fight with MootBot this time... once was enough *g*20:17
nixternalI was mdz fight with it too, you would think I would have learned :)20:17
nixternalerr, s/was/watch20:17
ScottKpersia put forward the idea of using interdiff and we tried it.20:17
ScottKIt's a good idea in theory, but a real PITA in practice.20:17
ScottKI think we've discussed enough that a .diff.gz is sufficient in almost all cases and easier to both understand and create.20:18
ScottKSo the question is do we stick with interdiff, switch to .diff.gz, or handle upgrade some other way.20:18
ScottKThe key point, I think, is the sponsor should fetch the tar.gz themselves and be able to easily review the proposed package.20:19
nixternal.diff.gz is easier in practice than the interdiff, at least it proved that way for me20:19
* sistpoty hasn't tried interdiff yet, so sistpoty doesn't have a real opinion20:19
nixternalI did a couple of interdiffs, and each time I kept reading the wiki...20:19
LaserJockdid I miss it?20:20
ScottKAnyone like interdiff?20:20
* RainCT tried sponsoring an interdiff but couldn't achieve to get the source, even following the wiki :(20:20
nixternalRainCT: ya, me either20:20
ScottKLaserJock: We're just discussing switching from interdiff to diff.gz for upgrade bug sponsoring.20:20
* txwikinger does not understand why interdiff is advantegeous over just taking the new orig and diff20:20
DktrKranzwith .diff.gz in place, it could be possible to obtain interdiff quite easily, but it is harder to have interdiffs for someone who is not comfortable with it20:20
nixternalwhat happened with using debdiff?20:21
LaserJockI couldn't care less what people use as long as they give me something I can use20:21
ScottKnixternal: Debdiff for a new upstream would include all the upstream changes too.20:21
nixternalheh, I am actually the same as LaserJock20:21
LaserJockI'm not sure why we are actually having this discussion20:21
nixternalScottK: gotcha, and we are trying to limit to just ubuntu/debian changes then20:21
superm1i'd be for just having diff's of the debian directory20:21
superm1have them extract both and just run diff across the two directories and attach that to a bug20:22
sistpotysuperm1: that would exclude packages not using a patch system20:22
ScottKLaserJock: Because the agreement is we don't change process/policy unless agreed at a MOTU meeting.20:22
superm1sistpoty, ah yeah.20:22
LaserJockScottK: my point is why is this policy? it seems petty and silly20:22
ScottKLaserJock: Because there was a meeting and it was decided.20:22
* ScottK wasn't at the meeting.20:22
LaserJockme neither, so I guess I should just shut up20:23
nixternalIt does seem that way, but I understand the wanting of common process20:23
* sistpoty thought back then to give it a try20:23
nixternalotherwise trying to teach future MOTUs the availability of 10 different processes can be a pita at times20:23
LaserJock"get us the source package, we don't care how" doesn't seem to be all that bad20:23
nixternalbut providing them choice is good imho, as it will allow them to follow a practice that suits their style possibly20:24
sistpotythough I'm not active in sponsoring, what speaks against a link to a dsc attached to the bug report?20:24
nixternalsistpoty: not everyone has a place to store the .dsc and the rest of the files20:25
LaserJockthere's revu if they don't20:25
sistpotynixternal: revu can store dsc's, so I guess everyone has20:25
nixternalI believe that was the argument heard when I thought of a similar idea a while back20:25
LaserJockand if they aren't that big LP would be fine20:25
superm1everyone can use revu or ppa to store them20:25
nixternalalso people can link us to their PPA20:25
* ScottK very much dislikes PPA for this due to versioning issues20:25
superm1well you can delete stuff in PPAs now20:26
sistpotyLaserJock: no, LP (as in attachments) will screw the names, but PPAs are an alternative20:26
DktrKranzHaving .diff.gz (and interdiff, of course) requires a watch file to grab .orig.tar.gz, what if watch files can't be implemented?20:26
superm1so you can use proper versioning if you want20:26
sistpotylinks even20:26
ScottKSponsoree should propose exactly what they want uploaded, not with PPA versioning.20:26
LaserJocksistpoty: screw what names?20:26
sistpotyLaserJock: link names20:26
sistpotyLaserJock: as in you can't dget20:26
nixternalahh, good point20:26
LaserJocksistpoty: oh well20:26
RainCTsistpoty: there's dgetlp in ubuntu-dev-tools20:26
nixternalit will give them that 0034802934408202__48389W.dsc garbage20:26
* sistpoty would rather have a straight dget... but with PPAs that is possible20:27
nixternalperfect timing persia :)20:27
nixternalwe are covering your topic right now, care to add?20:27
ScottKActually I think they fixed LP to have dget work with it now.20:27
sistpotyhi persia20:27
sistpotyScottK: cool20:27
* persia apologises for being late20:27
* ScottK hands the gavel to persia.20:27
LaserJockI just don't think we need a strict policy for this, but I'd prefer diff.gz over interdiff20:27
nixternalI would as well20:27
geserScottK: does it also work for attached packages or only for published packages?20:27
* sistpoty would just like to have anything dget'able linked in the bugreport20:28
persiaIt's not about policy, it's more about standard recommendations to newcomers, and expected processing by sponsors.20:28
nixternalpersia: thanks for clarifying that20:28
persiasistpoty: That's inherently error-prone, as it doesn't force the use of upstream sources.20:28
LaserJockpersia: but that institutes policy and creates punishment for not doing so20:28
persiaLaserJock: True.20:28
LaserJock"no I won't sponsor your package because you didn't format it the way I want it"20:28
sistpotypersia: that would always need checking, right20:28
sistpoty(note, that I'm not favourable to "must have" get-orig-source or similar20:29
persiasistpoty: It's not been historically checked well using dget and REVU or third-party websites.20:29
nixternalso maybe have a list of a few recommendations on how MOTU members who are willing to sponsor a package would like to see a diff created possibly?20:29
sistpotyoh, side note: I don't want the commenting to happen on revu... (and I guess could easily hide non-new packages there), so that we have one place (LP) to comment on a new upstream version20:30
nixternalin a sense, you have to convince a sponsor to, well sponsor you...and making it easier for the sponsor truthfully will only make it easier on you20:30
persianixternal: Multiple options tend to be confusing to contributors, and cause sponsors to only process the ones in the format they understand.20:30
LaserJocksomething like "As opposed to bug fixes and merges, for new upstream releases providing the entire source package is a must. Convenient ways to do so are .."20:30
persianixternal: That doesn't scale for unknown parties.20:30
nixternala lot of my style comes from crimsun since he sponsored a lot of my packages a couple of years ago, and I did it the way he liked it, therefor making it easier for him too20:31
persiaLaserJock: That's precisely the behaviour interdiff was instituted to stop20:31
LaserJockpersia: which I thought was weird20:31
LaserJockthe source package is what I'm sponsoring, not an interdiff20:31
sistpotymaybe we should first think about what needs to be checked for new upstream versions...20:31
sistpoty1) is it applicable in the cycle/in general20:32
persiaLaserJock: I can't reliably reconstruct about 10% of the new upstreams I see in REVU or the sponsors queue.20:32
sistpoty2) are the source not screwed20:32
LaserJockpersia: that's a different problem20:32
sistpoty3) any breakages20:32
sistpotyanything I missed?20:32
persiaLaserJock: Yes, which was solved by interdiffs20:32
LaserJockpersia: but that seems to be the wrong solution to the wrong problem20:32
gesersistpoty: perhaps: 4) did the licensing change?20:33
persiasistpoty:I think that 1) that is different than interdiff vs. diff,gz, 2) we already do that, and 3) it's best left to MOTU judgement20:33
LaserJockbasically a new upstream release should be reviewed similarly to NEW20:33
gesersome upstream are updating their license to GPL3 to debian/copyright needs to be updated too20:33
LaserJockjust not quite a thoroughly20:33
persiaLaserJock: Should it?  We decided in feisty not to have both be the same.20:34
sistpotypersia: so 2) is best solved with interdiff, right? but for 1), 3) and 4) you'll still need manual judgement20:34
LaserJockpersia: perhaps you misunderstand me. I was saying in what we're looking at, not the tools to do so20:34
persiasistpoty: I now believe that 2 is best solved by diff.gz, but yes.20:34
sistpotyhm... *thinking*20:35
persiaLaserJock: Ah.  Yes, but the mechanism and tools influence that to some degree.  I'd not mind just diff.gz for new upstreams, but that's a different issue, and more complicated.20:35
sistpotyhm... just a .diff.gz will mean that the sponsor needs to get the orig-tar in some way, which I guess (w.o. some automation) is an additional burden for the sponsor20:36
LaserJockwell seems like 1) should be done in bug report, 2) a diff.gz or link to .dsc 3-4) ya gotta look at the thing20:37
persiasistpoty: Less burden than for an interdiff though.20:37
ScottKHopefully there's a watch file for that.20:37
sistpotypersia: right20:37
sistpotymaybe I'm missing s.th., but imo apt-get source package and dget newpackage would be the easiest way for a sponsor to achieve all points?20:38
persiasistpoty: And that's the only problem I wished to solve today. https://wiki.ubuntu.com/Spec/ReviewProcessConvergence is the right way to solve 1, 2, and 4.20:38
persiasistpoty: Historically, sponsors haven't done well at checking against upstream.  Lots of repacks that cannot easily be constructed causing difficult merges due to not only variance in md5sum of orig.tar.gz, but variance in contents.20:39
sistpotypersia: so you see 2) as biggest problem to solve?20:40
persiaThe use of interdiff in gutsy and hardy has helped with that a lot, and I didn't see so many of those during the hardy merge cycle.  I think this is because of the tools, rather than because the sponsors are more careful.20:40
LaserJockpersia: that's kind of no so good though, IMO20:41
LaserJockit's putting a band-aid on people not doing the right thing20:41
LaserJockif we're having problems with MOTUs not being careful enough we need to address that20:41
persiasistpoty: I think 3 and 4 are the biggest problems.  I think many people aren't sure about 4, and we need better testing for 3.20:41
sistpotyyeah, it leaves the feeling, that sponsors aren't really checking what they are supposed to do20:41
sistpotyso I guess we fix a different problem (sponsors not checking) with .diff.gz or interdiff, right?20:42
LaserJocka diff.gz at least already has to be created20:42
nixternalis "sponsors aren't really checking what they are supposed to do" the cause of this? is it a problem that we do need to in fact confront and fix?20:43
persiaI'd much rather address it with positive steps to cause the checks, like using interdiff/diff.gz, providing the suspicious-source script, etc. rather than telling people they aren't doing it right.20:43
LaserJockso it's no more effort20:43
LaserJockpersia: but if they aren't ...20:43
LaserJocklike I could totally be doing things wrong and not be aware of it20:43
nixternalya, if they aren't doing it right, I would rather tell them so and have them fix it20:43
LaserJockand I'd hate it if nobody told me20:43
nixternalthat is how it was around here in 2006 for sure...people had no problems doing a /msg and saying "hey, you did this wrong, this is how you do it"20:44
sistpotywell, I won't say that .diff.gz/interdiff isn't a solution to sponsors not checking, though I still have some doubts if we'll be able to manage all new upstream versions with this20:44
persiaWho wants to volunteer to check reproducibility of orig.tar.gz files?20:44
LaserJockso what problem are we trying to fix again?20:44
* sistpoty must admit, that sistpoty always did it by hand, and *always* found it a pity to do so20:45
nixternalheh, it seems we are uncovering other problems trying to find a fix for the original now20:45
persiasistpoty: I've only seen one case where get-orig-source didn't work, and it was a multiverse package with registration required to see the source.  In most cases, a watch file is present, and works.20:45
LaserJockare we having problems with .orig.tar.gz files not being the same as upstream?20:45
persiasistpoty: Agreed.  Part of why I asked for standardisation to interdiff previously was with the intention of creating a script to automate it.  This only changed because diff.gz being easier was explained to me in some detail.20:46
LaserJockI've seen it occasionally, I actually did one myself I hate to admit, but is it a widespread problem?20:46
sistpotypersia: we've had some upstreams package their own software, and that's where I always said "ok, release a good version later" if the orig-tarball wasn't sane20:46
sistpotybut maybe this is a side issue20:46
nixternalI have seen a couple of those recently LaserJock20:46
persiaLaserJock: Yes.  I see lots of those.20:47
LaserJockok, so why aren't people checking the .orig.tar.gz?20:47
nixternalLaserJock: don't feel bad, I just did one recently myself...we are human in a way :p20:47
LaserJockit shouldn't cause too many problems, it's more of a "doh, I can't believe I did that"20:48
persiaLaserJock: lack of concern.  trust of the packager.  Lack of an easy way to do it (especially for repacks), etc.20:48
nixternalLaserJock: could be that some people may not know how to correctly check the .orig.tar.gz for one?20:48
sistpotywell, I've thought about that since a very long time ago, but have never done it: "Reviewing the reviewers" (and giving polite hints)20:48
sistpotymaybe I should finally start that one20:48
LaserJocknixternal: they shouldn't be MOTUs if they can't figure out how to check a .orig.tar.gz20:48
persiasistpoty: I think that would be helpful, but think it is part of https://wiki.ubuntu.com/Spec/ReviewProcessConvergence20:49
LaserJockwell, we shouldn't really be doing many repacks for one thing20:49
nixternalLaserJock: true, but most of the time it is easy to just get lucky and not have any problems with the .orig.tar.gz until that one time20:49
persiaLaserJock: We need to do that in a very large number of cases for tar.bz2, .zip, etc.20:49
LaserJockand if you're gonna upload with an  -sa you should check the .orig.tar.gz if you don't know for sure20:49
persiaLaserJock: Yes, but does everyone?  Automating it seems good to me because 1) it forces the check, and 2) it makes it easier to repack the next upstream for the next person20:50
LaserJockpersia: right, but we shouldn't have to check those all that much20:50
LaserJockpersia: but it's *not* forcing a check20:50
persiaLaserJock: What?  Why not?20:50
persiaErr.  That's why not to both "we shouldn't have to check those all that much" and to "it's not forcing a check"20:51
LaserJockit's just shifting responsibility and making it easier for people who don't do the right thing to get away with it20:51
LaserJockand I don't understand why were doing all this repacking20:51
persiaLaserJock: Because the archive requires tar.gz.  Upstreams don't all provide one.20:52
LaserJockI understand that20:52
LaserJockbut presumably this is being done in Debian20:52
nixternaluupdate -u has been my friend 99.5% of the time with new upstream luckily20:52
persiaRegarding "forcing the check", I only mean checking it matches upstream, so diff.gz really contains all the patches.  Checking the actual code is a different issue.20:52
LaserJockso we should have few occasions to have to check this stuff20:52
sistpotynixternal: for my own packages, I either checked by hand or have upstream commit rights, so I know what's going on *there*20:53
persiaLaserJock: This *never* applies to sources we get from Debian.  This is only new orig.tar.gz files in Ubuntu which are not in Debian.20:53
nixternalsistpoty: ya, I have that advantage with KDE packages, but other packages I don't20:53
LaserJockpersia: then they should be in Debian20:53
LaserJockI don't understand why we're doing so much in Ubuntu when it seems we can't do it well20:54
persiaLaserJock: No.  We already decided to allow REVU, and this isn't the agenda item with which to reverse that decision.20:54
LaserJockbut this directly effects the topic20:54
LaserJockif we keep allowing people to trash our archive and in fact pushing them to do so, then it's gonna cause problems20:55
LaserJockif we aren't willing to clean it up and have MOTUs that can properly review a new upstream tarball then we should have Debian do it20:55
ScottKLaserJock: I don't understand what you're getting at?20:56
persiaI don't consider it to be trashing our archive.  We just need to check to make sure the packages are still clean when they are updated.  Also, we pull a lot of new upstreams ahead of Debian because of our differing release schedule.20:56
sistpotywell, universe was always some kind of testing ground, and I guess it will (and should!) stay so. Admitted, that we've become far more professional than a few release cycles ago20:56
* persia thinks Edgy was a low point for Universe, and it is improving20:57
sistpotyagreed ;)20:57
LaserJockScottK: I'm getting at that most all of this could be "fixed" if people got things into Debian20:57
LaserJockI can't believe we have almost 800 packages in Universe that aren't in Debian20:57
ScottKLaserJock: I agree that'd be better, but that's more of a strategic question and I think we're on tactics here.20:57
nixternalLaserJock: I can agree with that, and that works great sometimes...20:57
LaserJock1/3 of the package we have to maintain are not in Debian20:58
sistpotyLaserJock: universe is (apart from debian) the main source for new good MOTUs and later core-devs. Of course there's fallout, but I wouldn't know how to predict that in advance20:58
persiaLaserJock: That really doesn't help for fly-by-night packagers who push something in, and don't plan to maintain.  Having watch files, using diff.gz, etc. helps to make team maintenance of these easier, if they are considered useful.20:58
nixternalI can believe we have 800 packages in Universe that aren't in Debian...I have had a few ITPs get challenged with a "we have something similar, why is this better"20:58
LaserJockso my thought is that maybe attacking the root of the issue is long-term better for us than putting a band-aid on it20:58
nixternalI can't believe we don't have more actually20:58
* jpatrick just got a universe package of his into Debian20:58
nixternalDebian can be a pita for getting a package into at times20:59
sistpotyLaserJock: but what's the root? and how to fix?20:59
* persia wants both bandaging and long-term care20:59
LaserJockwell, as I see it anyway:20:59
LaserJock1) new packages should be done in Debian when possible20:59
nixternaland for me, when there have been updates upstream, I have filed a bug with Debian that went unanswered for some time, or attempting direct communications toward the Debian maintainer went unanswered21:00
persianixternal: Right, which can get very painful as we approach feature freeze.21:00
nixternaleven sent diffs and the whole ball of wax21:00
LaserJock2) if MOTUs aren't keeping up QA standards then we need education, review, and a helpful hand21:00
nixternalLaserJock: I can't agree more with both of your points actually, especially #1 even considering how difficult it can be21:01
LaserJocknow, I agree with persia that both bandaging and long-term care sounds good21:01
sistpoty1) call me the exception, but it took some time... finally all my packages are in debian21:01
sistpoty2) fully agreed21:01
* ScottK has all his packages in Debian too.21:01
LaserJocknixternal: I think it can be much easier to get packages into Debian than into Ubuntu21:01
* nixternal has about 90% now in Debian21:01
nixternalLaserJock: well, Ubuntu doesn't ask "what makes this better than package x which is similar?"21:02
nixternalDebian does, and they stick to it21:02
sistpotyLaserJock: w.o. getting (my first) pet package of me into ubuntu in a few weeks, I doubt that I would have stayed as a ubuntu maintainer21:02
LaserJocknixternal: it should, and it should be easy to answer that question21:02
Lamegoselecting between  open source projects an easy answer ?21:03
LaserJockI kinda feel like people view Universe as a crutch so they don't have to get stuff in Debian21:03
persiaI don't think Ubuntu should be asking that question.  I prefer competition in universe as the best means to find ideal solutions.  The one-best-solution thing is tricky.21:03
LaserJockhah, like Debian doesn't have competition?21:04
nixternalI am with persia on that one21:04
LaserJockthey just don't want people just packaging for packaging's sake21:04
LaserJockthey want something that's gonna be maintained, as we should21:04
nixternalLaserJock: Debian does, but with them denying ITPs or RFPs just because something similar is already in their repos, that doesn't breed competition imo21:04
sistpotywell, I agree to persia, though we don't really have a way find the results of the competition when it comes to orphaned packages21:04
persiaLaserJock: Rather, they enforce that rule as a way to reduce packaging random cruft as a path to DD without integration with the rest of the distro.21:05
LaserJocknixternal: you just ask somebody else21:05
nixternalLaserJock: hahaha, that has worked for me, but someone new who hasn't been around long, it isn't going to work21:05
persiasistpoty: That's a different problem (and a much harder one).21:05
sistpotyLaserJock: I guess your statement right now is closest to what I see the root of the problem: "packaging for packaging's sake"21:05
LaserJockI would be rather surprised if Debian just out-and-out rejected a package you plan to maintain21:06
sistpotypersia: which I hope we'll be tackling rather sooner than later ;)21:06
nixternalman, we are getting to the point of "where we need stats, solid stats", yet have no way to really produce them (ScottK, sound familiar from say, 2 hours ago?)21:06
persiaI think the solution to that is to work on the wiki, and point new people to bugfixing and patching.  merges, new upstreams, and REVU aren't the right things to be doing, and pushing the "packaging guide" doesn't help.21:06
LaserJockanyway, perhaps we should get the particular agenda item resolved?21:06
ScottKThere's an agenda item?21:07
LaserJockpersia: redoing the packaging guide, IMO, would be a good idea to make it more friendly to bug fixing and patching21:07
nixternalScottK: don't you remember, you filled in for persia's topic because he was afk? :)21:07
LaserJockso votes on interdiff or diff.gz?21:07
nixternalOK, what was the reasoning for that again? :p21:07
* ScottK has had a nap in the meantime.21:08
nixternalbeen a while since we talked about them21:08
* persia proposes "Request diff.gz in preference to interdiff when receiving new upstreams for review" as the subject for a vote.21:08
* sistpoty still prefers dgettable urls21:08
sistpoty(attached to the bug report)21:08
* nixternal thinks all of this talk is making for a good recipe honestly21:08
nixternaland not of the cooking variety21:09
LaserJocksistpoty: well, a diff.gz is pretty close21:09
persiasistpoty: hardy ubuntu-dev-tools will have a script to make it easy based on the decision in this meeting.21:09
nixternalshould I go ahead and call the vote then for this with MootBot?21:09
LaserJocksistpoty: the only additional thing is that the sponsor has to do is get the .orig.tar.gz21:09
sistpotyok, go ahead with the vote21:09
nixternal[VOTE] Request a diff.gz in preference to interdiff when receiving new upstreams for review?21:10
MootBotPlease vote on:  Request a diff.gz in preference to interdiff when receiving new upstreams for review?.21:10
MootBotPublic votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot21:10
MootBotE.g. /msg MootBot +1 #ubuntu-meeting21:10
* persia requests people to vote based on interdiff vs. diff.gz, rather than on the larger issues21:10
MootBot+1 received from persia. 1 for, 0 against. 0 have abstained. Count is now 121:10
MootBot+1 received from nixternal. 2 for, 0 against. 0 have abstained. Count is now 221:10
MootBot+1 received from sistpoty. 3 for, 0 against. 0 have abstained. Count is now 321:10
MootBot+1 received from LaserJock. 4 for, 0 against. 0 have abstained. Count is now 421:10
MootBot+1 received from RainCT. 5 for, 0 against. 0 have abstained. Count is now 521:10
LaserJockwow, I've never seen that before21:11
LaserJockwhen did we get this?21:11
sistpotyLaserJock: MootBot?21:11
nixternalhe has been here for a while, jsut not many people use him?21:11
persiaOctober or so21:11
nixternalany other voters?21:11
LaserJockoh, I see21:11
MootBot+1 received from ScottK. 6 for, 0 against. 0 have abstained. Count is now 621:11
nixternalderr, I can't believe I did that again21:12
MootBotFinal result is 6 for, 0 against. 0 abstained. Total: 621:12
nixternalthey need to update the wiki page :)21:12
sistpotythat's why /me likes votes... long discussion, but short vote *g*21:12
LaserJockthere's a wiki page?21:12
nixternalLaserJock: it is part of the Scribes Team21:12
* LaserJock wonders where he's been21:12
persiaLaserJock: https://wiki.ubuntu.com/ScribesTeam/MootBot21:12
nixternalis that all for today?21:12
LaserJockI vaguely remember something about there being a scribes team21:13
sistpotynixternal: fixed points are still left (next meeting time)21:13
nixternaloh ya21:13
* persia proposes 15th February, 12:00 UTC21:13
nixternal[TOPIC] Next meeting time21:13
MootBotNew Topic:  Next meeting time21:13
nixternal[IDEA] persia proposes 15th February @ 12:00 UTC21:14
MootBotIDEA received:  persia proposes 15th February @ 12:00 UTC21:14
sistpotyok with me21:15
nixternalthat is a bit early :)21:15
nixternal06:00 here21:15
ScottKHow about 13 UTC?21:15
nixternalbut I don't need to be here, so if it works for everyone else21:15
persianixternal: Yes, but it's currently 06:15 here :)21:15
sistpotynixternal: that's a bad starting attitude for a new MC member :P21:15
persiaScottK: conflict with MOTU Q&A session21:16
nixternalI don't want to be the 1 stinker among the many21:16
nixternalif I have to wake up early, I guess I will need to start working on that21:16
nixternalyou are taking the freedom loving hippy out of me though :p21:16
ScottKFor me that's right in the middle of getting the kids out the door for school time, so it's essentially impossible21:17
sistpotyany other proposals?21:17
persia13:00 UTC is also 0:00 in Sydney.  Maybe 11:00 UTC?21:17
nixternal06:00 UTC :) that is midnight for me :) and lord knows I am still awake at that time21:18
* sistpoty will be eating lunch then, but sistpoty wouldn't be able to be fully present during work time anyway21:18
persiaI can't get to much earlier than 10:00 UTC, but I've attended lots of meetings: I can miss one if required.21:19
nixternalI think we need a list showing everyone's best times for a meeting...like we used to do with the doc team a couple of years ago when we had meetings :)21:19
sistpotynixternal: that would cause the scheduler to segfault, due to no options *g*21:20
nixternalwe had a nice wiki page that listed each member and their best times for being available21:20
sistpotylet's just vote... candidates so far are 11 UTC and 12 UTC, right?21:21
persiaWe've been rotating between 20:00 and 12:00 for a while.  We could change that, but I'm afraid of going back to the old scheduling discussions which sometimes caused 6 weeks to pass without a meeting.21:21
persiasistpoty: 13:00 was also proposed (by ScottK)21:21
sistpotypersia: but has conflicts in #meeting... but nixternal also proposed 6 UTC21:21
nixternalno, I was kind of joking on that one because that would be way to early for others more than likely21:22
persiaWait, conflicts in #meeting?  resolvable conflict in #classroom21:22
LaserJockwe should just rotate 4 hrs each time21:22
sistpotypersia: oh, sorry, so that's an option too21:22
* persia prefers 8 hour rotation21:23
sistpotyso at 28UTC *g*21:23
persiaWorks for me: scheduling is more flexible on the weekend.21:23
LaserJockpersia: yeah, that works21:23
persiaLaserJock: So you want to propose 04:00 UTC?21:24
nixternalthat might be past his bed time though :)21:24
LaserJockI don't care what it is21:24
LaserJockbut I think it'd be nice to establish some sort of schedule21:25
sistpotylet's just vote, shall we?21:25
nixternaldo we have 3 times in which to vote for? what times are we looking at right now?21:25
persiasistpoty: We can only vote on binary conditions.  Lots of votes maybe?21:25
sistpotypersia: it could be a non-mootbot vote ;)21:26
nixternalif we have 3, we can still use MootBot to count it for us, use +1 for one time, -1 for another, and +0 for another21:26
nixternallist the 3 times and I will put it to action21:26
sistpotyso we have 4 utc, 12 utc and...?21:27
sistpoty11 or 13?21:27
sistpotyif noone is against, I'd say 11 as 3rd option (qa-conflict)21:28
LaserJock4,12, and 20 I think are generally good21:28
sistpotythen what LaserJock wrote ;)21:28
nixternal[VOTE] Next meeting time: Vote +1 for 04:00 UTC, -1 for 12:00 UTC, +0 for 20:00 UTC21:28
MootBotPlease vote on:  Next meeting time: Vote +1 for 04:00 UTC, -1 for 12:00 UTC, +0 for 20:00 UTC.21:28
MootBotPublic votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot21:28
MootBotE.g. /msg MootBot +1 #ubuntu-meeting21:28
nixternaldamn, there are 2 good ones for me now :)21:28
MootBot-1 received from persia. 0 for, 1 against. 0 have abstained. Count is now -121:28
sistpoty-1 | +021:29
MootBot-1 received from sistpoty. 0 for, 2 against. 0 have abstained. Count is now -221:29
MootBot+1 received from LaserJock. 1 for, 2 against. 0 have abstained. Count is now -121:29
MootBot+1 received from nixternal. 2 for, 2 against. 0 have abstained. Count is now 021:29
MootBotAbstention received from RainCT. 2 for, 2 against. 1 have abstained. Count is now 021:29
nixternalyou can only vote once :)21:29
sistpotydamn, I can't recast21:29
persiasistpoty: No double voting :p21:30
nixternalonly the city of Chicago can double vote, or vote for dead people21:30
LaserJocknixternal:  Vegas is pretty good at that too21:30
=== ubotu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 13 Feb 22:30 UTC: Forum Council | 20 Feb 01:00 UTC: TriLoCo-Midwest
MootBot-1 received from ScottK. 2 for, 3 against. 1 have abstained. Count is now -121:30
MootBot+1 received from superm1. 3 for, 3 against. 1 have abstained. Count is now 021:31
nixternalcome on geser, be the tie breaker :)21:31
txwikingerthe dead people can vote as often as they want in Chaicago21:31
gesernixternal: reading the scrollback as my DSL-line comes and goes today, one moment21:32
persiaRegardless of the vote, based on the interest in 04:00 UTC, I think we should choose that time, as we haven't had a 04:00 UTC meeting in months, while the other two have had heavy attendance.21:32
nixternalno problem21:32
sistpoty*drum rolling for geser*21:32
MootBotAbstention received from geser. 3 for, 3 against. 2 have abstained. Count is now 021:32
* sistpoty starts to not like votes any longer *g*21:32
nixternalhaha, I am with you on that one21:32
LaserJockit's looking good though21:32
geserat the other times I'm either sleeping or at work with no IRC21:33
LaserJockit means we have interest in all 3 times21:33
nixternalrock, paper, scissors?21:33
sistpotyI'd agree with persia though21:33
MootBotFinal result is 3 for, 3 against. 2 abstained. Total: 021:33
persiaActually, let's just institute a standard rotation of 04:00, 12:00, 20:00, 04:00...21:34
nixternalpersia: are you up and breathing MOTU at 04:00 UTC?21:34
persianixternal: Sometimes.  Depends on the client.21:34
LaserJockpersia: that's what I was trying to say21:34
persia(it's lunchtime here)21:34
sistpotypersia: sounds sane, given the long discussion time for only the next meeting time21:34
nixternal[VOTE] Meeting rotation schedule or 04:00 UTC, 12:00 UTC, and 20:00 UTC21:34
MootBotPlease vote on:  Meeting rotation schedule or 04:00 UTC, 12:00 UTC, and 20:00 UTC.21:34
MootBotPublic votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot21:34
MootBotE.g. /msg MootBot +1 #ubuntu-meeting21:34
MootBot+1 received from nixternal. 1 for, 0 against. 0 have abstained. Count is now 121:34
MootBot+1 received from sistpoty. 2 for, 0 against. 0 have abstained. Count is now 221:34
MootBot+1 received from superm1. 3 for, 0 against. 0 have abstained. Count is now 321:35
MootBot+1 received from LaserJock. 4 for, 0 against. 0 have abstained. Count is now 421:35
nixternalthis is looking good21:35
persia+1 with a note that 28;00 UTC becomes 04:00 UTC so it always happens on Friday UTC.21:35
geserare the enough people for a meeting at 04:00 UTC? /me remebers meetings at 00:00 UTC where nearly nobody was there21:35
MootBot+1 received from persia. 5 for, 0 against. 0 have abstained. Count is now 521:35
MootBot+1 received from geser. 6 for, 0 against. 0 have abstained. Count is now 621:35
geserwe can try it if it works out21:35
persiageser: This is the first time I've seen lots of votes for 04:00 UTC, but as we get more interest from the Americas, it should see more activity.21:35
nixternalRainCT or ScottK?21:36
nixternalglad I can spell in the vote topic, s/or/for21:36
LaserJockyeah, that's 8pm for me21:36
nixternaladd a plus to it21:37
MootBotAbstention received from ScottK. 6 for, 0 against. 1 have abstained. Count is now 621:37
MootBotAbstention received from RainCT. 6 for, 0 against. 2 have abstained. Count is now 621:38
MootBotFinal result is 6 for, 0 against. 2 abstained. Total: 621:38
LaserJockso was the first agenda item discussed? renaming motu-uvf?21:38
sistpotyLaserJock: yes21:38
persiaLaserJock: http://irclogs.ubuntu.com/2008/02/01/%23ubuntu-meeting.html21:38
nixternalit will be named motu-release per vote21:38
sistpotywohoo we've found the date for the next meeting :)21:38
superm1was there a vote for who is on motu-release then too?21:38
nixternal[AGREED] Next meeting will be 04:00 UTC21:38
superm1or is that next meeting?21:38
MootBotAGREED received:  Next meeting will be 04:00 UTC21:38
persiasuperm1: There's a call for candidates: polls will probably be set up Monday.21:39
sistpotysuperm1: no, that'll be on LP iirc21:39
superm1ah okay21:39
nixternalso now is the meeting ok to be adjourned?21:39
MootBotMeeting finished at 21:39.21:39
persiaDo we know who is doing minutes and announcements?21:39
nixternalw00t, good meeting21:39
sistpotybig thanks for hosting, nixternal21:39
nixternalpersia: minutes should be done by the scribes team21:40
sistpotyand thanks for everyone around :)21:40
nixternalI will look into that21:40
persianixternal: They don't.21:40
nixternalyes, thanks everyone!21:40
persiaAnyone, about announcements?21:40
nixternalpersia: OK, then I will scribe them out21:40
* sistpoty would volunteer for announcements21:40
nixternalgroovy...I am looking into this MootBot thing now21:41
nixternalnice layout21:42
persianixternal: The times are links to the full log too, making it easy :)21:43
=== ubotu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 13 Feb 22:30 UTC: Forum Council | 15 Feb 04:00 UTC: MOTU | 20 Feb 01:00 UTC: TriLoCo-Midwest

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!