21:09:00 <stgraber> #startmeeting Ubuntu Technical Board meeting
21:09:00 <meetingology> Meeting started Mon Jan 23 21:09:00 2012 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.
21:09:00 <meetingology> 
21:09:00 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
21:09:18 <stgraber> #topic Action review
21:09:37 <stgraber> kees: so keeping "kees to perform brainstorm review" for an extra two weeks then? :)
21:09:53 <kees> yes please. *sheepish*
21:10:06 <stgraber> #topic Harmonizing DMB membership expiring dates (tumbleweed)
21:10:08 <stgraber> tumbleweed: around?
21:10:13 <tumbleweed> hi, yes
21:10:17 <stgraber> hi!
21:10:34 <tumbleweed> it looks like you've mostly covered this on the list
21:10:35 * stgraber looks at ML logs
21:10:50 <tumbleweed> we just wanted to reduce the number of elections we need to do
21:10:50 <cjwatson> Mark acked this and I don't really see a reason to object personally
21:11:25 <stgraber> ok, I'll implement the change then
21:11:42 <tumbleweed> thanks, that was easy :)
21:11:59 <cjwatson> so just extend everything to 13 Feb
21:12:00 <cjwatson> ?
21:12:05 <cjwatson> (with various years)
21:12:33 <tumbleweed> that'd be great
21:12:49 <cjwatson> then it settles down to a nice rotation of four each year
21:13:09 <tumbleweed> except that laney just extended a year, so it'll be 3 and 5
21:13:09 <stgraber> #action stgraber to harmonize the DMB expiring dates  (extend bdrung to 2013-02-13 and micah, tumbleweed and then the two new members to 2014-02-13)
21:13:09 * meetingology stgraber to harmonize the DMB expiring dates  (extend bdrung to 2013-02-13 and micah, tumbleweed and then the two new members to 2014-02-13)
21:13:14 <tumbleweed> but I'm sure we'll have an early retirement or something
21:13:31 <stgraber> does that sound like what we want^
21:13:45 <cjwatson> that's ok by me
21:13:47 <micahg> stgraber: that should be 1 new member, I still need to file a mail to the TB ML about extending laney as well
21:14:06 <stgraber> micahg: oh, right
21:15:18 <Laney> anyone heard anything from persia yet?
21:15:55 <stgraber> ok, I quickly did it on LP: https://launchpad.net/~developer-membership-board/+members
21:16:03 <cjwatson> not I
21:17:22 <stgraber> haven't heard anything either. Wondering if we should deactivate his membership from the team to make things clearer, especially now that I just extended tumbleweed's term.
21:18:12 <Laney> I think that would be a good thing to do: ask him to check in with the TB on his return
21:18:21 * kees nods
21:18:39 <stgraber> is everyone happy with that?
21:19:02 <cjwatson> it seems cognate with what we do for developers who go missing
21:19:09 <micahg> not happy, but understandable
21:19:18 <cjwatson> I think he will understand
21:19:25 <micahg> yes, indeed
21:19:35 <tumbleweed> if you could also squeeze in a decision on Laney extending his membership back to 2 years, it'd save us having to persuade him to nominate himself for re-election
21:19:47 <stgraber> yeah, I'm writting a "de-activation" message on LP and will e-mail him as well
21:19:59 <Laney> I thought the feeling was that it wasn't needed (as the original date was an error), but ymmv
21:20:06 <cjwatson> "back to 2 years"?  did you reduce it at some point?
21:20:21 <Laney> It was erroneously added as 1 year initially
21:20:26 <Laney> s/It/I/
21:20:32 <cjwatson> oh, fixing errors shouldn't require a TB vote surely
21:20:54 * micahg is sending the TB E-Mail momentarily for records reasons
21:21:08 <tumbleweed> micahg: thanks
21:21:22 <stgraber> Laney: right, that was an old mistake you asked us not to fix initialy?
21:21:56 <Laney> I wanted to delay deciding due to previous events
21:22:40 * Laney wonders how long that hob has been on and unlit for
21:22:57 <micahg> FTR, https://lists.ubuntu.com/archives/technical-board/2012-January/001171.html
21:23:42 <cjwatson> it's a bug if TB meetings blow up your kitchen
21:24:18 <stgraber> ok, bumped Laney's "expiry" to 2013-02-13 and de-activated Emmet's membership
21:24:25 <stgraber> I think that's it for the DMB?
21:24:57 <tumbleweed> yes, thanks
21:25:02 <stgraber> perfect
21:25:03 <Laney> cheers all
21:25:05 <stgraber> #topic Adjustment to backports upload policy (cjwatson)
21:25:21 <cjwatson> https://lists.ubuntu.com/archives/technical-board/2012-January/001166.html
21:25:45 <cjwatson> OK, so as I noted in the mail, I *think* this is an editorial change, but broder seemed to have a different reading so I wanted to make sure I was correct
21:26:32 * cjwatson gives people a bit to read
21:27:08 * micahg doesn't think uploading to -updates or -security directly should be allowed
21:27:38 <cjwatson> I don't think I was suggesting that as such
21:28:04 <micahg> no, but I think it might be able to be inferred :)
21:28:06 <cjwatson> ubuntu-security is currently a celebrity though and I think that ought to eventually be fixed
21:28:07 <kees> Yeah, I think whitelist would be better than blacklist here. "Uploads to all pockets: ~ubuntu-core-dev for all components"
21:28:17 <kees> i.e. not -updates and -security
21:28:31 <cjwatson> anyway, none of this supersedes the general prohibitions on uploading to certain pockets
21:28:33 <kees> just a language change, I'm fine with the intent
21:28:38 <cjwatson> I can clarify that explicitly in the LP bug if needed
21:28:41 <kees> right, cool.
21:29:20 <mdz> I'm not sure I follow
21:29:38 <mdz> are you saying that you want the policy to remain the same despite the underlying technical restrictions changing?
21:29:41 <cjwatson> mostly I just wanted to make sure that the TB hadn't intended to prohibit -backporters from uploading to backports; that's what Evan writes in his report of the relevant meeting, but it contradicts my memory of my intent
21:29:45 <cjwatson> no
21:29:51 <cjwatson> s/my intent/our intent/
21:30:57 <cjwatson> in general, I want to make it easier for ubuntu-backporters to do things that currently only ubuntu-archive / ubuntu-core-dev (variously) can do
21:31:04 <cjwatson> where it pertains to the backports pocket
21:31:08 <mdz> makes sense
21:31:52 <stgraber> having the backport team be able to manage their pocket and upload to any component of it sounds good to me.
21:32:34 <Laney> the bug is more general because AFAICT that is how the feature in LP should be. It'll be a separate decision for the TB to decide which delegations to grant.
21:32:35 <cjwatson> specifically, relative to now, I want them to be able to manage queues for the backports pocket (agreed in last meeting, AFAIK uncontroversial), and upload to backports regardless of component (I thought we agreed this in the last meeting but it wasn't in the write-up, so I'm suggesting we make it explicit if everyone agrees)
21:33:09 <mdz> I don't remember that discussion...at the 9 Jan meeting?
21:33:20 <cjwatson> the write-up is written in terms of closing an anomaly which we believed to exist but which turned out not to exist, and therefore the write-up is confusing
21:33:32 <cjwatson> at the meeting that coincided with UDS
21:33:48 <mdz> oh, so October
21:33:51 <mdz> I think I missed that meeting
21:33:58 <mdz> which explains why I'm confused
21:34:33 <mdz> I abstain
21:34:44 <cjwatson> November, I think - hunting logs
21:34:50 <cjwatson> http://irclogs.ubuntu.com/2011/11/03/%23ubuntu-meeting.html
21:35:09 <cjwatson> you were present
21:35:52 <cjwatson> http://irclogs.ubuntu.com/2011/11/03/%23ubuntu-meeting.html#t18:52 - ah, it was incomplete and finished next meeting
21:36:02 <cjwatson> http://irclogs.ubuntu.com/2011/11/17/%23ubuntu-meeting.html#t18:12
21:36:52 <mdz> yes, I believe I missed 11/28
21:36:57 <mdz> anyway, I don't want to hold things up
21:36:59 <stgraber> so basically the question is: do we agree that members of the backport team can upload to the backport pocket, whatever the component and without any relation to their upload rights to the release pocket?
21:37:30 <stgraber> anyway, that's a +1 for me
21:37:50 <mdz> +0, I'll support the consensus
21:38:28 <cjwatson> stgraber: yes.  I'm sorry that this seems to require set theory notation to express clearly :-)
21:39:31 <stgraber> kees: ?
21:39:44 <cjwatson> my position is basically that the backports team has by this point a long track record of responsibility and we should let them get on with it :)
21:39:49 <cjwatson> so +1 in case that isn't obvious
21:43:27 <stgraber> hmm, looks like we lost kees, quickly scanning the mailing-list for things we might have missed
21:43:47 <kees> +1
21:43:54 <stgraber> kees: thanks
21:44:51 <stgraber> #agreed Backport team is allowed to upload to the backport pocket in any of its components whatever the person's upload rights to the main archive are
21:44:59 <stgraber> #topic tmpfs for /tmp
21:45:35 <stgraber> we received: https://lists.ubuntu.com/archives/technical-board/2012-January/001167.html
21:46:05 <stgraber> is that something we want to discuss now or should discuss by e-mail/bug report?
21:46:48 <kees> I've been against a tmpfs /tmp because it doesn't seem to really solve anything.
21:46:52 <stgraber> I vaguely remember us (or maybe another distro, I said vaguely ...) mounting /tmp as tmpfs if / was full or close to being full but can't find any trace of that on my system, so maybe it disappeared (or I was just dreaming)
21:47:15 <cjwatson> I am nervous about that mail because it is definitely missing some things; the installer's partitioning rules would certainly need to be adjusted.
21:47:16 * soren stubmles in
21:47:19 <stgraber> as the guy who runs hundreds of containers on his machines, I'm definitely against tmpfs by default as it'd basically kill my system
21:47:31 <kees> stgraber: yeah, it to try to avoid apt/dpkg pain in the face of a full fs.
21:47:32 <soren> Gosh, I'm so sorry I (pretty much) missed this meeting!
21:47:34 <kees> no idea where that went
21:47:44 <cjwatson> stgraber: it used to exist in Ubuntu; Ian added t, I think
21:47:47 <cjwatson> *it
21:47:56 <cjwatson> "mountoverflowtmp" or some such?
21:48:16 <cjwatson> but I think that's mostly sideways to psusi's proposal
21:48:27 <stgraber> cjwatson: yeah, looks like we might have lost it with the switch to mountall?
21:48:53 <stgraber> (I quickly scanned /etc and mountall's code for anything related to tmpfs and couldn't find a trace of it)
21:49:05 <cjwatson> the initscripts changelog says it was replaced by an upstart job
21:49:36 <stgraber> which apparently got dropped (or my grepping skills disappeared recently)
21:49:46 <cjwatson> I'm kind of -0.5 on this because I don't feel the system performs well in some cases when tmpfses fill up
21:49:53 <cjwatson> but I don't have a clear written-up rationale
21:50:28 <cjwatson> some people with particular system use models seem to prefer it and I certainly think it should be a supported model
21:50:38 <stgraber> I know some of my systems (most?) would start crashing if they were using tmpfs (obviously depending on what gets written to /tmp)
21:50:54 <micahg> also, /run is already a tmpfs
21:51:10 <cjwatson> but I find myself unable to support it as the default
21:51:30 <stgraber> my understanding is that it's essentially a one line change in /lib/init/fstab (or through /etc/fstab) to change the fstype from "none" to "tmpfs"
21:51:31 <cjwatson> micahg: right, but the bug is specifically asking for /tmp, not just for tmpfses to exist
21:51:58 <micahg> right, I was just pointing out the decreasing need for such a thing as stuff is being migrated to /run
21:52:12 <stgraber> micahg: yeah, so far I haven't seen a badly written piece of software fill up my /run though I definitely did for /tmp, /run is pretty new, I'm sure it'll come :)
21:52:15 <cjwatson> micahg: I'm not sure I agree, but in any case I think it's moot :)
21:52:25 <micahg> oh, sorry for the noise then :)(
21:52:44 <cjwatson> stgraber: lines in /etc/fstab for a given mount point will override /lib/init/fstab - people shouldn't ever need to change the latter
21:53:09 <cjwatson> I think this would benefit from e-mail discussion
21:54:16 <stgraber> agreed, then we can update the bug based on the outcome (and get rid of a pretty old bug potentially)
21:54:28 <stgraber> #topic Chair for next meeting
21:54:34 <stgraber> soren: ^
21:54:37 <soren> I guess that will be me :)
21:54:52 <stgraber> perfect
21:54:56 <stgraber> #topic AOB
21:55:18 <soren> I hope I don't triggers kees's OCD too hard :)
21:55:21 <kees> heheh
21:55:46 <stgraber> we can just move backward through the list of that helps kees' ocd :)
21:55:53 <cjwatson> odc
21:56:04 <kees> no need. :)
21:56:32 <stgraber> #endmeeting