MOTU Process discussion on #ubuntu-devel

[Scott Kitterman]

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.