17:01:54 #startmeeting 17:01:54 Meeting started Thu Feb 4 17:01:54 2010 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:59 #topic Roll call! 17:02:40 sound off 17:02:44 off 17:02:46 heh 17:03:07 * poelcat here 17:03:49 I see ctyler, dgilmore, mdomsch, and walters_ also 17:03:52 hello everyone 17:04:22 * ctyler here 17:05:05 spot will not make it today -- as hopefully everyone knows by now, he and his wife just had their first child this past weekend 17:06:01 *good thing* he's not here, then! 17:06:09 dgilmore mdomsch Are you guys here too? 17:06:10 * dgilmore hopes he is not here 17:06:12 ha 17:06:14 stickster: i am 17:06:17 Good on ya mate 17:06:54 * mdomsch is here 17:07:02 OK, it's 12:05. I want to proceed with one item for a maximum of 15 minutes, and then we'll go to Q&A 17:07:12 #topic regional localized spins 17:07:29 #link http://lists.fedoraproject.org/pipermail/advisory-board/2010-February/007900.html 17:08:06 I generally think "meh, why bother?" with this but realize that I don't have this problem so it clouds my judgement. 17:08:14 * dgilmore thinks that they are fine and necessary. but i think that teams in the region they are intended for should be responible for producing and distributing them 17:08:17 I think the questions are really: 17:08:52 mmcgrath: yeah i agree on the latter 17:08:58 1. Can we give a special blanket approval to spins that only change default language/regional settings? 17:09:02 apologies for being tardy. sick kids 17:09:20 jwb: No problem 17:09:27 2. Where should those spins be hosted? 17:10:10 3. who makes them? rel-eng or someone else? 17:10:19 stickster: one question I'd ask are these spins a convenience or is there really something inadequate with the anaconda language selection? 17:10:31 and can we solve it differently? 17:10:45 mdomsch: I would say that if the answer to (2) is not on our official space, then the answer to (3) is not rel-eng. 17:10:48 (note that opensuse & ubuntu use a translated grub screen to start the install) 17:10:55 stickster, agreed 17:11:11 mdomsch: how does that work? 17:11:19 2) I suspect we _can_ host them on FI space, just not the mirrors 17:11:20 mmcgrath: big issue is that the spinds being livecds boot into english. if yo dont know any english then you might have trouble to change it to your native language. and it has nothing to do with anaconda 17:11:31 On (1), two questions arise from the word "only" -- (a) what is the base for the comparison? The Desktop spin? and (b) what if there are some packages that are needed because of regional settings, e.g., for input methods? 17:11:56 mmcgrath, not sure exactly, but the grub boot screen is translated IIRC 17:12:21 how have the other distros solved this problem? 17:12:27 mdomsch: at least some of the use cases i can think of finding local hosting inside the target countries is financially better as international links can be very expensive 17:12:30 dgilmore: mmcgrath: The other question is which fonts and other input method related material is on the Live spin by default. 17:12:49 If there's not support for your language, then I'd imagine a new spin is very important to you when you go to local community groups handing out media. 17:12:54 stickster: right some spinds will need to add fonts/input methods 17:13:09 that's the part that concerns me more 17:13:17 there's actually a fair bit on the default spin, but I'm sure it's not exhaustive 17:14:21 * poelcat thinks we are getting off track... answer one question at a time? :) 17:14:39 yeah agreed... 17:14:45 personally, i think question 1 is the only board-level question 17:14:52 poelcat: yeah, perhaps we should put it this way: "Is anyone against us allowing language spins, but making the different local groups create and distribute them?" 17:15:14 mmcgrath: im all for that 17:15:20 mmcgrath, +1 17:15:22 +1 17:15:22 i'm for that as well 17:15:26 i'm not against it 17:15:56 then I say let them go forth and spin 17:16:02 what are the remaining *board* issues to discuss on this? 17:16:12 I have no problem with regional groups making minimally altered spins for use in their locale, but I think those spins *must* still go through the Spins SIG 17:16:30 stickster, agreed 17:16:34 just to clarify, they can alter package sets etc. in addition to local settings, with no Q&A? 17:16:35 In other words, we don't have a concern about trademarks, as long as the Spins SIG feels the changes are minimal, to support local language. 17:16:46 stickster: +1 17:16:46 stickster: agreed as well... use existing established processes 17:16:56 +1 from me 17:16:57 ctyler: I would limit that only to required fonts or something directly in support of the local language 17:17:35 ctyler: fonts and input methods 17:17:37 And when I say "limit," note that I mean "limiting the blanket approval," not "limit what people can remix in general" 17:18:06 getting the Spins SIG to approve solves that -- we can give a blanket trademark approval and the Spins SIG can decide how much can change and whether there's a QA issue 17:18:27 ctyler: sounds reasonable 17:18:49 yep - each still needs to go through the Spins SIG 17:19:24 * poelcat notes 3 minutes left on this topic 17:20:01 So the answer to 1. is "Yes, the Board will give a blanket TM approval for regionally-produced spins, provided that 17:20:46 a. The changes are only those required to serve language and font settings, including font packages, and 17:21:06 b. The Spins SIG approves the spins on a technical level to assure (a). 17:21:07 " 17:21:12 Is that correct? 17:21:15 +1 17:21:40 +1 17:21:41 stickster: yep 17:21:42 +1 17:21:42 +1 17:21:42 yes 17:21:45 +1 17:21:50 OK, thanks everyone. 17:22:06 +1 sorry 17:22:10 that went to a pm on accident :) 17:22:12 Now we are at the end of 15 minutes and there seems to be a consensus that the Fedora Project is not required to host these spins 17:22:25 well 17:22:28 But no clear decision. 17:22:42 i think there is consensus that it's not a Board level issue 17:22:46 :) 17:22:47 not required to - I agree; may be able to though. 17:22:56 right, that's FI 17:23:15 * stickster can clear (2) off the agenda then 17:23:20 Regional 17:23:23 oops 17:23:53 Give me a second, copy/paste slowness 17:24:10 #agreed , the Board will give a blanket TM approval for regionally-produced spins, provided that (a) The changes are only those required to serve language and font settings, including font packages, and (b) The Spins SIG approves the spins on a technical level to assure (a) 17:24:49 #agreed The Board leaves the question of hosting to any regional creators to work out with the Infratructure and rel-eng teams 17:25:04 Shall we move on? 17:25:09 please 17:25:21 #info caillon cannot make it today and sends his regrets 17:25:26 #topic Community Q&A 17:25:39 wait, did we address (3)? 17:25:44 do we need to? 17:25:59 ctyler: the locale community does 17:26:02 ctyler, we did. 2 and 3 are up to FI and rel-eng 17:26:07 3) is a Spins SIG <-> rel-eng problem IMHO 17:26:11 right 17:26:17 right. 17:26:30 at such a point when that can't be resolved, they'll kick it up 17:26:33 right. 17:26:39 sounds reasonable, just wanted to ensure we were in agreement 17:27:21 #agreed The Board leaves question about production to regional creators to work out with Spins SIG and rel-eng 17:27:52 * stickster awaits questions in other channel. 17:28:01 We'll leave the line open for a few minutes 17:28:07 jwb: Go ahead, you raised a hand over there. 17:28:38 Has everyone seen the thread on the devel list about the target audience? 17:28:49 Has anyone *not*? 17:28:58 right :) 17:29:13 so something that has come up there is the idea behind conflicting package changes 17:29:25 we've disallowed this basically forever 17:29:44 is that something we should revisit in light of allowing more flexible remixing? 17:29:59 So the question is, should we allow conflicting package changes? 17:30:15 yes, basically 17:30:30 jwb: FESCo decided on that question specifically or are they looking at things one conflict at a time? 17:30:32 so what would that look like, in practical terms? 17:30:34 jwb: i'd have to scroll through the thread again, but concretely do you mean Conflicts: or multiple shared library versions? 17:30:35 * mmcgrath forgets the history on that. 17:30:55 both right? 17:31:06 jwb: i think its an issue to be taken up with FESCo not the board 17:31:08 walters_, i think both 17:31:23 dgilmore: agreed 17:31:25 "but I _don't want to link against libnss" ... 17:31:44 dgilmore, in how it is implemented, possibly. i'm wondering if the higher level goal behind it is something the Board needs to look at 17:32:11 jwb: its a technical issue hence its a FESCo issue 17:32:28 if FESCo asks for assisatnce or guidence then we should look at it 17:32:37 fine. retracted 17:33:25 jwb: did you feel there was anything else for the board to discus around the devel thread? 17:33:32 I think it's a fair question to ask - how often have such "us vs them" conflicts arisen? if many, the board may wish to provide some additional guidance 17:33:40 There are some implications for people who end up on the receiving end of workload, like packagers, developers, and bug triagers. But it wouldn't work for us to start there before someone goes through the technical aspects. 17:33:45 poelcat, yes, i just asked exactly what i felt needed to be asked 17:34:33 i'm ok being wrong about it being a Board level issue 17:34:38 well we'll definitely be taking up the feedback during the next SWG meeting, right? 17:34:47 mdomsch: it's funny because those things are rare, but increasingly I think people think that's what the boards job is... and little else. 17:35:00 walters_: I would hope so 17:35:08 mdomsch: the whole surf conflict recently was the first i rember 17:35:22 dgilmore, i'm not talking about package names 17:35:42 If we're agreeing this is a FESCo question, we should move on. There are others in the queue. 17:35:47 yes, move on 17:36:03 Strangely, the next question is also from a Board member -- go ahead mdomsch 17:36:07 :-) 17:36:53 * mdomsch started a thread on advisory-board 17:36:58 #info Board does not take up the question of conflicting packages at this time 17:37:05 * stickster making better use of zodbot, sorry. 17:37:20 soliciting feedback. Basically, I want to have yum provide a uuid in mirrorlist requests, to improve our ability to count the number of Fedora installations worldwide 17:37:24 and over time 17:37:53 our "unique IP address" metric is undercounting by, at my guess, at least 2x, probably closer to 6x 17:38:10 mdomsch: only if its opt-in 17:38:23 in my proposal, it's opt-out 17:38:29 mdomsch, i'm concerned about opt-out 17:38:34 smolt is opt-in 17:38:54 opt-in will leave us with the status quo 17:38:55 there's not great way to do opt-out without some kind of 'firstboot' like dialog for yum/PK 17:38:56 at best 17:39:05 mdomsch: opt-ot is not acceptable 17:39:09 opt-out 17:39:16 mdomsch: it has to be opt-in 17:39:25 dgilmore: why? 17:39:36 dgilmore: why? no trackable info here, really 17:39:55 I think we should get expert legal advice on what these sorts of records mean, both here and other places like the EU 17:40:07 ctyler, that's not entirely accurate. it's trackable, but it's certainly not _easy_ to track an individual 17:40:30 stickster, agreed 17:40:32 stickster: yeah i don't feel i have a solid grasp of what standard practice is here 17:40:41 How would you track a UUID back to a person? 17:40:50 ctyler: it would be possible to track. not trivially so but it would be possible 17:40:54 You could trace it to an IP as I understand the problem mdomsch set out 17:40:57 mdomsch: what were you intending to record? just a DB of UUIDs that have been seen before? 17:41:24 Then you *probably* could check other requests from that IP around the same time to see what was happening, i.e. wiki edits and from whom they came 17:41:49 In order to do that, you would have to be somewhat of a trusted contributor yourself 17:41:52 this is a slight derailment now... 17:41:58 jwb: Yes, sorry. 17:41:59 stickster: you can also track the different ips used by that UUId and work out travel patterns etc 17:42:23 mdomsch: How about you and I round up with the right legal folks to ask specific questions? 17:42:24 I personally feel it needs to be opt-in 17:42:25 dgilmore: "you" being a mirror server? 17:42:34 stickster, yes please 17:42:37 dgilmore: I think opt-in makes it just as useless as what we have now, and thus pointless. 17:42:38 I personally don't care if the uuid gets added, but I find myself being paranoid for people before they even raise a stink about it because of what I went through with smolt. 17:43:05 mmcgrath: Understood, I agree it's a concern. I don't want to see us sink a bunch of effort into something that's not going to get us better information. 17:43:18 there are 2 standards here; 1) legal; 2) what our community expects 17:43:30 we need to address 1) with the right people 17:43:40 2) we need to address as well, hopefully via fab 17:43:48 i guess i feel what we need to do in the big picture is strongly encourage people to interact with fedora 17:43:49 With 1) we can do 2) more readily. 17:43:56 yes 17:44:02 I don't think you want to track anything (IPs included) except the fact that you have seen a particular UUID. Not evern *when* you saw that UUID. 17:44:03 like with smolt, we don't clearly explain the benefits of sending the data 17:44:07 stickster: I think it would accomplish what mdomsch is trying to accomplish though. 17:44:21 mmcgrath: *nod 17:44:38 * poelcat would still like understand why dgilmore says "has to be opt-in" + why decision was made to make smolt opt-in 17:44:45 ctyler, implementation-wise, we currently build a map of "checkins over the last 7 days" 17:44:56 poelcat: You might want to go back and check the archives of FAB (?) for smolt discussions 17:45:03 poelcat: I made smolt opt in to because I got tired of people complaining about it. mdomsch might have a stronger will than I :) 17:45:05 It was fairly extensive 17:45:08 mdomsch: tied to what? IP? 17:45:17 ctyler, yes, as that's all I've got to go on 17:45:31 so if you do UUID, would you drop IP? 17:45:36 OK, I think we've answered mdomsch's question, which is "What shall we do?" 17:45:47 ctyler, no; need IP to generate the map (geoip) 17:45:53 poelcat: because, in the event of a malicious user/event. with the right data you could track a users travels and who he is via it 17:46:11 #agreed mdomsch and stickster to talk to legal counsel about a revised statistics gathering method 17:46:31 #agreed mdomsch and stickster to bring that information back to FAB for more discussion and, if applicable, planning 17:47:01 stickster: can you ask about whether it has to be "opt-in" too? 17:47:11 poelcat: certainly 17:47:27 * ctyler is a lot less comfortable with IP+UUID then IP or UUID by itself 17:47:27 #info mdomsch and stickster will set up a list of specific questions through FAB so we can gather the right ones. 17:47:33 Let's move on 17:47:44 We can focus on specifics on the lsit. 17:47:46 *list 17:48:44 The question queue is currently empty. 17:48:58 I thought maxamillion had one 17:49:22 BobLfoot: Go ahead, you had a question 17:50:23 BobLfoot: ? 17:50:34 OK, we'll come back to him. 17:50:44 maxamillion: Go ahead, you had a question 17:51:46 maxamillion: ? 17:52:24 our discussion of esoteric privacy issues made everyone else look away from the chat apparently =) 17:52:57 eyes glassed over everywhere, it seems 17:53:12 Should I just paste it in, and we'll have at it? 17:53:19 sounds good 17:53:51 maxamillion asked, What is the specific, defined, and concrete end goal that the Board hopes to obtain with its current working group meetings? 17:53:51 s/obtain/achieve 17:55:36 (1) a clear set of proposals for ways to improve our focus on a useful product that people want to use, as part (but not all) of what the Fedora Project does 17:55:59 * poelcat thought we set some of that in our first meeting 17:56:11 poelcat: yes, got a link handy? 17:56:21 * stickster is paraphrasing from memory which is probably not as helpful 17:56:48 basically address everything here: https://fedoraproject.org/wiki/Unfinished_Board_issues 17:56:56 the approach was 17:57:04 1) SWG add items to page 17:57:13 2) solicity community feedback (there was none) 17:57:27 3) work through issues and make formal proposals to board as a whole 17:57:41 4) when page is empty/done... SWG disbands 17:57:44 17:58:04 right now we are on step #3 17:58:24 Thanks poelcat 17:58:55 at a high level i see the SWG as a positive thing, trying to find and create rough consensus and refine existing structure, and I hope maxamillion doesn't continue to see it as a negative thing 17:59:17 The ultimate goal is *not*, as it's been misstated, to disenfranchise people or devalue their contributions 17:59:22 right 18:00:17 to be clear the SWG does not make decisions for Fedora or the board as a whole 18:00:18 in my personal view, the SWG exists because the Board has more work than a weekly meeting can accommodate and not everyone can always make time for more than one meeting 18:00:19 * stickster reminds everyone that repeatedly in the past, conflicts have arisen (and continue to do so) where there's no clear rationale for deciding them, software being one of them 18:01:09 jwb: yes, that is why i originally proposed it 18:01:10 We'd like to reduce that problem 18:01:21 the SWG is an accelerator, a way to spend more effort on some issues that have been around for a long time, progressing very slowly 18:02:17 In part because the Board handles other issues as well, and sometimes being acountable to the community in the short term was causing us to lag on more long-term work. 18:04:44 ultimately, I want to grow our contributor base, and grow our user base 18:05:09 is this a wrap for today? 18:05:31 I think we've finished, there are no more questions in the queue. 18:05:51 #info SWG background is found here: https://fedoraproject.org/wiki/Unfinished_Board_issues 18:06:15 OK, I'm going to end the meeting in 15 18:06:32 5 18:06:34 3 18:06:35 2 18:06:36 1 18:06:38 #endmeeting