Started logging meeting in #ubuntu-meeting
[20:04:29] <nixternal> [TOPIC] Rename motu-uvf - ScottK
[20:04:48] <nixternal> go ahead ScottK, the floor is yours
[20:05:04] <ScottK> OK.
[20:05:20] <ScottK> Clearly since we no longer have uvf, we need a new name.
[20:05:56] <ScottK> motu-ff, motu-release, motu-freeze have been suggested so far
[20:06:15] <ScottK> Any preferences from anyone?
[20:06:26] <nixternal> [IDEA]Clearly since we no longer have uvf, we need a new name.
[20:06:41] <nixternal> [IDEA] motu-ff, motu-release, motu-freeze have been suggested so far
[20:07:00] * sistpoty thinks that motu-release would also shift the purpose of the team
[20:07:03] <DktrKranz> I'd say motu-release, just for mere assonance with ubuntu-release
[20:07:08] <nixternal> well, since uvf is no longer around, then obvious a name change would probably make the teams goals a tad bit clearer
[20:07:18] <ScottK> Well sistpoty brings up an interesting question.
[20:07:35] <geser> but wouldn't people expect from motu-release more than it really is?
[20:07:38] <ScottK> For Gutsy, motu-uvf was active helping manage things up through release.
[20:07:58] <ScottK> No one complained and I think it helped a lot with a good end game for Universe.
[20:07:59] * RainCT says hi. sorry, just remembered about the meeting.
[20:08:08] <nixternal> I thought motu-freeze sounded kind of cool and actually gets its point across a bit
[20:09:02] <ScottK> I'm good with either motu-freeze or motu-release.
[20:09:14] <ScottK> FF is the first step in release management for Universe.
[20:09:23] <sistpoty> ScottK: so you think that (the team formerly known as) motu-uvf should in fact care with release matters?
[20:09:35] <ScottK> sistpoty: I do.
[20:09:44] <ScottK> sistpoty: We did it for Gutsy and it worked well.
[20:10:03] <sistpoty> hm... I guess the goals are quite similar in fact
[20:10:18] <sistpoty> (for a release team and handling uvf-requests)
[20:10:44] <ScottK> It's really the same kind of risk/benifit tradeoff, just with different focus as the release gets closer.
[20:10:51] <nixternal> or what was formally called uvf-requests I guess
[20:10:53] <sistpoty> so I don't have any objections to motu-release
[20:11:26] <ScottK> Any objections to that?
[20:11:45] * RainCT likes it
[20:11:46] <nixternal> should we take a vote on motu-release? if so I will set MootBot to record the votes
[20:12:13] * sistpoty likes votes
[20:12:19] <ScottK> nixternal: We can if you want, but no one objected.
[20:12:22] <nixternal> [VOTE] Do we change the name of motu-uvf to motu-release?
[20:12:27] <nixternal> +1
[20:12:28] <ScottK> +1
[20:12:28] <sistpoty> +1
[20:12:31] <RainCT> +1
[20:12:44] <DktrKranz> +1
[20:12:56] <nixternal> is that everyone?
[20:13:09] <superm1> +1
[20:13:31] <nixternal> #endvote
[20:13:57] <nixternal> any day now bot
[20:14:23] <ScottK> [ENDVOTE]
[20:14:31] <nixternal> #endvote
[20:14:45] <sistpoty> he, I guess you dislike votes from now, nixternal? *g*
[20:14:59] <nixternal> it seems he likes to hang when ending a vote, possibly because he can't do simple addition :)
[20:15:07] <DktrKranz> mh, probably when an new topic is set, endvote is called
[20:15:10] <geser> nixternal: simply change the topic and mootbot will close the vote
[20:15:17] <sistpoty> nixternal: write what ScottK proposed
[20:15:40] <nixternal> [AGREED] motu-uvf to become motu-release
[20:15:58] <nixternal> [TOPIC] Moving on...
[20:16:02] <nixternal> there you go
[20:16:23] <nixternal> since persia isn't around to talk about his topic, does anyone else have anything to add?
[20:16:24] <ScottK> I'll speak on persia's topic since he's not hear.
[20:16:30] <ScottK> hear/here
[20:16:31] <nixternal> ok...let me set that one up
[20:17:02] <nixternal> [TOPIC] Switch from Interdiff to diff.gz for new upstream candiadtes (EmmetHikory) - covered by ScottK
[20:17:03] * sistpoty is glad to not have to fight with MootBot this time... once was enough *g*
[20:17:08] <nixternal> lol
[20:17:21] <nixternal> I was mdz fight with it too, you would think I would have learned :)
[20:17:29] <nixternal> err, s/was/watch
[20:17:29] <ScottK> persia put forward the idea of using interdiff and we tried it.
[20:17:31] <sistpoty> hehe
[20:17:40] <ScottK> It's a good idea in theory, but a real PITA in practice.
[20:17:51] <nixternal> true
[20:18:16] <ScottK> I think we've discussed enough that a .diff.gz is sufficient in almost all cases and easier to both understand and create.
[20:18:41] <ScottK> So the question is do we stick with interdiff, switch to .diff.gz, or handle upgrade some other way.
[20:19:16] <ScottK> The key point, I think, is the sponsor should fetch the tar.gz themselves and be able to easily review the proposed package.
[20:19:18] <nixternal> .diff.gz is easier in practice than the interdiff, at least it proved that way for me
[20:19:21] <ScottK> Comments?
[20:19:22] * sistpoty hasn't tried interdiff yet, so sistpoty doesn't have a real opinion
[20:19:50] <nixternal> I did a couple of interdiffs, and each time I kept reading the wiki...
[20:20:08] <LaserJock> did I miss it?
[20:20:11] <ScottK> Anyone like interdiff?
[20:20:12] * RainCT tried sponsoring an interdiff but couldn't achieve to get the source, even following the wiki :(
[20:20:24] <nixternal> RainCT: ya, me either
[20:20:34] <ScottK> LaserJock: We're just discussing switching from interdiff to diff.gz for upgrade bug sponsoring.
[20:20:40] <LaserJock> ah
[20:20:47] * txwikinger does not understand why interdiff is advantegeous over just taking the new orig and diff
[20:21:00] <DktrKranz> with .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 it
[20:21:01] <nixternal> what happened with using debdiff?
[20:21:14] <LaserJock> I couldn't care less what people use as long as they give me something I can use
[20:21:23] <ScottK> nixternal: Debdiff for a new upstream would include all the upstream changes too.
[20:21:26] <nixternal> heh, I am actually the same as LaserJock
[20:21:39] <LaserJock> I'm not sure why we are actually having this discussion
[20:21:46] <nixternal> ScottK: gotcha, and we are trying to limit to just ubuntu/debian changes then
[20:21:52] <superm1> i'd be for just having diff's of the debian directory
[20:22:10] <superm1> have them extract both and just run diff across the two directories and attach that to a bug
[20:22:12] <ScottK> LaserJock: Because the agreement is we don't change process/policy unless agreed at a MOTU meeting.
[20:22:12] <sistpoty> superm1: that would exclude packages not using a patch system
[20:22:23] <superm1> sistpoty, ah yeah.
[20:22:26] <LaserJock> ScottK: my point is why is this policy? it seems petty and silly
[20:22:50] <ScottK> LaserJock: Because there was a meeting and it was decided.
[20:22:56] * ScottK wasn't at the meeting.
[20:23:12] <LaserJock> me neither, so I guess I should just shut up
[20:23:13] <LaserJock> ;-)
[20:23:16] <nixternal> It does seem that way, but I understand the wanting of common process
[20:23:18] * sistpoty thought back then to give it a try
[20:23:35] <nixternal> otherwise trying to teach future MOTUs the availability of 10 different processes can be a pita at times
[20:23:56] <LaserJock> "get us the source package, we don't care how" doesn't seem to be all that bad
[20:24:00] <nixternal> but providing them choice is good imho, as it will allow them to follow a practice that suits their style possibly
[20:24:51] <sistpoty> though I'm not active in sponsoring, what speaks against a link to a dsc attached to the bug report?
[20:25:10] <nixternal> sistpoty: not everyone has a place to store the .dsc and the rest of the files
[20:25:24] <LaserJock> there's revu if they don't
[20:25:26] <sistpoty> nixternal: revu can store dsc's, so I guess everyone has
[20:25:27] <nixternal> I believe that was the argument heard when I thought of a similar idea a while back
[20:25:35] <LaserJock> and if they aren't that big LP would be fine
[20:25:35] <superm1> everyone can use revu or ppa to store them
[20:25:40] <nixternal> also people can link us to their PPA
[20:25:56] * ScottK very much dislikes PPA for this due to versioning issues
[20:26:04] <superm1> well you can delete stuff in PPAs now
[20:26:05] <sistpoty> LaserJock: no, LP (as in attachments) will screw the names, but PPAs are an alternative
[20:26:09] <DktrKranz> Having .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:10] <superm1> so you can use proper versioning if you want
[20:26:12] <sistpoty> links even
[20:26:17] <ScottK> Sponsoree should propose exactly what they want uploaded, not with PPA versioning.
[20:26:21] <LaserJock> sistpoty: screw what names?
[20:26:27] <sistpoty> LaserJock: link names
[20:26:33] <sistpoty> LaserJock: as in you can't dget
[20:26:39] <nixternal> ahh, good point
[20:26:42] <LaserJock> sistpoty: oh well
[20:26:44] <RainCT> sistpoty: there's dgetlp in ubuntu-dev-tools
[20:26:52] <nixternal> it will give them that 0034802934408202__48389W.dsc garbage
[20:27:05] * sistpoty would rather have a straight dget... but with PPAs that is possible
[20:27:07] <nixternal> perfect timing persia :)
[20:27:16] <nixternal> we are covering your topic right now, care to add?
[20:27:17] <ScottK> Actually I think they fixed LP to have dget work with it now.
[20:27:18] <sistpoty> hi persia
[20:27:27] <sistpoty> ScottK: cool
[20:27:28] * persia apologises for being late
[20:27:28] * ScottK hands the gavel to persia.
[20:27:31] <LaserJock> I just don't think we need a strict policy for this, but I'd prefer diff.gz over interdiff
[20:27:47] <nixternal> I would as well
[20:28:00] <geser> ScottK: does it also work for attached packages or only for published packages?
[20:28:00] * sistpoty would just like to have anything dget'able linked in the bugreport
[20:28:05] <persia> It's not about policy, it's more about standard recommendations to newcomers, and expected processing by sponsors.
[20:28:28] <nixternal> persia: thanks for clarifying that
[20:28:32] <persia> sistpoty: That's inherently error-prone, as it doesn't force the use of upstream sources.
[20:28:34] <LaserJock> persia: but that institutes policy and creates punishment for not doing so
[20:28:49] <persia> LaserJock: True.
[20:28:53] <LaserJock> "no I won't sponsor your package because you didn't format it the way I want it"
[20:28:54] <sistpoty> persia: that would always need checking, right
[20:29:23] <sistpoty> (note, that I'm not favourable to "must have" get-orig-source or similar
[20:29:25] <sistpoty> +)
[20:29:26] <persia> sistpoty: It's not been historically checked well using dget and REVU or third-party websites.
[20:29:49] <nixternal> so 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:30:22] <sistpoty> oh, 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 version
[20:30:27] <nixternal> in 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 you
[20:30:35] <persia> nixternal: Multiple options tend to be confusing to contributors, and cause sponsors to only process the ones in the format they understand.
[20:30:36] <LaserJock> something 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:56] <persia> nixternal: That doesn't scale for unknown parties.
[20:31:00] <nixternal> a 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 too
[20:31:11] <sistpoty> heh
[20:31:15] <persia> LaserJock: That's precisely the behaviour interdiff was instituted to stop
[20:31:30] <LaserJock> persia: which I thought was weird
[20:31:50] <LaserJock> the source package is what I'm sponsoring, not an interdiff
[20:31:58] <sistpoty> maybe we should first think about what needs to be checked for new upstream versions...
[20:32:06] <sistpoty> 1) is it applicable in the cycle/in general
[20:32:08] <persia> LaserJock: I can't reliably reconstruct about 10% of the new upstreams I see in REVU or the sponsors queue.
[20:32:14] <sistpoty> 2) are the source not screwed
[20:32:19] <LaserJock> persia: that's a different problem
[20:32:21] <sistpoty> 3) any breakages
[20:32:22] <LaserJock> IMO
[20:32:28] <sistpoty> anything I missed?
[20:32:33] <persia> LaserJock: Yes, which was solved by interdiffs
[20:32:55] <LaserJock> persia: but that seems to be the wrong solution to the wrong problem
[20:33:05] <geser> sistpoty: perhaps: 4) did the licensing change?
[20:33:13] <sistpoty> right
[20:33:31] <persia> sistpoty: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 judgement
[20:33:38] <LaserJock> basically a new upstream release should be reviewed similarly to NEW
[20:33:49] <geser> some upstream are updating their license to GPL3 to debian/copyright needs to be updated too
[20:33:59] <LaserJock> just not quite a thoroughly
[20:34:10] <persia> LaserJock: Should it? We decided in feisty not to have both be the same.
[20:34:25] <sistpoty> persia: so 2) is best solved with interdiff, right? but for 1), 3) and 4) you'll still need manual judgement
[20:34:46] <LaserJock> persia: perhaps you misunderstand me. I was saying in what we're looking at, not the tools to do so
[20:34:49] <persia> sistpoty: I now believe that 2 is best solved by diff.gz, but yes.
[20:35:03] <sistpoty> hm... *thinking*
[20:35:49] <persia> LaserJock: 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:36:16] <LaserJock> k
[20:36:51] <sistpoty> hm... 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 sponsor
[20:37:05] <LaserJock> well seems like 1) should be done in bug report, 2) a diff.gz or link to .dsc 3-4) ya gotta look at the thing
[20:37:07] <persia> sistpoty: Less burden than for an interdiff though.
[20:37:14] <ScottK> Hopefully there's a watch file for that.
[20:37:17] <sistpoty> persia: right
[20:38:31] <sistpoty> maybe 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:44] <persia> sistpoty: 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:39:43] <persia> sistpoty: 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:40:36] <sistpoty> persia: so you see 2) as biggest problem to solve?
[20:40:46] <persia> The 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:41:00] <sistpoty> ok
[20:41:09] <LaserJock> persia: that's kind of no so good though, IMO
[20:41:21] <LaserJock> it's putting a band-aid on people not doing the right thing
[20:41:47] <LaserJock> if we're having problems with MOTUs not being careful enough we need to address that
[20:41:47] <persia> sistpoty: 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:48] <sistpoty> yeah, it leaves the feeling, that sponsors aren't really checking what they are supposed to do
[20:42:49] <sistpoty> so I guess we fix a different problem (sponsors not checking) with .diff.gz or interdiff, right?
[20:42:54] <LaserJock> a diff.gz at least already has to be created
[20:43:03] <nixternal> is "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:07] <persia> I'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:08] <LaserJock> so it's no more effort
[20:43:24] <LaserJock> persia: but if they aren't ...
[20:43:39] <LaserJock> like I could totally be doing things wrong and not be aware of it
[20:43:39] <nixternal> ya, if they aren't doing it right, I would rather tell them so and have them fix it
[20:43:46] <LaserJock> and I'd hate it if nobody told me
[20:44:09] <nixternal> that 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:10] <sistpoty> well, 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 this
[20:44:15] <persia> Who wants to volunteer to check reproducibility of orig.tar.gz files?
[20:44:50] <LaserJock> so what problem are we trying to fix again?
[20:45:04] * sistpoty must admit, that sistpoty always did it by hand, and *always* found it a pity to do so
[20:45:13] <nixternal> heh, it seems we are uncovering other problems trying to find a fix for the original now
[20:45:14] <persia> sistpoty: 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:56] <LaserJock> are we having problems with .orig.tar.gz files not being the same as upstream?
[20:46:44] <LaserJock> I've seen it occasionally, I actually did one myself I hate to admit, but is it a widespread problem?
[20:46:46] <sistpoty> persia: 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 sane
[20:46:48] <persia> sistpoty: 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:51] <sistpoty> but maybe this is a side issue
[20:46:58] <nixternal> I have seen a couple of those recently LaserJock
[20:47:10] <persia> LaserJock: Yes. I see lots of those.
[20:47:20] <LaserJock> ok, so why aren't people checking the .orig.tar.gz?
[20:47:37] <nixternal> LaserJock: don't feel bad, I just did one recently myself...we are human in a way :p
[20:48:02] <LaserJock> it shouldn't cause too many problems, it's more of a "doh, I can't believe I did that"
[20:48:09] <persia> LaserJock: lack of concern. trust of the packager. Lack of an easy way to do it (especially for repacks), etc.
[20:48:10] <nixternal> LaserJock: could be that some people may not know how to correctly check the .orig.tar.gz for one?
[20:48:29] <sistpoty> well, 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:36] <sistpoty> maybe I should finally start that one
[20:48:39] <LaserJock> nixternal: they shouldn't be MOTUs if they can't figure out how to check a .orig.tar.gz
[20:49:00] <persia> sistpoty: I think that would be helpful, but think it is part of https://wiki.ubuntu.com/Spec/ReviewProcessConvergence
[20:49:18] <LaserJock> well, we shouldn't really be doing many repacks for one thing
[20:49:31] <nixternal> LaserJock: 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 time
[20:49:49] <persia> LaserJock: We need to do that in a very large number of cases for tar.bz2, .zip, etc.
[20:49:56] <LaserJock> and if you're gonna upload with an -sa you should check the .orig.tar.gz if you don't know for sure
[20:50:37] <persia> LaserJock: 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 person
[20:50:41] <LaserJock> persia: right, but we shouldn't have to check those all that much
[20:50:50] <LaserJock> persia: but it's *not* forcing a check
[20:50:52] <persia> LaserJock: What? Why not?
[20:51:21] <persia> Err. 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:23] <LaserJock> it's just shifting responsibility and making it easier for people who don't do the right thing to get away with it
[20:51:54] <LaserJock> and I don't understand why were doing all this repacking
[20:52:11] <persia> LaserJock: Because the archive requires tar.gz. Upstreams don't all provide one.
[20:52:23] <LaserJock> I understand that
[20:52:33] <LaserJock> but presumably this is being done in Debian
[20:52:38] <nixternal> uupdate -u has been my friend 99.5% of the time with new upstream luckily
[20:52:51] <persia> Regarding "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:52] <LaserJock> so we should have few occasions to have to check this stuff
[20:53:16] <sistpoty> nixternal: for my own packages, I either checked by hand or have upstream commit rights, so I know what's going on *there*
[20:53:30] <persia> LaserJock: 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:38] <nixternal> sistpoty: ya, I have that advantage with KDE packages, but other packages I don't
[20:53:45] <LaserJock> persia: then they should be in Debian
[20:53:57] <sistpoty> hehe
[20:54:02] <LaserJock> I don't understand why we're doing so much in Ubuntu when it seems we can't do it well
[20:54:17] <persia> LaserJock: No. We already decided to allow REVU, and this isn't the agenda item with which to reverse that decision.
[20:54:54] <LaserJock> but this directly effects the topic
[20:55:23] <LaserJock> if we keep allowing people to trash our archive and in fact pushing them to do so, then it's gonna cause problems
[20:55:52] <LaserJock> if 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 it
[20:56:04] <ScottK> LaserJock: I don't understand what you're getting at?
[20:56:18] <persia> I 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:38] <sistpoty> well, 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 ago
[20:57:03] * persia thinks Edgy was a low point for Universe, and it is improving
[20:57:12] <sistpoty> agreed ;)
[20:57:18] <LaserJock> ScottK: I'm getting at that most all of this could be "fixed" if people got things into Debian
[20:57:45] <LaserJock> I can't believe we have almost 800 packages in Universe that aren't in Debian
[20:57:49] <ScottK> LaserJock: I agree that'd be better, but that's more of a strategic question and I think we're on tactics here.
[20:57:53] <nixternal> LaserJock: I can agree with that, and that works great sometimes...
[20:58:03] <LaserJock> 1/3 of the package we have to maintain are not in Debian
[20:58:25] <sistpoty> LaserJock: 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 advance
[20:58:26] <persia> LaserJock: 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:30] <nixternal> I 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:40] <LaserJock> so my thought is that maybe attacking the root of the issue is long-term better for us than putting a band-aid on it
[20:58:42] <nixternal> I can't believe we don't have more actually
[20:58:57] * jpatrick just got a universe package of his into Debian
[20:59:20] <nixternal> Debian can be a pita for getting a package into at times
[20:59:25] <sistpoty> LaserJock: but what's the root? and how to fix?
[20:59:30] * persia wants both bandaging and long-term care
[20:59:39] <LaserJock> well, as I see it anyway:
[20:59:58] <LaserJock> 1) new packages should be done in Debian when possible
[21:00:00] <nixternal> and 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 unanswered
[21:00:24] <persia> nixternal: Right, which can get very painful as we approach feature freeze.
[21:00:25] <nixternal> even sent diffs and the whole ball of wax
[21:00:26] <LaserJock> 2) if MOTUs aren't keeping up QA standards then we need education, review, and a helpful hand
[21:01:10] <nixternal> LaserJock: I can't agree more with both of your points actually, especially #1 even considering how difficult it can be
[21:01:17] <LaserJock> now, I agree with persia that both bandaging and long-term care sounds good
[21:01:18] <sistpoty> 1) call me the exception, but it took some time... finally all my packages are in debian
[21:01:26] <sistpoty> 2) fully agreed
[21:01:30] * ScottK has all his packages in Debian too.
[21:01:37] <LaserJock> nixternal: I think it can be much easier to get packages into Debian than into Ubuntu
[21:01:43] * nixternal has about 90% now in Debian
[21:02:12] <nixternal> LaserJock: well, Ubuntu doesn't ask "what makes this better than package x which is similar?"
[21:02:18] <nixternal> Debian does, and they stick to it
[21:02:19] <sistpoty> LaserJock: 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 maintainer
[21:02:26] <LaserJock> nixternal: it should, and it should be easy to answer that question
[21:03:23] <LaserJock> anyway
[21:03:38] <Lamego> selecting between open source projects an easy answer ?
[21:03:41] <LaserJock> I kinda feel like people view Universe as a crutch so they don't have to get stuff in Debian
[21:03:47] <persia> I 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:04:02] <LaserJock> hah, like Debian doesn't have competition?
[21:04:15] <nixternal> I am with persia on that one
[21:04:19] <LaserJock> they just don't want people just packaging for packaging's sake
[21:04:37] <LaserJock> they want something that's gonna be maintained, as we should
[21:04:50] <nixternal> LaserJock: Debian does, but with them denying ITPs or RFPs just because something similar is already in their repos, that doesn't breed competition imo
[21:04:52] <sistpoty> well, I agree to persia, though we don't really have a way find the results of the competition when it comes to orphaned packages
[21:05:02] <persia> LaserJock: 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:14] <LaserJock> nixternal: you just ask somebody else
[21:05:32] <nixternal> LaserJock: hahaha, that has worked for me, but someone new who hasn't been around long, it isn't going to work
[21:05:37] <persia> sistpoty: That's a different problem (and a much harder one).
[21:05:46] <sistpoty> LaserJock: I guess your statement right now is closest to what I see the root of the problem: "packaging for packaging's sake"
[21:06:00] <LaserJock> I would be rather surprised if Debian just out-and-out rejected a package you plan to maintain
[21:06:08] <sistpoty> persia: which I hope we'll be tackling rather sooner than later ;)
[21:06:16] <nixternal> man, 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:40] <persia> I 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:57] <ScottK> Agreed.
[21:06:57] <LaserJock> anyway, perhaps we should get the particular agenda item resolved?
[21:07:03] <sistpoty> Agreed
[21:07:14] <ScottK> There's an agenda item?
[21:07:18] <nixternal> lol
[21:07:32] <LaserJock> persia: redoing the packaging guide, IMO, would be a good idea to make it more friendly to bug fixing and patching
[21:07:37] <nixternal> ScottK: don't you remember, you filled in for persia's topic because he was afk? :)
[21:07:45] <LaserJock> so votes on interdiff or diff.gz?
[21:07:59] <nixternal> OK, what was the reasoning for that again? :p
[21:08:02] * ScottK has had a nap in the meantime.
[21:08:04] <nixternal> been a while since we talked about them
[21:08:06] <nixternal> hahahaha
[21:08:11] <sistpoty> hehe
[21:08:18] * persia proposes "Request diff.gz in preference to interdiff when receiving new upstreams for review" as the subject for a vote.
[21:08:30] * sistpoty still prefers dgettable urls
[21:08:52] <sistpoty> (attached to the bug report)
[21:08:59] * nixternal thinks all of this talk is making for a good recipe honestly
[21:09:04] <nixternal> and not of the cooking variety
[21:09:09] <LaserJock> sistpoty: well, a diff.gz is pretty close
[21:09:17] <persia> sistpoty: hardy ubuntu-dev-tools will have a script to make it easy based on the decision in this meeting.
[21:09:39] <nixternal> should I go ahead and call the vote then for this with MootBot?
[21:09:42] <LaserJock> sistpoty: the only additional thing is that the sponsor has to do is get the .orig.tar.gz
[21:09:44] <sistpoty> ok, go ahead with the vote
[21:10:18] <nixternal> [VOTE] Request a diff.gz in preference to interdiff when receiving new upstreams for review?
[21:10:22] * persia requests people to vote based on interdiff vs. diff.gz, rather than on the larger issues
[21:10:29] <persia> +1
[21:10:30] <nixternal> +1
[21:10:33] <sistpoty> +1
[21:10:40] <LaserJock> +1
[21:10:48] <RainCT> +1
[21:11:01] <LaserJock> wow, I've never seen that before
[21:11:11] <LaserJock> when did we get this?
[21:11:22] <sistpoty> LaserJock: MootBot?
[21:11:24] <nixternal> he has been here for a while, jsut not many people use him?
[21:11:27] <persia> October or so
[21:11:29] <nixternal> any other voters?
[21:11:34] <LaserJock> oh, I see
[21:11:37] <nixternal> ScottK:?
[21:11:58] <ScottK> +1
[21:12:02] <nixternal> #endvote
[21:12:08] <sistpoty> [ENDVOTE]
[21:12:09] <nixternal> derr, I can't believe I did that again
[21:12:13] <nixternal> [ENDVOTE]
[21:12:25] <sistpoty> ;)
[21:12:27] <nixternal> they need to update the wiki page :)
[21:12:30] <sistpoty> that's why /me likes votes... long discussion, but short vote *g*
[21:12:33] <LaserJock> there's a wiki page?
[21:12:43] <nixternal> LaserJock: it is part of the Scribes Team
[21:12:49] * LaserJock wonders where he's been
[21:12:53] <persia> LaserJock: https://wiki.ubuntu.com/ScribesTeam/MootBot
[21:12:54] <nixternal> is that all for today?
[21:13:04] <LaserJock> I vaguely remember something about there being a scribes team
[21:13:36] <sistpoty> nixternal: fixed points are still left (next meeting time)
[21:13:41] <nixternal> oh ya
[21:13:48] * persia proposes 15th February, 12:00 UTC
[21:13:57] <nixternal> [TOPIC] Next meeting time
[21:14:24] <nixternal> [IDEA] persia proposes 15th February @ 12:00 UTC
[21:15:01] <sistpoty> ok with me
[21:15:02] <nixternal> that is a bit early :)
[21:15:08] <nixternal> 06:00 here
[21:15:17] <ScottK> How about 13 UTC?
[21:15:20] <nixternal> but I don't need to be here, so if it works for everyone else
[21:15:21] <persia> nixternal: Yes, but it's currently 06:15 here :)
[21:15:28] <nixternal> jeesh
[21:15:48] <sistpoty> nixternal: that's a bad starting attitude for a new MC member :P
[21:15:57] <nixternal> hehehe
[21:16:09] <persia> ScottK: conflict with MOTU Q&A session
[21:16:10] <nixternal> I don't want to be the 1 stinker among the many
[21:16:22] <sistpoty> hehe
[21:16:42] <nixternal> if I have to wake up early, I guess I will need to start working on that
[21:16:50] <nixternal> you are taking the freedom loving hippy out of me though :p
[21:17:15] <ScottK> For me that's right in the middle of getting the kids out the door for school time, so it's essentially impossible
[21:17:32] <sistpoty> any other proposals?
[21:17:47] <persia> 13:00 UTC is also 0:00 in Sydney. Maybe 11:00 UTC?
[21:18:19] <nixternal> 06:00 UTC :) that is midnight for me :) and lord knows I am still awake at that time
[21:18:55] * sistpoty will be eating lunch then, but sistpoty wouldn't be able to be fully present during work time anyway
[21:19:20] <persia> I 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:26] <nixternal> I 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:20:11] <sistpoty> nixternal: that would cause the scheduler to segfault, due to no options *g*
[21:20:25] <nixternal> hehe
[21:20:51] <nixternal> we had a nice wiki page that listed each member and their best times for being available
[21:21:13] <sistpoty> let's just vote... candidates so far are 11 UTC and 12 UTC, right?
[21:21:17] <persia> We'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:32] <persia> sistpoty: 13:00 was also proposed (by ScottK)
[21:21:48] <sistpoty> persia: but has conflicts in #meeting... but nixternal also proposed 6 UTC
[21:21:52] <sistpoty> right?
[21:22:01] <persia> Right.
[21:22:08] <nixternal> no, I was kind of joking on that one because that would be way to early for others more than likely
[21:22:27] <persia> Wait, conflicts in #meeting? resolvable conflict in #classroom
[21:22:50] <LaserJock> we should just rotate 4 hrs each time
[21:22:55] <sistpoty> persia: oh, sorry, so that's an option too
[21:23:01] * persia prefers 8 hour rotation
[21:23:15] <sistpoty> so at 28UTC *g*
[21:23:20] <nixternal> lol
[21:23:44] <persia> Works for me: scheduling is more flexible on the weekend.
[21:23:46] <LaserJock> persia: yeah, that works
[21:24:03] <persia> LaserJock: So you want to propose 04:00 UTC?
[21:24:38] <nixternal> that might be past his bed time though :)
[21:24:48] <LaserJock> whatever
[21:24:52] <LaserJock> I don't care what it is
[21:25:02] <LaserJock> but I think it'd be nice to establish some sort of schedule
[21:25:02] <sistpoty> let's just vote, shall we?
[21:25:43] <nixternal> do we have 3 times in which to vote for? what times are we looking at right now?
[21:25:47] <persia> sistpoty: We can only vote on binary conditions. Lots of votes maybe?
[21:26:08] <sistpoty> persia: it could be a non-mootbot vote ;)
[21:26:16] <nixternal> if we have 3, we can still use MootBot to count it for us, use +1 for one time, -1 for another, and +0 for another
[21:26:30] <sistpoty> cool
[21:26:46] <nixternal> list the 3 times and I will put it to action
[21:27:15] <sistpoty> so we have 4 utc, 12 utc and...?
[21:27:28] <sistpoty> 11 or 13?
[21:28:09] <sistpoty> if noone is against, I'd say 11 as 3rd option (qa-conflict)
[21:28:18] <sistpoty> 3
[21:28:20] <LaserJock> 4,12, and 20 I think are generally good
[21:28:20] <sistpoty> 2
[21:28:35] <sistpoty> then what LaserJock wrote ;)
[21:28:38] <nixternal> [VOTE] Next meeting time: Vote +1 for 04:00 UTC, -1 for 12:00 UTC, +0 for 20:00 UTC
[21:28:50] <nixternal> damn, there are 2 good ones for me now :)
[21:28:58] <persia> -1
[21:29:05] <sistpoty> -1 | +0
[21:29:11] <LaserJock> +1
[21:29:31] <nixternal> +1
[21:29:31] <RainCT> +0
[21:29:49] <nixternal> heh
[21:29:51] <sistpoty> +1
[21:29:59] <nixternal> you can only vote once :)
[21:29:59] <sistpoty> damn, I can't recast
[21:30:06] <persia> sistpoty: No double voting :p
[21:30:21] <nixternal> only the city of Chicago can double vote, or vote for dead people
[21:30:28] <sistpoty> heh
[21:30:30] <LaserJock> lol
[21:30:34] <nixternal> ScottK:?
[21:30:36] <nixternal> superm1:?
[21:30:43] <LaserJock> nixternal: Vegas is pretty good at that too
[21:30:48] <nixternal> true
[21:30:52] <nixternal> geser:?
[21:30:55] <ScottK> -1
[21:31:15] <superm1> +1
[21:31:20] <nixternal> jeesh
[21:31:21] <sistpoty> noooo
[21:31:29] <nixternal> come on geser, be the tie breaker :)
[21:31:30] <txwikinger> the dead people can vote as often as they want in Chaicago
[21:32:04] <geser> nixternal: reading the scrollback as my DSL-line comes and goes today, one moment
[21:32:09] <persia> Regardless 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:11] <nixternal> no problem
[21:32:21] <sistpoty> *drum rolling for geser*
[21:32:23] <geser> +0
[21:32:27] <nixternal> gahahahah
[21:32:49] * sistpoty starts to not like votes any longer *g*
[21:32:56] <nixternal> haha, I am with you on that one
[21:32:59] <LaserJock> it's looking good though
[21:33:09] <geser> at the other times I'm either sleeping or at work with no IRC
[21:33:11] <LaserJock> it means we have interest in all 3 times
[21:33:15] <nixternal> rock, paper, scissors?
[21:33:37] <sistpoty> I'd agree with persia though
[21:33:45] <nixternal> [ENDVOTE]
[21:34:09] <persia> Actually, let's just institute a standard rotation of 04:00, 12:00, 20:00, 04:00...
[21:34:10] <nixternal> persia: are you up and breathing MOTU at 04:00 UTC?
[21:34:26] <persia> nixternal: Sometimes. Depends on the client.
[21:34:28] <LaserJock> persia: that's what I was trying to say
[21:34:34] <persia> (it's lunchtime here)
[21:34:37] <sistpoty> persia: sounds sane, given the long discussion time for only the next meeting time
[21:34:47] <nixternal> [VOTE] Meeting rotation schedule or 04:00 UTC, 12:00 UTC, and 20:00 UTC
[21:34:50] <nixternal> +1
[21:34:52] <sistpoty> +1
[21:34:59] <superm1> +1
[21:35:03] <LaserJock> +1
[21:35:12] <nixternal> this is looking good
[21:35:18] <persia> +1 with a note that 28;00 UTC becomes 04:00 UTC so it always happens on Friday UTC.
[21:35:18] <geser> are the enough people for a meeting at 04:00 UTC? /me remebers meetings at 00:00 UTC where nearly nobody was there
[21:35:49] <geser> +1
[21:35:59] <geser> we can try it if it works out
[21:35:59] <persia> geser: 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:36:11] <nixternal> RainCT or ScottK?
[21:36:41] <nixternal> glad I can spell in the vote topic, s/or/for
[21:36:52] <LaserJock> yeah, that's 8pm for me
[21:37:35] <ScottK> 0
[21:37:42] <nixternal> add a plus to it
[21:37:43] <ScottK> +0
[21:38:09] <RainCT> +0
[21:38:11] <nixternal> [ENDVOTE]
[21:38:15] <LaserJock> so was the first agenda item discussed? renaming motu-uvf?
[21:38:19] <nixternal> yes
[21:38:20] <sistpoty> LaserJock: yes
[21:38:27] <persia> LaserJock: http://irclogs.ubuntu.com/2008/02/01/%23ubuntu-meeting.html
[21:38:31] <nixternal> it will be named motu-release per vote
[21:38:32] <sistpoty> wohoo we've found the date for the next meeting :)
[21:38:45] <superm1> was there a vote for who is on motu-release then too?
[21:38:54] <nixternal> [AGREED] Next meeting will be 04:00 UTC
[21:38:54] <superm1> or is that next meeting?
[21:39:01] <persia> superm1: There's a call for candidates: polls will probably be set up Monday.
[21:39:02] <sistpoty> superm1: no, that'll be on LP iirc
[21:39:10] <superm1> ah okay
[21:39:30] <nixternal> so now is the meeting ok to be adjourned?
[21:39:36] <sistpoty> +1
[21:39:40] <nixternal> #endmeeting
Meeting ended.

MeetingLogs/MOTU/20080201 (last edited 2008-08-06 16:27:09 by localhost)