Re: Readjusting SRU review process
On Thu, May 23, 2013 at 03:00:01PM -0700, Brian Murray wrote: Given that Launchpad API doesn't expose a way to contact users, what would be the best way of sending the uploader of a package being rejected email? Ideally, fixing https://bugs.launchpad.net/launchpad/+bug/31750 would be the right answer to this, rather than having the API expose a field for who to contact on reject and having your (possibly broken) local MTA send an email out of band. CCing William to see if we can get an estimate on the horror involved in tacking a -m'Message' on to rejecting packages, and then you can just use that. ... Adam -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Readjusting SRU review process
On Fri, May 24, 2013 at 05:19:14PM +0200, Martin Pitt wrote: Brian Murray [2013-05-24 8:00 -0700]: Having said that, I currently don't reject things because there is not a good way to communicate the reason for rejection to the uploader. Why is following up in the bug not a good way? Following up in bugs is fine for SRUs, since they're all meant to be tied to bugs anyway. This isn't true for, say, things in the NEW queue, however. And, even in the SRU case, you might have an SRU that addresses 24 bugs: which one do you follow up on? All 24? The first in the list? The one that seems most relevant to the problem you found with the upload? At any rate, I'm having StevenK work on getting Soyuz to allow for a rejection comment, and from there, we can let the debate drop, since we'll be able to do rejection comments or, if you prefer, you can follow up to a bug, and have the rejection comment be: https://bugs.launchpad.net/ubuntu/+source/foo/+bug/1234/comments/5 That should address use-cases in both directions, while allowing the uploader to get a proper reject response with some information that doesn't mean they need to hunt through all 24 linked bugs for their excuse. (And, while I usually do the ping on IRC thing myself, this is also one thing that stops me from rejecting packages, as not everyone keeps the same IRC hours as I do and, shockingly, some people are offline when I try to contact them, async communication is definitely better in this case). ... Adam -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
m...@ubuntu.com broken
I expired out of ubuntu-core-dev, which apparently caused me to be removed from ubuntumembers (techboard isn't in ubuntumembers). This has caused m...@ubuntu.com to start bouncing, which is the email address I used to subscribe to technical-board@lists, so I'm no longer receiving tech board email. I don't require upload privileges at the moment but would like to retain membership status. What's the best way? -- - mdz -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies
Colin Watson [2013-05-27 15:22 +0100]: It's a UK bank holiday today, so I won't be around this evening. I believe it's a US public holiday too; should we defer the meeting? WFM; the only pending topic that I can see is the discussion of the OpenSSL licensing issue (which we already deferred last time because you couldn't attend, so it would be pointless to try and discuss it today when you also cannot attend). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies
On Mon, May 27, 2013 at 04:27:20PM +0200, Martin Pitt wrote: Colin Watson [2013-05-27 15:22 +0100]: It's a UK bank holiday today, so I won't be around this evening. I believe it's a US public holiday too; should we defer the meeting? WFM; the only pending topic that I can see is the discussion of the OpenSSL licensing issue (which we already deferred last time because you couldn't attend, so it would be pointless to try and discuss it today when you also cannot attend). I suspect that is at least in part overtaken by events anyway, since I hear MongoDB upstream has added / is adding an exception. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Readjusting SRU review process
Steve Langasek [2013-05-24 13:19 -0700]: There are definitely times when I have a sense that the SRUs in the queue are not the best use of our time. Every developer has their own idea of what's important enough to SRU, and it's difficult as an SRU team member to be in the position of arbitrating, and rejecting uploads because /you/ don't think they're important. It's also difficult to actually /know/ what's important enough for an SRU when it's sitting in front of you in the queue - some of this only shows up in aggregate after the fact, when we see that -proposed is full of packages that no one has bothered to verify. That's actually a very good point. It seems that over time we have become rather lenient about which kind of fixes we allow as SRUs. My gut feeling is that the current level is just about right for LTSes, but especially with the deemphasized role of the non-LTS releases we should perhaps set the bar much higher again for those? We've tried to mitigate this with stricter enforcement of the requirements around test cases Having those is great, but a separate issue from the severity of bugs. but it seems there is still a big gap between the resources for preparing SRUs and the resources for validating them. Maybe we need to start pushing for self-verification of SRUs more aggressively? With defined test cases, this is less risky than in the past, and if SRU uploaders were explicitly expected to do the verification (if no one else does), then that could help reduce the problem of fire-and-forget SRUs clogging up -proposed with no one to verify them. We have done this in the past for cases where verification for other people proved hard/impossible, like for rare hardware. I don't think that self-verification is a bad thing when being documented properly. It's not even the primary concern for SRUs, as we most importantly need to avoid regressions in them, not necessarily be completely sure that all of the referenced bugs are 100% fixed (as we can always do a followup SRU). My feeling is that having fewer SRUs (for the non-LTSes) altogether would go a long way in raising motivation again; what's your feeling about this? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Catch up with the CC Thursday 30th May
Hello fellow TBers, Laura Czajkowski [2013-05-27 10:06 +0100]: We'd like for some representatives of your board to join us at our next meeting for this on Thursday, 30th May, 2013 at 17:00 UTC. I'm on holiday and in the mountains this Wed to Saturday, so I cannot join this. Does anyone else have time? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
