Times are Eastern Daylight Time (-0400). This is just for the record (I've removed the IRC discussion not relevant to this thread) ....
This starts out with a discussion about https://bugs.launchpad.net/bugs/141101 [11:44] <mdz> Hobbsee: pardon? [11:45] <mdz> Hobbsee: "upstream version freeze" has, by definition, never applied to new packages [11:45] <Hobbsee> mdz: no, bu t new package freeze certainly does. [11:46] <Hobbsee> (which is what bryce actually meant in the bug report) [11:46] <mdz> Hobbsee: I am not prepared to remark on what he may have meant, only what he said [11:47] <Hobbsee> ScottK: did you want to respond? seeing as it was your complaint. [11:48] * ScottK reads the backscroll. [11:50] <ScottK> mdz: In MOTU we've been using the UVF exception process to cover both UVF exceptions and New package freeze exceptions, so asking for a UVFe for the new package was consistent with what we've been doing. [11:50] <towolf> the right side is after your revert, the left side is before the revert, but with suboptimal settings. center is authinter light mode. [11:51] <ScottK> Hobbsee and mdz: It's not clear to me from the backscroll what Hobbsee said that you were responding to. [11:52] <Hobbsee> ScottK: the ati bug that you were complaining about earlier? [11:52] <ScottK> Yes, but I was trying to get the exact context that led to "<mdz> Hobbsee: "upstream version freeze" has, by definition, never applied to new packages" and couldn't find it. [11:52] <mdz> ScottK: ok. I think that's a bit confusing, and suggest that we clarify this as part of pitti's work on consolidating freezes [11:53] <ScottK> mdz: I agree with it being confusing. [11:53] <ScottK> If we consolidate the freezes it would certainly make it easier. [11:53] <Hobbsee> ScottK: because there's no current version to compare the new upstream to, as it's new to ubuntu - so as mdz says, no possibility of regressions [11:53] <mdz> ScottK: I was responding to: [11:53] <mdz> <Hobbsee> seb128: at this point, we've stuck a blanket deny on any new packages, unless they're really important or interesting [11:53] <mdz> <Hobbsee> seb128: which mdz then hijacked, but that's beside the point. [11:53] <ScottK> Ah. [11:54] <ScottK> Yes. The reasons for new package freeze are entirely different. [11:54] <mdz> Hobbsee: interestingly enough, NewPackagesFreezeUniverse is one of the minority of freeze states which lacks a rationale on https://wiki.ubuntu.com/UbuntuDevelopment [11:54] <ScottK> As I understand it, primarily because the archive admins have other stuff to do late in the release. [11:55] <Mithrandir> ScottK: actually not. It was institutionalised at the request of MOTU as a way of forcing the MOTUs to concentrate on what was already in the archive. [11:55] <ScottK> Mithrandir: Ah. That would make sense too. [11:55] <seb128> ScottK: the freeze period is not really the busy time for the archive admin work [11:55] <seb128> ScottK: there is an higher number of sync requests and new packages when there is no freeze in action ;) [11:55] <pitti> seb128: it's for me, anyway [11:56] <seb128> pitti: how so? [11:56] <pitti> seb128: cleaning up the archive and beat it into consistency is a huge task [11:56] <pitti> seb128: just because before releases this has to be done [11:56] <ScottK> seb128: Yes and that's even with the ones we said no about. [11:56] <Hobbsee> mdz: seems to be on https://wiki.ubuntu.com/NewPackagesFreezeUniverse (linked from your report), as much so as the others are. [11:56] <Hobbsee> mdz: but i recall you saying to me - never put down to maliciousness what you can to disorganisation. [11:56] <seb128> pitti: we sort of try to clean up for every milestone CD [11:56] <pitti> seb128: right [11:57] <pitti> seb128: but the amount of churn that piles up is amazing [11:57] <seb128> pitti: well we slacked on that during the rest of the cycle [11:57] <seb128> pitti: try to not process NEW nor sync request for a month during the busy time of the cycle, I think the backlog would be quite impressive [11:58] <mdz> Hobbsee: what does? that doesn't seem like a rationale. I'm not questioning the usefulness of setting a deadline for new packages, but we should document the reason for it [11:58] <pitti> seb128: right, but if people stop packaging new crazy stuff and start concentrating on bug fixes, there shouldn't be NEW churn in the first place [11:58] <mdz> Hobbsee: also, that description merely says that new packages in the queue won't be accepted -- it doesn't say that they shouldn't be uploaded [11:59] <seb128> pitti: right [11:59] <mdz> Hobbsee: in which case, the sensible workflow would be upload -> request exception -> accept [11:59] <Hobbsee> mdz: which then sticks more work on the archive admins, though. and they have too much stuff to do as it is. [12:01] <Hobbsee> mdz: the aim, from my POV, is to not let things even get thru to the archive admins without exceptions. it's not their job to send it back, etc. [12:01] <mdz> Hobbsee: how does it create more work for the archive admins? [12:01] <mdz> Hobbsee: as I understand it, they'll just stop looking at the queue at the appropriate time [12:01] <Hobbsee> mdz: to have to check if exceptions are granted for everything that's in their queue [12:02] <Hobbsee> mdz: which makes them never deal with any exceptions, no? [12:02] <Hobbsee> mdz: then again, this is only for this release anyway. who knows what will happen next release. [12:02] <mdz> Hobbsee: presumably the archive admins are notified of exceptions, in which case they just accept the specific package which has been excepted. no need to look at anything else in the queue [12:02] <mjg59> towolf: The light blue blends into the white background much more readily than it does the black background [12:03] <mdz> Hobbsee: they would act based on the exceptions, not the packages (which should be much lower volume) [12:03] <Hobbsee> mdz: currently, there's hte understanding that anything in the queue has an exception, so they dont need to check it. however, your logic would work too. [12:03] <ScottK> Agreed it's sensible, just not how we've been doing it. [12:03] <Hobbsee> mdz: (and conversely, that anything *not* in the queue does nto have an exception) [12:04] <cjwatson> Hobbsee: the archive team can't realistically act on the assumption that people are honouring all freeze states [12:04] <mdz> Hobbsee: ideally, folks would go ahead and upload, and if they don't get an exception, their upload should automatically be redirected to the next release when it opens [12:04] <Hobbsee> cjwatson: if they cant follow the rules, then why do they have upload rights? [12:04] <Hobbsee> mdz: indeed, ideally. although, then the changelog would be wrong, etc. [12:04] <cjwatson> Hobbsee: if everyone followed all the rules, we wouldn't need archive admins [12:04] <mdz> Hobbsee: "trust, but verify" [12:05] <Hobbsee> cjwatson: yeah, well. there is that. [12:05] <mdz> Hobbsee: the changelog is already non-authoritative (e.g., syncs) [12:05] <Hobbsee> mdz: true [12:05] <cjwatson> mdz: although it's easy to tell in the case of syncs that it's non-authoritative, because the distribution doesn't match a valid Ubuntu one [12:06] <cjwatson> mdz: with your proposal the property that if you see an Ubuntu release name then it probably means what it says would be greatly diluted [12:06] <mdz> cjwatson: I'd argue that with PPA that's unavoidable anyway [12:06] <mdz> the changelog has never been the right place for that information [12:07] <mdz> the destination of the upload is independent of its contents [12:07] <Hobbsee> mdz: s/ubuntu release name/ubuntu release name and ubuntu version/ then [12:07] <cjwatson> but it is awfully convenient as such [12:07] <cjwatson> I think PPA should be gutsy-ppa etc., in fact [12:08] <cjwatson> mdz: it slows investigation down greatly if one has to go to the network all the time [12:08] <mdz> cjwatson: what type of investigation? [12:08] <cjwatson> mdz: investigation of problems and roughly when they appeared, correlating with bug reports [12:09] <cjwatson> e.g. if a reporter says a problem appeared in feisty, you grep back for feisty in the changelog [12:09] <Hobbsee> cjwatson: but hey, at least we've lost the binary mangling, i think. [12:09] <Hobbsee> cjwatson: (on ppa's) [12:09] <cjwatson> sure, I could go to Launchpad and ask for the exact versions, and sometimes I do that later [12:09] <cjwatson> but the changelog is an incredibly convenient local cache which is much faster to search [12:09] <cjwatson> and I think it is useful to put some effort into maintaining it for that purpose [12:09] <mdz> cjwatson: how about if the changelog for binary packages was generated at build to reflect where it was actually uploaded? [12:10] <cjwatson> mdz: when I'm doing this kind of investigation I usually already want to have the source package in hand, so no, I'm afraid I would just find that hopelessly confusin [12:10] <cjwatson> g [12:11] <mdz> cjwatson: I don't like the guessing game that folks have to play about whether the archive admins have time to process a new package [12:11] <mdz> there should be a clear cutoff, and packages which meet the cutoff should be processed [12:12] <Hobbsee> mdz: ..there is. [12:12] <cjwatson> mdz: I have no argument there, but I do not agree that the corollary of doing some weird automagic with whatever remains follows from that [12:12] <mdz> Hobbsee: https://wiki.ubuntu.com/NewPackagesFreezeUniverse [12:12] <Hobbsee> mdz: but there are exceptions for important stuff afterwards? [12:12] <mdz> Hobbsee: "Note: This means you should upload new packages in time for them to get reviewed by the archive admins and moved into the archive before this day." [12:13] <Hobbsee> mdz: yeah. should. [12:13] <cjwatson> I think the short-term benefits to uploaders of doing that are more than offset by the long-term detriment of confusion [12:13] <Hobbsee> mdz: our sponsorship team isnt big enough to get everything reviewed ages before the freeze - particularly if we were to go thru sync requests, etc, by that time too. [12:14] <Hobbsee> mdz: certain people like floodbombing the sync queue. [12:14] <mdz> Hobbsee: once the deadline has passed, the archive admins should clear out the backlog and not process any requests received after the deadline [12:14] <cjwatson> Hobbsee: in this case, I think the cutoff should be in terms of when the exception is granted and the package uploaded, not in terms of when it is processed [12:14] <Hobbsee> cjwatson: indeed - and when are you proposing this cutoff? [12:15] <Hobbsee> cjwatson: afaik, this already happens, for NPF. [12:15] <cjwatson> Hobbsee: the point where the new package freeze currently sits is fine [12:15] <cjwatson> Hobbsee: it's just that the documentation makes it hopelessly unclear, and so we have to have the debate about what it means every release [12:16] <Hobbsee> cjwatson: so in that case, the one that mdz ack'd last night - that should never go in? [12:16] <Hobbsee> cjwatson: true. hopefully it will get fixed near UDS> [12:16] <mdz> Hobbsee: no, we're not talking about changing the process for exceptions, only about what happens at the cutoff [12:16] <cjwatson> that sounds like an explicit exception granted by a member of the release team (or its superior, the technical board), to me [12:16] <mdz> things submitted before the cutoff shouldn't be rejected due to lack of time [12:16] <mdz> if there isn't enough time, the freeze should be moved earlier [12:17] <Hobbsee> mdz: then more exceptions get filed about massively important packages (supposedly), and the problem is still there. [12:17] <mdz> cjwatson: what that was was a correction of terminology which was interpreted as an exception because the terminology used was consistent with what the release team apparently expect [12:17] <ScottK> Hobbsee: We just say no more then. [12:17] <Hobbsee> mdz: as far as i'm concerned, the NPF / UVF thing works fine. it's just the number of exceptions that go thru. [12:18] <ScottK> That and the undocumented exceptions. [12:18] <Hobbsee> mdz: (modulo syncbombs) [12:19] <cjwatson> Hobbsee: anyone in an exception-granting team who isn't comfortable saying no quickly shouldn't be in that team [12:19] <Hobbsee> cjwatson: indeed. i dont think we have that problem [12:19] * Hobbsee is starting to suspect that we're all arguing over different things. [12:20] <lamont> Hobbsee: it sounded to me like you were grumbling about people mailbombing the sync queue [12:20] <ScottK> lamont: That happened. We had 3 or 4 MOTUs working full time to clean up the mess left by one guy. [12:20] <Hobbsee> lamont: that was a side issue. [12:20] <lamont> pathological cases are _ALWAYS_ the more interesting [12:21] <Hobbsee> lamont: the guy has been roasted repeatedly, and if he dares to do it again next cycle....he's going to get officially roasted, or the sponsorship team will all stop processing things. or something equally bad. [12:23] <mdz> Hobbsee: so if you leave the freeze where it is, but the admins agree to process the backlog, you shouldn't get any additional exception requests, and the confusion would be resolved [12:24] <Hobbsee> mdz: should not, yes. is it actually always motu-uvf's call about whether the exceptions get granted, or can ubuntu release team, and yourself step in and grant exceptions at will? [12:24] <Hobbsee> mdz: i think that's the real issue here [12:24] <ScottK> mdz: We'll certainly get requests. We'll just say no in virtually all cases. [12:25] <ScottK> Hobbsee: I'd say that they can grant exceptions at will. The question is more if they should. [12:25] <cjwatson> Hobbsee: in the same way that ubuntu-core-dev can upload to universe and multiverse, the Ubuntu release team and technical board can make decisions about universe and multiverse (but will not normally do so since the routine practice is delegated) [12:26] <Hobbsee> cjwatson: fair enough. ScottK, i'd suggest you document that somewhere. [12:27] <ScottK> Hobbsee: Suggestions on where? [12:27] <ScottK> I agree with it too. [12:27] <Hobbsee> ScottK: motu ML, perhaps. [12:28] <mdz> Hobbsee: it's a motu decision (apparently delegated to motu-uvf), which could be appealed to the release team or ultimately the tech board if there is contention [12:28] <mdz> (or some other exceptional circumstances, like an urgent request when the right people are not available) [12:28] <ScottK> Agree with that. It just hasn't always happened that way. [12:29] <mdz> ScottK: it was not my intention to make a decision on the request; I was confused by the terminology [12:29] <mdz> ScottK: which I think needs a lot of cleanup (hence my discussion with pitti about it) [12:29] <Hobbsee> mdz: would have thought you'd give it 24+ hours and such. but OK. [12:29] <ScottK> mdz: Agreed on the fact that the current situation is confusing. [12:30] <pitti> still waiting for some answers on the ML before I actually change it [12:30] <Hobbsee> pitti: the freeze stuff? [12:30] <Hobbsee> yes, i need to reply to that. [12:30] <Hobbsee> (as the head of universe sponsorship queue [12:30] <Hobbsee> ) [12:31] <ScottK> pitti: I also think that we need a documented spot for all of the distro release specific exceptions. [12:31] <pitti> ScottK: agreed, and that's the plan already [12:32] <pitti> ScottK: once we agree to the set of freezes, the links behind them will give details [12:32] <ScottK> OK. [12:32] <pitti> ScottK: and FreezeExceptionProcess, of course [12:32] <ScottK> In particular, there is a set of packages for UME that has a standing exception. Which packages those are won't be clear to people not involved in UME. -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
