[00:20] <crimsun> does anyone actively use LLVM? (http://llvm.org)
[00:20] <crimsun> I need it for work, so I'm going to be updating to 2.1 and pushing to Debian
[00:20] <RAOF> What do you mean by actuvily?
[00:21] <crimsun> RAOF: meaning "I need this software updated, or my life at work will be miserable" :)
[00:21] <RAOF> Hah, no.
[00:21] <RAOF> Although I'm interested in it for two reasons: pypy & gallium.
[00:21] <crimsun> understandably so
[00:22] <crimsun> I'll be going with the gcc4.0 portion instead of gcc4.2, but I'm happy to coordinate packaging both if people seem to want both (?)
[00:22] <RAOF> I think I may want to start adding the nouveau 3d stuff to my ppa soonish, so a version that works with the gallium stuff would be good :).
[00:25] <pwnguin> RAOF: is the exa stuff making progress upstream?
[00:25] <RAOF> pwnguin: For nouveau?
[00:25] <pwnguin> yes
[00:26] <RAOF> From what I gather, it pretty much works on everything != nv30 atm.
[00:26] <RAOF> And by "works" I mean, "is fast on Xservers >= 1.4"
[00:26] <pwnguin> and for nv30?
[00:27] <RAOF> I'm not sure.  It was broken at some point because they didn't do the T&L init properly (and EXA is using the 3d engine).
[00:27] <pwnguin> last i knew, they wanted to hold off on xrandr improvements until exa was better
[00:27] <RAOF> I don't know if that's fixed yet.
[00:28] <ajmitch> exa is definitely getting better
[00:28] <RAOF> Ah.  EXA may well be in a state that's amenable to accelerating xrandr now.
[00:28] <ajmitch> that's mostly what they've been working on lately, it seems
[00:28] <ajmitch> of course there's been some experiments with gallium & ttm stuff
[00:28] <RAOF> For values of "they" in {Xorg, nouveau}, it seems.
[00:30] <RAOF> It looks like nouveau may be approaching the point where people start to really work on gallium stuff
[00:38] <ajmitch> & hopefully some ttm stuff soon in a branch, for texturing support :)
[00:41] <davebags> hey guys
=== bear is now known as bear_dinner
[00:59] <_16aR_> Hello
[00:59] <_16aR_> Anyone has tried apturl on PPAs ?
=== LjL is now known as LjL2
[01:26] <bmk789> is ubuntu planning a port to PS3?
[01:26] <Fujitsu> bmk789: There are Gutsy ISOs.
[01:26] <bmk789> really?
[01:27] <Fujitsu> Yes.
[01:27] <Nafallo> I think there where feisty isos as well, no?
[01:27] <Fujitsu> http://cdimage.ubuntu.com/ports/releases/7.10/release/
[01:27] <Fujitsu> Nafallo: Quite possibly.
[01:28] <bmk789> Fujitsu: thanks
[01:40] <joejaxx> not the netsplits again :(
[01:43]  * somerville32 dances.
[01:44]  * somerville32 sings "It is raining servers!"
[01:44] <Fujitsu> bigon: That is broken versioning in -proposed.
[01:45] <Fujitsu> How annoying.
[01:45] <bigon> Fujitsu: yea I realised that :/
=== _czessi is now known as Czessi
[01:48]  * Fujitsu people would conform to the SRU procedures and versioning.
[01:48] <Fujitsu> +wishes
[01:52] <persia> Fujitsu: For the latter, it may help to provide explicit guidance on versioning in the procedural documentation.  For the latter, it is perhaps more difficult.
[01:54] <Fujitsu> -0ubuntu1 is clearly wrong.
[01:55] <Fujitsu> It fails part 2.3, and common sense.
[01:56] <persia> Fujitsu: I agree it fails common sense, but I could construct a case for a hypothetical package in which it would meet 2.3.
[01:56] <persia> (although I would doubt a new upstream was ever a good SRU candidate anyway)
[01:56] <joejaxx> grr blasted lpia FTBS
[01:56] <Fujitsu> persia: We clearly want 2.20.1 in Hardy at some point, and the proper Hardy versioning would be -0ubuntu1.
[01:57] <Fujitsu> persia: GNOME 2.20.1 has a blanket exception.
[01:57] <Fujitsu> The first point release usually does.
[01:57] <bigon> packages are not checked by archive admin before being published in -proposed?
[01:58] <Fujitsu> bigon: I thought they were, but apparently not.
[01:58] <persia> Fujitsu: Ah.  Yes.  That's completely broken right now, although I suspect we are really targeted 2.22 for hardy, which means it won't matter later.
[01:58] <persia> bigon: Checked, but people are busy.
[01:58] <Fujitsu> That does, however, seem to be the standard for GNOME.
[01:58] <Fujitsu> But that is just plain wrong, wrong, wrong.
[01:59] <bigon> it was why I asked about migration,  this package should be directly migrated to hardy
[02:00] <persia> bigon: If it were before, yes.  Migrating now is trickier, as it requires manual adjustments on the servers, and the status is tracked badly.
[02:02] <Fujitsu> You might be able to convince an archive admin to do it (heck, seb128 is an archive admin and he uploaded some of the stuff with bogus versioning).
[02:04] <blueyed> Fujitsu: what would the correct version have been? 2.20.1-0ubuntu0.1?
[02:04] <persia> blueyed: That would have been preferable.
[02:05] <Fujitsu> blueyed: Yes.
[02:07] <Fujitsu> Also, I'm sure that SRUs are meant to be in the development release first, unless it isn't open yet.
[02:07] <Fujitsu> And those didn't look like particularly critical updates.
[02:08] <Fujitsu> But if archive admins don't follow procedure, I guess we can't expect others to.
[02:09] <persia> Fujitsu: No, it just means we need to complain to the archive admins, much as we'd complain to anyone else.
[02:24] <bigon> about SRU version what's better? 0.4.3-1ubuntu2.1 or 0.4.3-1ubuntu3~gutsy1 ?
[02:24] <persia> bigon: I like 0.4.3-1ubuntu2.1
[02:25] <persia> (both are policy-compliant)
[02:25] <Fujitsu> ~gutsy1 is for backports, not SRUs.
[02:25] <bigon> oh ok
[02:25] <Fujitsu> The normal SRU versioning is .1, or .7.10 (or appropriate release)
[02:26]  * persia agrees with Fujitsu, and notes that the documentation on this matter is notoriously poor
[02:26] <Fujitsu> I thought it was resolved a year ago that said documentation was to be improved, but apparently not.
[02:27] <persia> Fujitsu: Yes, it was resolved a year ago that said documentation was to be improved, but there was neither assignment nor volunteers.
[02:33] <ScottK> persia: I was responding to your earlier ping about overlap between our MOTU meeting topics.
[02:33] <ajmitch> hello Hobbsee
[02:34] <persia> ScottK: Ah.  Yes.  I'm very tempted to agree with you about new packages.  Would you be willing to rebut me on new versions in a first discussion, and then we'll hiit new packages in a second?
[02:34] <Hobbsee> hi ajmitch
[02:36] <Fujitsu> ScottK: What do you think about new packages?
[02:36] <Fujitsu> Morning Hobbsee.
[02:36] <Hobbsee> hiya Fujitsu
[02:37] <persia> Fujitsu: MOTU Meeting agenda may help create context in case ScottK still has 12-hour lag.
[02:38] <Fujitsu> persia: Thanks.
[02:38]  * ajmitch looks at agenda
[02:38] <ScottK> persia: I've got sending details on my proposal to the MOTU ML tonight or tomorrow.  I'll try and incorporate what you're propsing.
[02:38] <ScottK> As I understand it anyway.
[02:38] <ajmitch> ScottK: what's a 1-line summary of what you're proposing?
[02:39] <persia> ScottK: OK.  Just to clarify, I'd like to separate "new version" from "new package", and use REVU for "new package" and LP for "new revision".  I have other thoughts on how these should be reviewed, but they may be separate to that central dichotomy.
[02:39] <ScottK> ajmitch: Quit trying to status new package reviews in two places.  LP for needs packaging/assignement/fix released with a link to revu and revu comments in between
[02:40] <ScottK> persia: I'm going to have to disagree with you on that as I find REVU useful for new version too, but definitely agree that the diff of the Debian dir is quite needed.
[02:40]  * persia agrees with ScottK that the current state is broken and likely to create duplicate work or conflicting information to contributors
[02:40] <ajmitch> alright, I wasn't aware that people were using LP much for tracking the status
[02:40] <ScottK> ajmitch: Some are and some aren't and that's part of the problem.
[02:41] <ajmitch> I thought that the general practice was following what you are proposing
[02:41]  * Fujitsu thinks that an interdiff of the .diff.gz should be all that is needed for new upstream versions, soon.
[02:41] <persia> ScottK: Not just the debian dir: I want a full diff of everything in diff.gz.  Anyway, I'm happy to debate LP vs. REVU at the appropriate time, I just want to separate the concerns, as I think that new package issues are sufficiently different from new version issues to warrant separate discussions.
[02:41] <ScottK> ajmitch: It is what has been agreed at a MOTU meeting.  Some people (dholbach in particular) have pushed the current practice well beyond what the community has ever agreed to.
[02:42] <ScottK> persia: Fair enough.
[02:42] <persia> Fujitsu: Actually, I'd really like something better than interdiff, which gets annoying when the diff.gz files are in different orders, but basically, yes.
[02:42] <ajmitch> probably because he didn't want processes to stagnate, and was trying to find new ways of managing it
[02:43]  * ScottK find process churn to be a problem and would like to avoid semi-random process changes.
[02:43] <persia> ajmitch: I'd agree with that, and believe that the current state comes from the best of intentions, but it's likely time to review, and either choose a more modern method, or go back to the old way, rather than maintaining both processes.
[02:44] <ScottK> I think moving from the wiki to LP for needs-packaging was a good move.  It was the unagreed churn after that I find problematic.
[02:44]  * persia notes that the parallel processes have been maintained since late feisty
[02:45] <ScottK> And been problematic since then too.
[02:46] <persia> ScottK: did we have conflicts in feisty?  I thought that the parallel model worked fairly well when first testing the new process, it was only after it became normal without the old becoming deprecated that we hit a wall.
[02:46] <ScottK> persia: I've never liked the double book keeping approach and it was never agreed to.  It just happened.
[02:47] <ScottK> When I pinned dholbach down on this point at UDS he described it as a logical consuequence of the move to needs-packaging bugs and so no agreement to change the process was needed.
[02:49] <persia> ScottK: Ah.  I see your point there.  I still think there needs to be opportunity for experimentation with process alterations, to provide a basis of discussion, but I agree that regularisation of double-entry is not ideal: if the new process is better, we should use it.  If not, we should drop it.  If not there yet, we should adjust it.
[02:49] <ScottK> Right, but there continue to be process 'experiments' that get documented in the wiki in ways that make it not at all clear it's an experiment.
[02:50] <ScottK> New package reviews in bzr was one of those late Gutsy until I pushed back on that.
[02:50] <persia> ScottK: That's true, and a different problem.
[02:50] <ScottK> I agree with process experimentation if and only if it's clear what's experiment and what's not.
[02:51] <ScottK> So I don't think it's at all different.
[02:51] <ajmitch> agreed, I like having new processes if they'll make life easier
[02:51] <ajmitch> but confusing people with multiple ways to do things doesn't make it easier
[02:52] <ScottK> Yes.  Experimentation is fine, but a short experiment followed by mail to MOTU ML, and then a few days later, "No one objected so here's how we do it now..." is not fine.
[02:52] <ScottK> Confusing old people coming back is not good either.
[02:53] <ScottK> As siretart pointed out at UDS, we really need a process changelog people coming back can review.
[02:53] <persia> ScottK: I see several different issues: 1) The process shouldn't change without discussion, 2) experimental and test processes should be clearly marked as such, 3) experimental processes should be adopted wholly or stopped after the testing period: we should not support dual processes, 4) current processes should be documented somewhere for clear reference to all parties.
[02:54] <ScottK> I don't think anyone disagrees with these points as stated, the just aren't followed by some.
[02:54] <persia> I don't see how these are related, except that they are about processes.  Because all of these issues exist, things get awkward.  I think we've an hours worth for the 9th, but perhaps we could have a meta-process agenda item for the 23rd?
[02:54] <ajmitch> ScottK: ubuntu-devel-announce should be used for that, I think
[02:54] <ajmitch> it's not used often enough
[02:54]  * persia agrees with ajmitch about process changelog
[02:54] <ScottK> Sounds reasonable.
[02:54] <ScottK> persia: I'd like to nail down the specifics we have for the next meeting and not defer them, but sure.
[02:55] <persia> ScottK: Ah.  Yes.  it's precisely because I believe the new package / new upstream issue is more important than meta-process that I suggest meta-process be handled on the 23rd.  We need to fix the other now, as it's already annoying Contributors and slowing reviews.
[02:56] <ScottK> Agreed.
[02:57] <ScottK> persia: If we could add debian dir diff and .diff.gz diff to REVU would you consider that an appropriate place for new upstream versions?
[02:58] <persia> ScottK: Maybe.  I think debian dir diff is dangerous because someone might not check for other files in diff.gz.  I also think that once we've accepted a package, we need more agressive cryptographical checks to make sure we're shipping the right thing.  I'm still preparing the list for the 9th, so I'm not really prepared to debate that now.
[02:58] <Fujitsu> ScottK: New upstream versions are closer to normal sponsoring jobs - the process should be similar to them, not NEW packages.
[02:58] <persia> Fujitsu: That's the other point.
[02:59] <persia> Anyway: this is on the agenda for the meeting: let's wait until everyone is together to discuss specifics.
[02:59] <ScottK> Except you need to download the entire pacakge.
[02:59] <Fujitsu> When the vast majority of packages have sane watch files in the near future, it should be easier.
[02:59] <ScottK> OK.
[02:59] <Fujitsu> ScottK: Why?
[02:59] <persia> ScottK: If you don't do that anyway, you aren't checking the cryptography properly.
[02:59] <Fujitsu> Exactly.
[03:00] <ScottK> Yes, you need to download it, so LP doesn't give you a good place to do that from.
[03:00] <Fujitsu> If I sponsor an upstream version, I check the upstream site anyway, to see that it's the really the right tarball.
[03:00] <persia> ScottK: Right.  Downloading from LP would be even *more* broken.  You need to download from upstream.
[03:01] <ScottK> So the packager provides a diff.gz and a .dsc and you get the tarball yourself?
[03:02] <persia> ScottK: No, I just want the interdiff.  I can apply that to the current diff.gz to make a candidate diff.gz, download upstream with the watch file or get-orig-source, and make my own .dsc.
[03:02] <ScottK> I see.
[03:02] <Fujitsu> That means you are guaranteed to get a real upstream tarball, can more easily review the changes, and not upload a lot of big attachments to LP.
[03:03] <persia> Plus, it enforces that all Ubuntu-local new upstreams have get-orig-source or watch files so we can more easily maintain them in the future.
[03:03] <ajmitch> ScottK: of course the suggested way is often to rm the supplied tarball & grab upstream's
[03:04] <Fujitsu> persia: That too.
[03:04] <Fujitsu> And with the Debian mass-filing yesterday...
[03:04] <persia> Fujitsu: Now we just need to get "should" changed to "must" for get-orig-source, and everything is golden :)
[03:05] <Fujitsu> Yep.
[03:08] <bddebian> pfft ;-P
[03:08] <ScottK> persia: You mean must for repacked tarballs?
[03:09] <persia> ScottK: It's already "should" for all packages in Debian: I don't see why it shouldn't become "must".  Writing get-orig-source to call uscan is trivial.
[03:10] <ScottK> persia: Where is get-orig-source a should for non-repacked tarballs in Debian policy?
[03:10] <persia> ScottK: Of course, I don't expect that to happen for a couple years, and don't see the point of imposing it in Ubuntu early: at this point I'd like "must" for repacks, and "should" for thers.
[03:10]  * ScottK doesn't see the point if you have a watch file.
[03:11] <persia> interface standardisation, but I agree it's not very important.
[03:11] <Fujitsu> Are we all agreed that a debian/watch is a "must" for REVU?
[03:12] <persia> Fujitsu: That's also for discussion on the 9th, but I'm a fan
[03:12]  * ScottK agrees it's a good idea and someone should propose it at a MOTU meeting so we can agree to the process change.
[03:12] <Fujitsu> ScottK: It's there.
[03:12] <ScottK> Perfect
[03:13]  * ajmitch wonders if it should be made a lintian error on REVU
[03:13] <Fujitsu> ajmitch: That's a good idea.
[03:13] <persia> ScottK: You're correct.  I must have been looking at a draft or proposal.  Currently, 4.9 only says "This target is optional, but providing it if possible is a good idea."
[03:14] <ScottK> ajmitch: Sounds like a good idea.
[03:14] <bddebian> Watch files are NOT possible for every application.  I have like 50% of the packages on the games team that are virtually impossible to create watch files for
[03:14] <Fujitsu> bddebian: Why would such a high number be impossible?
[03:14] <persia> bddebian: Really?  Is this because upstream doesn't act sane, or is there something else happening?
[03:14] <ScottK> bddebian: OK.  Required unless proven not feasible.
[03:15] <bddebian> Either upstream is gone (can't find the tarballs at all) or the upstream naming is such that it cannot be done
[03:15] <ajmitch> persia: I doubt that many games have sane upstreams
[03:15]  * persia is worried about maintainability of Ubuntu-local packages without automated mechanisms to track new upstreams
[03:15] <ajmitch> bddebian: of course your packages would sneak in the back door via a debian sync :)
[03:16] <persia> bddebian: Ah.  Yes, I should have said "dead or insane".  Games are extra hard.  Happy Penguin should organise a general upstream repository.
[03:16] <persia> ajmitch: Doesn't help with the recent mass-bug filed.
[03:16] <chillywilly> hmmm, terminal fonts are all fubar after the dist-upgrade
[03:16] <ajmitch> persia: of course not
[03:16] <chillywilly> that's not cool :-/
[03:16] <Fujitsu> I believe said bug-filing will be a regular occurence, too :)
[03:17] <bddebian> persia: I think we should just lynch all the damn upstream devs.  It's crazy :)
[03:18] <persia> bddebian: Nah: lynching makes them not produce more games.  They just need someone to be "official, sane upstream" to whom they can send their files when they want them distributed.
[03:18] <bddebian> Honestly most of them are just stupid anyway :)
[03:19] <ajmitch> then enlighten them
[03:20] <bddebian> I mean the games themselves are weak :-(
[03:22] <ajmitch> why do you package them then?
[03:22] <bddebian> Honestly I'm not even sure why we have packaged some of them
[03:22] <ajmitch> fame & glory?
[03:22] <bddebian> I don't ;-)
[03:22] <ajmitch> the respect of debian people? :)
[03:22] <bddebian> I am just trying to help fix the crap already there :-)
[03:22] <bddebian> Oh yeah, that's it ;)
[03:23] <bddebian> There are a few exceptions
[03:23]  * Fujitsu wonders why Debian likes PHP so much.
[03:23] <bddebian> Bos Wars is well done
[03:23] <bddebian> ASC 2.0.1.0 looks nice (I'm working on that now)
[03:23] <white> Fujitsu: good question
[03:25]  * bddebian talks shit as he fires up The Witcher again..
[03:45] <Fujitsu> Oh dear.
=== bear_dinner is now known as bear
[03:45] <ajmitch> fun, isn't it?
[03:45] <joejaxx> these netsplits are getting ridiculous
[03:45] <Fujitsu> slangasek: I wondered who was going to attack me about it.
[03:45] <Fujitsu> slangasek: Lessee...
[03:45] <Fujitsu> DEHS is written in it.
[03:45] <Fujitsu> debcheck's frontend is too...
[03:45] <slangasek> "debcheck's frontend"?
=== rob1 is now known as rob
[03:45] <Fujitsu> slangasek: Yes, the debcheck web frontend.
[04:13] <somerville32> Hi
[04:13] <Hobbsee> there we are...
[04:13] <Fujitsu> But for how long...
[04:13] <persia> Fujitsu: More explicity, I don't entirely understand what you are seeking.  PATCHES seems to have a list of variation, against which one could compare things.  On the other hand, if you want to differentiate "updated" from "pending" merges, you'll either need access to the internals, or to maintain your own gutsy/hardy Sources.gz as a reference.
[04:13] <StevenK> And if nickserv will answer
[04:13] <Fujitsu> persia: What I really want is a list of packages that are deemed to be `local', as represented in the MoM stats.
[04:13] <Hobbsee> it will - slowly
[04:13] <Fujitsu> StevenK: I can imagine it might be a bit flooded.
[04:14] <persia> Fujitsu: Ah.  I believe that is just the list of packages that are present in local Sources.gz and not in sid Sources.gz, but I suspect there is a blacklist involved as well.
[04:15] <Fujitsu> persia: Right, it has about 70 fewer packages than mine. I'll see what happens if I also exclude the blacklist..
[04:20] <persia> Fujitsu: Ah.  I see now.  Where's the MoM blacklist?
[04:20] <slangasek> Fujitsu: so anyway, I have to disagree with your conclusion that "Debian" likes PHP.  There are some people peripherally involved in Debian who seem to like prototyping in PHP, and sadly qa.debian.org seems to be pretty heavy on PHP, but I believe that Debian developers as a whole (taking myself as a representative sample) have a healthy dislike for PHP. :)
[04:21] <Fujitsu> slangasek: Well, QA people like PHP. There we go.
[04:21] <Fujitsu> Oh dear.
[04:22] <persia> Err..  Rather Debian QA websites appear to be typically implemented in PHP.  They may hate it, but that doesn't force things.
[04:22] <Fujitsu> persia: If they hate it, why would they right their tools in it?
[04:22] <Fujitsu> *write, gah.
[04:23] <persia> Fujitsu: That may be the best of the environments available on servers that the authors don't control, where the administrators haven't deployed something else yet (although I'd expect most to be running etch by now: they  may not have been when the tools were developed)
[04:24] <persia> I could even believe that some of the tools were first deployed onto Woody servers, which makes PHP a less surprising choice
[04:24] <Fujitsu> I guess so.
=== asac_ is now known as asac
[05:21] <ScottK> persia: I've been considering your new upstream sponsorship proposal.  I've a counter proposal.  First we need to agree and document a Best Current Practice for MOTUs reviewing and sponsoring new upstream versions.  From that I think how to submit them and what to submit will be obvious.
[05:21] <persia> ScottK: That sounds good.  Do you think we can do that in a meeting, or do you want to first collaborate on a proposal?
[05:22] <ScottK> I think the conversation on IRC was a good start.  I think document that and you're 90% there.
[05:22] <ScottK> If you can put that together, maybe we can agree in the meeting.
[05:23] <persia> ScottK: In that case, I'll outline things a bit more (as it's quiet), let you object, and propose it at the meeting.
[05:23] <persia> New Upstreams:
[05:23] <persia> Reviewer should be reviewing the work done by the packager: if good, the package should be prepared for upload to meet cryptographic requirements.
[05:24] <persia> This means that the reviewer needs to look at the difference in packaging (interdiff of diff.gz) to make sure the right things are being done, and then use the provided watch file or get-orig-source to prepare a candidate package.
[05:25] <persia> The candidate package should be reviewed to see if there are other bugs that can be usefully closed, or other adjustments deemed wise, these applied, and uploaded.
[05:25] <persia> New Packages:
[05:26] <persia> Reviewer should be reviewing both the work done by the packager and the applicability of the proposed package for Ubuntu.  The packaging should meet all automatic tests, follow documented policy, and provide a get-orig-source rule or watch file to ease future team maintenance of updated packages.
=== jdong_ is now known as jdong
[05:27] <persia> The package should integrate well with an Ubuntu system, and not directly conflict with anything in main unless there is an associated spec for a future transition.
[05:27] <persia> Each candidate should be approved by two members of ubuntu-dev for correctness and suitability, after which it may be uploaded.
[05:28] <persia> ---
[05:28] <minghua> What does "directly conflict" mean there?
[05:28] <persia> Aside from that, it's just implementation details
[05:28] <ajmitch> persia: would you require approval by 2 ubuntu-dev members for all packages, or just those by non-MOTUs?
[05:28] <Fujitsu> I think that `should meet all automatic tests' should probably be clarified - I presume it means lintian/linda?
[05:28] <persia> minghua: Something like the Y Window system, unless there is a strong compellling reason.
[05:28] <Fujitsu> Yay!
[05:29]  * ajmitch kicks freenode
[05:29] <persia> ajmitch: I say 2, but if the packager is one, that only requires one more.  I'm not perfect, and I don't expect you to be.
[05:29] <minghua> persia: But what if X Window and Y Window can be installed in parallel?
[05:29] <persia> Fujitsu: Yes, it all needs a little more clarification, but that's the base of what I was thinking: perhaps also piuparts.
[05:30] <persia> minghua: They can't (or couldn't last I looked), but it they could, it wouldn't be a conflict.
[05:30] <minghua> persia: Basically I am asking if it's "conflict of interest" or "Conflict in dpkg-sense"
[05:30] <persia> minghua: Conflict in dpkg-sense
[05:30] <Fujitsu> I think those guidelines look pretty good.
[05:30] <minghua> Right.  (BTW I didn't know Y Window System is a real-world example...)
[05:31] <persia> minghua: It's a local-frame-buffer windowing system for posix compliant systems, but it's not call-compatible to X.
[05:31] <persia> (and I think upstream is losing interest, or has already done so, due to newer, faster, X)
[05:31]  * ajmitch isn't entirely happy with requiring 2 ACKs for everything yet again - it will get ignored quite often
[05:32] <persia> ajmitch: We require 2 ACKs now: that won't be a change.
[05:32] <minghua> persia: Thanks.  Don't let me sidetrack you though. :-)
[05:32] <ajmitch> persia: we did change it so that MOTUs weren't *required* to get the additional review, I believe
[05:32] <ajmitch> though it was still encouraged
[05:32] <persia> ajmitch: Given that I've never advocated another MOTUs package on first review, I don't find that encouraging.
[05:33] <ajmitch> at which point does it become ignorable? when you're hired by canonical? :)
[05:33] <minghua> persia: An extra ACK for MOTU's new package upload is probably better left as a soft requirement.
[05:33] <ScottK> ajmitch: I think we changed it from MOTU needs to acks to MOTU counts as one of the acks.
[05:33] <persia> minghua: I'll defer to current policy regarding the number of ACKs, but I think it's 2,
[05:33] <ajmitch> ScottK: it was always a MOTU counting as an ACK before that
[05:33] <ScottK> This is for new packages.  For new upstreams, it's only one.
[05:33] <persia> ScottK: That's my memory: it used to be three people, and now it's down to two.
[05:34] <persia> ScottK: For new upstreams, MOTU needs an ACK?  I've just uploaded the one I did.  Was that wrong?
[05:34] <minghua> Basically I don't think it's enforceable, and it's always bad to have unenforceable policies.
[05:34] <ScottK> persia: No that's right.
[05:34] <ScottK> persia: For new upstream MOTU can be the one.
[05:34] <persia> ScottK: Right.  Originating MOTU as ACK.
[05:34] <ajmitch> minghua: it's certainly not enforceable, most of core-dev would ignore it, I'd say
[05:35] <minghua> ajmitch: Yeah, I'm with you on this.  (Not that my opinion matters much, though.)
[05:35]  * Fujitsu admits to having ignored the rule once, though it was just a rename.
[05:35] <ScottK> ajmitch: I've seen Riddell upload new packages for review.
[05:35] <ajmitch> (my opinion isn't worth anything either)
[05:35] <persia> ajmitch: Maybe: we can encourage them to look at each other's packages, and to let us look at their packages: for a good package (even one that needs a little work), the total cycle is usually less than an hour.
[05:35] <ajmitch> ScottK: he'd be one of the few then
[05:35] <ScottK> The ironic thing is I found a licensing/copyright problem in it.
[05:36] <persia> That's actually the reason I favor reviews.  The people who do lots & lots of reviews get pretty good at looking for things.  Most developers couldn't care less about many of the issues.
[05:38] <ScottK> StevenK: Any idea how long one has to generally wait for an AM to be assigned these days?
[05:38] <ajmitch> probably several weeks
[05:38] <Fujitsu> ScottK: Mine was 3 months, IIRC.
[05:38] <Fujitsu> Yeah, about that.
[05:38] <ScottK> Thanks.
[05:39]  * ScottK got advocated today, so waiting for AM now.
[05:39]  * persia continues to find NM sufficiently painful to be avoided
[05:39] <ajmitch> given the length of the list of unassigned applicants, it could take awhile
[05:39] <ajmitch> jcastro! dude!
[05:39] <Fujitsu> Oh joy, of the 149 Ubuntu-specific packages that actually have watch files, 59 of them don't work at all.
[05:39] <ajmitch> only 59?
[05:39] <ajmitch> that's pretty good
[05:40]  * persia grumbles at reviewers who don't test watch files
[05:40] <Fujitsu> persia: These could well be old stuff synced from the middle of nowhere.
[05:40] <persia> Fujitsu: Ah.  True.
[05:40] <ajmitch> sorry persia, we're not all wonderful at reviewing like some
[05:41] <persia> ajmitch: Huh?  I'm not a very good reviewer: I just run uscan, linda, lintian, and have 4 or 5 manual checks.
[05:42] <ajmitch> if I review, I'll get grumbled at, I'm sure
[05:43] <persia> ajmitch: Actually, while I grumble at people in general, I'm always happy when people review: there's never enough people to just take a look at the packages, and give the packagers a little feedback.
[05:44]  * somerville32 has learnt a lot from persia 
[05:45]  * ajmitch heads out
=== highvolt1ge is now known as highvoltage