[00:02] mok0: thanks! I will. [00:12] TheMuso, Hobbsee: ping [00:20] TheMuso, Hobbsee: bug #214083, fwiw [00:20] Launchpad bug 214083 in opensync "[FFe request] Please sync opensync_0.22-2 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/214083 [00:20] slangasek: Isn't that main? [00:20] TheMuso: the plugins are in universe and need updated at the same time [00:20] slangasek: Oh right, will attend to that, as I want to see this in. :) [00:21] ok :) [00:41] LaserJock, the feisty-proposed flash debdiff is up at bug 173890 [00:41] Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install due to md5sum mismatch" [Undecided,Confirmed] https://launchpad.net/bugs/173890 [00:44] LaserJock, i talked to the adobe rep at LF today, he wasn't aware of the issue with the naming scheme, and said he'd poke around to get it fixed [00:44] so we may have a better situation in the future [00:56] superm1: awesome thanks === evalles_ is now known as effie_jayx [02:10] Heya gang [02:11] bddebian heya! [02:11] Hi RAOF [02:11] (Why doesn't heya tab autocomplete? :)) [02:11] nv4x gallium now does reflections properly! neverball isn't evilly slow! [02:11] heh [02:12] Although it doesn't seem to want to quit :) [02:16] RAOF: but can it play WoW in wine? :) [02:16] RAOF: how did mandalon and mantuu go? [02:17] lifeless: It turns out that lvl 70 mages kick the pants of lvl 19 mobs. Who'd've thought? [02:17] But there didn't seem to be _that_ much XP gained. Mantuu is now 17.3 [02:18] let me guess, a deadmines run? [02:18] SFK [02:18] If you play with a much higher level character in a group, your XP is hamstrung [02:18] StevenK: its a net win done well [02:18] RAOF: how long was the run? 20 minutes or so ? [02:19] lifeless: maybe 1/2 an hour? [02:19] anybody got a couple of minutes to help oil my rusty brainz? [02:19] * StevenK did a deadmines run with two other 70s about a week ago [02:19] RAOF: do you have an xp/hour figure? [02:19] lifeless: I think it was somewher around 13K/hr [02:19] RAOF: so, 1 level / hour. [02:20] RAOF: that can be increased with practice :P [02:20] ajmitch: Nope; WoW still dies in st_program_stringify (which I should check against that intel mesa bug; it may well be that gallium hasn't had the fix applied). [02:20] StevenK: three 70's? [02:21] A rogue stealthed in, and killed all the bosses aside from VC himself, and then a 70 pally ran through the instance trying to drag every mob up to VC so we could try and kill everything at once. [02:21] StevenK: rotfl [02:21] It was great fun. [02:22] StevenK: I *can't* do that on my mage; level one arcane explosion kills the mobs too quickly [02:22] or a paladin tankign all of a scarlet monastery wing? [02:22] I've not seen that -- that would be cool. [02:22] RAOF: a shame, it'll be good to start replacing the binary blob [02:22] ajmitch: meh, a clothy can do all of SM nonstop [02:22] Aside from the fact that Scarlet Monastery sucks to get to [02:22] StevenK: having a trinket that heals on each block is useful there [02:23] lifeless: in 1 pull? [02:23] figurine of the colossus [02:23] ajmitch: if you mean 'without dropping out of combat' yes [02:23] * StevenK plays a 'lock, still wearing cloth and no shield [02:23] ajmitch: walk and ae nostop [02:23] Well, I have a shield, it's called a Felguard. [02:24] ajmitch: frost nova every time its up [02:24] ah, by the time I get home from work, the new badge vendor should be open [02:25] Mmmmm, the Isle [02:25] Dath finally hit phase 3 last night. [02:25] khaz is at 97% for the vendor [02:25] lifeless: On the plus side, Mantuu is coated in delicious blue [02:25] RAOF: I'm jealous [02:25] ajmitch: Which phase is that? If you know what you're fighting for, I can figure it out [02:26] RAOF: also, lvl 18 :P [02:26] * StevenK replaced one of his greens last night. [02:26] One more green and I'll be blue and purples only [02:26] StevenK: midway through phase 3 [02:26] lifeless: We picked up an 2h blue axe you would have loved. Sadly, BoP. [02:26] RAOF: ah well, we will get to sfk in a coulple of weeks I think [02:27] 1 more purple trinket, and I'll have a full set of epic gear for dps [02:27] I have 21 badges on my priest I think; need moar [02:27] ajmitch: Ahhhhh, you're a bit a head of us. Dath was 4% into phase 3 when I went to bed last night [02:27] cool [02:27] * ajmitch has 190 badges saved [02:27] jubei has the badge vendor already [02:27] * StevenK has 14, and is due in Karazhan tonight, so that should give another 5 [02:27] (Depending which opera event we get) [02:28] /topic Welcome to #ubuntu-WoW [02:28] well, technically we've got the vendor, just not selling anything :) [02:28] #ubuntu-wow actually exists, too [02:28] * slangasek stares [02:28] i didn't know there was a native linux binary for wow. [02:29] StevenK: you aren't downing curator yet ? [02:29] DarkMageZ: There isn't. Wine runs it nicely though. (On a laptop that isn't totally borked, like mine) [02:29] lifeless: Our group needs better gear for Curator [02:29] ah, heathens the lot of you :P [02:29] heh [02:30] Yeah at least NWN runs natively on linux ;-P [02:30] bddebian: Is that "natively", like the Eve client? [02:30] ut2k4 as well =D [02:30] (Which embeds an old and crap cedega into it's installer) [02:30] No, there was a Linux client and server [02:31] Had to buy the windows CD to get the CD-key though :-( [02:37] i used to have a pbuilder set up (still do) for breezy and dapper. can anyone help me remember how to run this setup with breezy-base.tgz and dapper-base.tgz files in my pbuilder directory? [02:38] nalioth: You can pass a --base-tgz argument [02:38] StevenK: ah, excellent :) thanks [03:07] nalioth: for some reason my pbuilder scripts broke when I upgraded to Hardy [03:08] nalioth: I'd recommend starting from scratch with the new pbuilderrc given on the wiki [03:09] YokoZar: i seem to have it working ( but i do things the longhanded way ) [04:07] good night people [04:10] LaserJock: am now [04:47] slangasek: looks to be doen [05:14] Hobbsee: you pinged me for something yesterday [05:14] LaserJock: yeah. what do you think would happen if all, or almost all, restrictions about paperwork applied for intrepid? [05:16] the people would revolt? [05:17] would they? i thoguth they'd be pleased. [05:18] Hobbsee: what to you mean? [05:18] we through out all the "paperwork"? [05:18] *throw [05:18] LaserJock: and put an emphasis on thinking before uploads [05:18] for MOTU's [05:19] well, hmmm [05:19] that sounds pretty chaotic [05:19] I was thinking more like streamlining [05:19] how so? [05:19] so that we have useful paperwork, helpful paperwork [05:20] well, in general I think throwing out all the rules is just swinging the pendulum (sp?) to the other side [05:20] a nice balance would be good [05:21] Wow. This is the first time I've seen code in a package to check copyright stuff... [05:21] but the suggestion wasn't raised to throw out everything? [05:21] ajmitch: Hobbsee just suggested it :-) [05:21] ajmitch: i suggested it as a starting point - for MOTU's, anyway [05:22] Hobbsee: I'd withdraw from MOTU in a heartbeat. We still need some paperwork. [05:22] firstly, I think maybe we're obsessing too much "paperwork" and "beaurocracy" [05:22] I'm very guilty of that [05:22] in fact, we really don't have all that much [05:23] some policies could use some tweaks [05:23] TheMuso: ... You would? [05:23] for instance, I'd like to make it possible for MOTU SRU to approve bug-fix microreleases [05:23] StevenK: If there was no paperwork involved for some MOTU related stuff, yeah I'd certainly think about it. [05:24] I think MOTU Release has done a good job of keeping things sane [05:24] so I don't think we need to do a lot there [05:24] Hobbsee: do you agree? [05:24] Hobbsee: how much do you trust all MOTUs? :) [05:25] LaserJock: i don't think it's helpful that i'm getting told off by core canonical people, for asking them why they didn't do the required procedures, because i'm creating work for them, and they're just trying to get their job done. [05:25] ajmitch: I assume that's her poing ;-) [05:25] ajmitch: it varies. [05:25] *point [05:25] Hobbsee: which procedures specifically are troublesome? [05:25] LaserJock: actually having to file a uvfes, i think [05:26] particularly for native packages, where the rules later changed. [05:26] ah [05:26] I agree [05:26] they just want to upload and do their job, rather than fiddle with teh paperwork, because they're good enough that they're going to get it right anyway. [05:26] we can tweak that though fairly easily [05:26] LaserJock: by exempting core developers, or certain people? [05:26] LaserJock: motu release certainly isn't looking - or even if they are, there's no real way that we can raise it with people when they're not following policy [05:27] or delegating all responsibility for certain packages? [05:27] ajmitch: perhaps for a time [05:27] ajmitch: if you exempt canonical, core devs, and trusted (older) MOTU's, then taht would work quite well. But, you couldn't then say that there was no canonical/community split, and the people who don't fall into the trusted category woudln't be happy. [05:28] we can say that for native packages whether a UVFe is needed is up to the descretion of the developer [05:28] for non-native it's pretty obvious and you avoid having to do UVFes for trivial changes [05:28] Hobbsee: in practice, we know there's a split [05:28] ajmitch: between which? [05:29] canonical & community practices [05:29] ajmitch: certain canonical people will tell you until they're black and blue that there is none, and get pissed off that you're saying there is. [05:29] so exacerbating that may not be so helpful. [05:29] well, we can make it workable [05:30] but I'm good at annoying people anyway [05:30] even if it's "ping a MOTU Release member and get an IRC ok first" [05:30] ajmitch: sure, but then they discredit you publically. [05:30] ajmitch: which often doesnt' help for getting other stuff done [05:30] no big deal [05:31] ajmitch: it is when the discussions suddenly die. [05:32] but, meh. I'd prefer not to deal in rants about how i can't effectively contribute to MOTU, again. [05:33] LaserJock: is it worth making that split worse, seeing as our non-canonical people are likely to be a larger group than the canonicalites? [05:33] sure you can [05:33] we don't have to make the split worse [05:33] I don't see how I'm saying that at all [05:34] I'm saying we can have a pretty laid-back and flexible policy that still provides guidlines [05:35] Canonical people can be held to the exact same standard as everybody else [05:35] and I don't think they expect less really [05:35] does that actually happen in practice? [05:35] mostly yes [05:35] I'd say it mostly does [05:35] not that I've been watching closely in recent months :) [05:36] we have a few instances each release of Canonical people "sneaking" things in last minute to get a spec done or things like that [05:36] but we can handle that fine [05:36] But since the discussion was had privately, it didn't happen? [05:37] (I'm guessing) [05:37] StevenK: regarding what? [05:37] LaserJock: Never mind [05:38] I don't think anybody has said that Canonical people should be treated any differently [05:38] mostly what happens is people are either unaware of the policies or disgree on the interpretation [05:39] *that* we can fix I think [05:39] I've certainly noticed that Main tends to be more flexible than Universe [05:39] Hobbsee: yep, thanks though :) [05:39] which is pretty weird [05:39] slangasek: y/w [05:40] LaserJock: why are they unaware? Are the decisions not on the ML enough? [05:40] well, honestly people are just used to uploading stuff [05:40] they know what they're working on and that it's good to go [05:40] * TheMuso beats the csound package into submission, since the person who requested its syncing didn't check that it built... [05:41] ...or, who acked it. [05:41] so I was thinking of doing like a developer cheat sheet [05:41] with like a checklist to make sure everybody is following the same or similar steps [05:42] TheMuso: tasty. And people wonder why i don't trust all MOTU's. [05:43] TheMuso: transient, or "no way this could have built in ubuntu, under any circumstances"? [05:43] Hobbsee: It wouldn't have built, and likely not have even built in sid, but I haven't checked yet. [05:43] a problem I see is that we kind of have to have an agreed upon standard before we can really say "heah, you need to ..." [05:43] This copyright code I mentioned earlier found a discrepancy in the copyright data, and flagged it, hense the FTBFs. [05:43] TheMuso: it did build in sid, fwiw [05:44] slangasek: Very interesting. [05:44] Hobbsee: I think a lot of the problems you are facing is that your fighting a subjective/non-existant standard [05:44] LaserJock: because what's written in the wiki isn't a standard. [05:45] the question should not be "what should you have done?" but rather "did you do what everybody knows you should do" write? [05:45] its' just suggestions. or something. [05:45] no, I don't think that's really it [05:45] though some of it [05:45] I don't know what's on most of the wiki pages right now [05:46] like I said yesterday, I often spend more time finding and reading policy wiki pages than I do doing the work [05:46] sounds like the people at UDS need to do a great wiki rework again. [05:46] well [05:46] the neverending story [05:47] I'm not sure that just endlessly "redoing" the wiki is what we need [05:47] hence why I was thinking of a cheatsheet [05:47] to noisey in here [05:47] nixternal: go to bed vista lover [05:47] I am trying to [05:48] I have a long drive to Michigan in the morning...not looking forward to that [05:48] LaserJock: cheatsheets would be a good idea. [05:48] nixternal: just dream of vista on the way [05:48] I dream of you! [05:48] isn't that sweet? [05:48] * ajmitch finds a bucket [05:48] it sure is [05:48] hahahaha [05:49] I personally think a lot of the policy wiki pages could be simplifies or clarified [05:49] clarified yes [05:49] I read and reread the SRU page like 4 times yesterday to figure it out [05:49] LaserJock: if you work up something I will help you tackle the wiki changes [05:49] and I'm on MOTU SRU! [05:49] haha [05:49] * ajmitch would need to study for a week before doing any uploads [05:50] exactly [05:50] Right, csound dealt with. [05:50] I want packaging to be the bottleneck for Ubuntu Developement [05:50] and that's what contributors are having a hard time with [05:51] that creating a package is just the beginning [05:52] so we need short, clear, and flexible policy pages [05:52] and not a bunch of them [05:52] and then have a cheatsheet page, a single page, that is all a dev needs once they've read the policy pages [05:52] what does "flexible" mean here? [05:53] well [05:53] i.e., how does "flexible" differ from "ignorable by people who think they know better but really don't, to the detriment of the archive"? [05:54] I was thinking about times when we make sort of insane policy "rulings" because that's what the wiki page says [05:55] *I* think it differs because I wouldn't say ignorable [05:56] but rather things like letting developers get IRC approval or doing more case-by-case judgements [05:56] I think a lot of things can be at the descretion of the developer [05:56] otherwise what's the point of being a developer? [05:56] the definition of MOTU/Core Dev is "we trust you to do day-to-day work in Universe/Main" [05:57] am I wrong? [05:57] LaserJock: do *you* trust all the MOTU's to do day-to-day work in universe? [05:58] all of the above is rather abstract, and I'm not sure what pages we're talking about that have led to insane policy rulings [05:58] honestly, no, not at the moment all of them [05:58] slangasek: the diffstat thing cjwatson was talking about yesterday? [05:58] slangasek: not allowing any new upstream releases in -updates? [05:59] hrm [05:59] well, the latter of those is a point of ongoing discussion in the archive team anyway [05:59] yeah [06:00] but part of the trouble is that, once you say that /one/ package is allowed new upstream releases in -updates, it's very difficult to know where to draw the line [06:00] yeah [06:00] but that's where I think you can rely on the discretion of the developer for most cases [06:01] and the relavent oversight teams in others [06:01] but if we are honestly looking at what's best for the archive/users [06:01] well, we do need to have clear guidelines for the archive team saying when we're supposed to push the button or not, and I don't think those guidelines are ever going to say "a MOTU vouched for it, so rubber stamp it" [06:02] (wrt to -updates, that is) [06:02] why not? [06:02] not that I really disagree [06:02] but we used to just upload to -updates directly [06:02] because not all MOTUs will necessarily be familiar with the guidelines for what's *supposed* to go into an SRU? [06:02] well, ok [06:02] why not though? [06:02] why wouldn't they be familiar with the guidelines? [06:03] is it really that hard to figure out what is SRU worthy? [06:03] that too [06:03] because SRUs arguably don't fall under "day-to-day work" [06:03] Because it's not necessary for "day to day" Universe activity? [06:03] I agree [06:03] and that's why I do think we need an "oversight" team there [06:03] ok [06:03] in that case, the failure was merely that the archive admin you tagged wasn't familiar with the oversight process and wasn't comfortable sticking his neck out :) [06:04] well, as being a member of the oversight team, I feel a little confined [06:04] I can't just look at an update and say "yeah, that's SRU worthy" [06:05] if I have things like "it can't be a new upstream release, it has to be fixed in the development release already, etc." [06:05] sometimes those are just not practical [06:05] and are more harm than good [06:06] so that's sort of what I'm thinking in terms of "flexible" [06:06] ok [06:06] it could be that this is fairly specific to SRUs though [06:06] and not a general thing with "oversight" teams === asac_ is now known as asac [06:07] I feel like as a MOTU SRU member *I'm* not being trusted [06:07] which I guess may or may not be true [06:07] but I'd hope if I wasn't trustworthy somebody would say something so I could step down [06:07] because *I* don't want to harm Ubuntu or the archive [06:08] FWIW, it's my view that the flashplugin-nonfree SRU is one that should never have flown if it were a package in main or universe because there's really no assurance that it's not including random unrelated changes that would constitute regressions [06:08] sure [06:09] but obviously you don't have many choices when it's a closed-source app; which we're having to contend with as well for the Canonical partner archive [06:09] I did the best I could, I had multiple people test the package for regressions on multiple browsers [06:10] "not being trusted"> in seb128's case, that's probably not an inaccurate description, because he's been outside the SRU process so he doesn't know the decisions that have been made /institutionally/ wrt trusting people [06:11] but I'm slightly concerned because, for instance, I had that update in Fedora within a couple hours, and people notice that kind of stuff [06:11] but I don't think it's a criticism of you /personally/ [06:11] and the only real roadblock for us was getting it actually *into* the archives [06:12] right, and I know that. seb128 probably didn't even know I was in MOTU SRU [06:12] so I'm not holding that against anybody, for sure === macd_ is now known as macd [06:13] so should I file a wishlist bug against LP asking for the MOTU SRU team to have access to moderate the *-updates unapproved queues? :) [06:13] I think that's in the works already [06:13] oh. should I ask you for a bug number so I can +1 it? :) [06:13] or do you think the right answer is that MOTU should be able to upload directly to -updates again? [06:13] I don't know if there's a bug for it, there is a blueprint I belive [06:13] no [06:14] that worked in the beginning [06:14] but after the dapper Xorg incident everybody got paranoid [06:14] and now that Universe is turned on by default we need higher standards [06:14] such that I don't think uploading to -updates should be called "day-to-day" work [06:15] hmm, did I mean *-proposed or *-updates, probably not a good think for me to not be able to keep those two straight :-P [06:15] s/think/thing/ [06:15] to be honest, flash worked pretty darn well [06:15] once we got it into -proposed [06:16] we got the required 2 "works for me"s and pitti moved it to -updates promptly [06:16] really nice [06:16] I do have an issue with treating -proposed so carefully [06:16] the whole point of having it is to test stuff out [06:16] * slangasek nods [06:17] I would think it would be as "experimental" as the development release [06:17] and users should have about the same level of expectation of breakage [06:18] so I don't think archive admins should really need to do much other than perhaps make sure the versioning is sane [06:18] well, IMHO if there are objective guidelines that we agree should be applied to SRUs, as a best-available heuristic for blocking broken updates and making sure the process is *scalable* by not eating up all the time of the handful of trusted MOTU/core devs involved with this stuff, those objective tests should be applied before -proposed rather than after [06:18] but to go through "MOTU ack", "MOTU SRU ack", "Archive Admin ack" just to get into -proposed seems a tad much [06:19] well, we've gone back and forth on that [06:19] whether the careful analysis should be done before -proposed or before -updates [06:20] I would think though that if the MOTU treated the upload as one would any other upload as far as testing, etc. [06:20] and that MOTU SRU acks it, it should be fairly safe to go into -proposed [06:21] would you agree? [06:22] LaserJock: so you view it as a question of allowing better parallelization of the work effort by having it in -proposed as early as possible for testing? [06:23] well [06:23] I was looking at it from the other side, that having users test packages that can never pass the SRU guidelines is time wasted, but I can see it both ways [06:23] if we have a testing repo but we have to do all the testing beforehand, what's the point? [06:23] no, they *should* pass SRU guidelines [06:24] oh, ok then [06:24] those are what I meant by "objective tests" [06:24] but I think by the time it's uploaded it should be there [06:24] so archive admin's shouldn't need to do anything but accept the upload [06:24] as opposed to user testing, which is entirely subjective but we depend on to catch things that we can't automate [06:25] oh, I agree; is that not what happens today, aside from the flash case? [06:25] well, I'm honestly not sure [06:25] I would think that's mostly how it goes [06:26] I personally test that every package I upload/sponsor builds and installs [06:26] and for SRUs specific testing to make sure the bug is indeed fixed and there are no obvious regressions [06:27] that's my minimum "objective tests" [06:28] is that sane? [06:28] do we need more than that for SRUs? [06:29] does "no obvious regressions" mean runtime tests? no requirements that the changes to the source be minimally intrusive? [06:29] if I'm preparing an SRU I do runtime tests [06:30] if I'm sponsoring one I might not do the runtime tests if I'm confident the sponsoree did them [06:30] and the minimally intrusive I think is a MOTU SRU judgement [06:30] but if I want an SRU to go through I'll do that [06:30] :-) [06:31] so you think it shouldn't be a requirement for all SRUs? [06:31] which one? [06:31] that the changes be minimal [06:31] I think it should [06:31] ok [06:31] but what constitutes "minimal" is the discretion of the SRU team [06:32] then I think we're pretty much on the same page :) [06:32] well, ok; I understand "minimal" to imply "doesn't contain extraneous changes" [06:32] sure [06:32] btw, where did we chase everyone else off to? :) [06:33] * TheMuso is here but is busy doing other things. [06:33] but from my view the only reasons for an "oversight" team are 1) to make sure the upload is SRU worthy 2) make sure the changes are minimal [06:33] * Hobbsee is drowning her sorrows in lots of drink. [06:34] so obviously MOTUs *should* be making minimal changes but MOTU SRU is there to make sure that's the case [06:34] Hobbsee: are LaserJock and I one of the sorrows? [06:34] I hope not [06:35] slangasek: no, not at the moment, at least. [06:35] well if I'm to be drowned, I guess I'd prefer it to be in drink [06:35] so really, I expect MOTUs to basically make sure SRUs are good and MOTU SRU is around for Quality Assurance [06:35] hehe [06:36] making sure that MOTUs are correctly applying these "objective tests" and know what is SRU worthy [06:37] in any case, the only thing I'm having issues right now with SRU is upstream microreleases [06:37] from a "oversight" team perspective [06:38] most of the SRU applications have been good [06:38] slangasek: do you know if the archive admins agree? [06:38] if we're causing problems for the archive admins I certainly want to know about it [06:38] * Fujitsu just read all the scrollback. Wow, there's a lot of it. [06:39] Fujitsu: sorry [06:39] 'tis a most interesting discussion. [06:40] now that I've been thinking about stuff for a while [06:40] And brought to light one of the strangest differences between main and universe I've seen lately: pinging slangasek on IRC vs. filing a bug and waiting for motu-release acks, for freeze exceptions. [06:40] I'm thinking a lot of the issues are basically MOTU consistency [06:41] LaserJock: I don't know, the person to ask that particular question is probably pitti :) [06:41] we need to reliably expect that from MOTU to MOTU that we get similar results [06:41] but I haven't /heard/ him complain [06:41] slangasek: good [06:41] he complained about the last SRU policy we had and we redid it [06:41] so that was nice to get feedback from the archive admins [06:41] Fujitsu: you mean the pings today from people asking me to look at the unapproved queue? [06:42] LaserJock: Or was that two or three policies ago? [06:42] maybe two [06:42] seems like it was fairly recently [06:42] slangasek: I've seen a few `OK to upload ' today. [06:42] (not actually something I'm in favor of, I don't particularly enjoy having my day be interrupt-driven :-P) [06:42] but the policy is kinda a blur [06:42] slangasek: heh just say file a bug. :) [06:42] slangasek: if it was a team rather than just you would it help? [06:42] Fujitsu: right... IIRC, the universe policy says pinging motu-release on IRC is ok as well? [06:43] well, I honestly think there is often disconnect between what the wiki page says and what happens [06:43] and it depends on which team member you ask [06:43] LaserJock: technically it is a team already, I still have the problem of being the one who can't pass the buck, which everyone else also knows :) [06:44] slangasek: you also hang out here. You're the only archive admin to do so [06:44] but, I made a point in the u-d-a emails to also tell people "if it's sane, just upload it instead of asking first", which I think has improved things this time around vs. last cycle [06:44] which I appreciate tremendously, btw [06:45] I remember being very surprised to see an archive admin in these parts near the end of last cycle. It is, as LaserJock says, very good. [06:46]