Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-10/fedora-meeting.2009-07-10-17.00.html Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-10/fedora-meeting.2009-07-10-17.00.log.html Log below as well ---- 17:00:44 <jds2001> #startmeeting FESCo meeting 2009-07-10 17:00:45 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:00:53 <jds2001> FESCo meeting ping -- dgilmore, jwb, notting, nirik, sharkcz, jds2001, j-rod, skvidal, Kevin_Kofler 17:00:53 * nirik is here. 17:00:58 * sharkcz is here 17:01:01 * notting is here 17:01:02 * Kevin_Kofler is here. 17:01:04 <j-rod> here 17:01:14 * dgilmore is here 17:01:37 <jds2001> alright, full agenda today.... 17:01:52 <jds2001> #topic whot provenpackager application 17:01:57 <jds2001> .fesco 178 17:02:06 * jwb is here 17:02:18 <jwb> +1 to whot 17:02:22 <sharkcz> +1 17:02:26 <jds2001> I didn't see any objections on the list, +1 17:02:34 <j-rod> +1 17:02:43 <Kevin_Kofler> +1, no objections from me nor have I seen any from the sponsors 17:02:48 <nirik> +1 here. 17:02:54 <dgilmore> +1 i guess 17:02:59 <notting> +1 17:02:59 <Kevin_Kofler> I'd have liked more positive feedback, but we can't have everything. 17:03:18 <jds2001> Kevin_Kofler: that's about normal what we got. 17:03:38 <jds2001> #agreed whot provenpackager membership is approved 17:03:50 <jds2001> #topic critical path packages 17:03:55 <jds2001> .fesco 171 17:04:20 <jwb> jds2001, we approved this, so we're just re-reviewing? 17:04:24 * jds2001 honestly didnt have time to look at what changed. 17:04:30 <Kevin_Kofler> So we just approved this last time and now it's up again? 17:04:33 <jds2001> jwb: skvidal put it back on the agenda. 17:04:38 <Kevin_Kofler> Well, what's new is that there's now an actual list of packages. 17:04:46 <Kevin_Kofler> Which should have been there BEFORE we approved this in the first place. 17:05:11 * jds2001 not sure of what we do from here 17:05:14 <jds2001> skvidal: ping???? 17:05:25 <jds2001> is there something to do with this? 17:05:26 <jwb> i disagree with the BEFORE statement, but we already hashed that out last time 17:05:33 <Kevin_Kofler> The obvious absent from this list is a @critical-path-kde group. 17:05:46 <jds2001> Kevin_Kofler: the KDE SIG needs to make that. 17:05:54 <jds2001> and they're more than welcome to. 17:06:02 <Kevin_Kofler> I propose that the creation of a @critical-path-kde should be delegated to KDE SIG and will be taken up in the next KDE SIG meeting (probably July 21). 17:06:02 <jwb> Kevin_Kofler, it is absent, yes. so is the XFCE and any other spin group. which are defined by those SIGs 17:06:10 * nirik has toyed with doing a Xfce one... 17:06:18 <jwb> Kevin_Kofler, that was already in the proposal we approved 17:06:23 <jwb> you don't need to re-propose it 17:06:38 <Kevin_Kofler> Well, then what are we voting over? 17:06:42 <nirik> is it expected that @critical-path* groups all are under the same scrutiny? 17:06:45 <Kevin_Kofler> Should we just move on? 17:06:48 * jds2001 was wondering the same thing. 17:06:59 <jds2001> yeah, we have a full schedule 17:07:01 <jds2001> NEXT! 17:07:10 <nirik> yeah, next. 17:07:26 <jds2001> #topic bundling of cryptsetup with volume_key 17:07:37 <jds2001> .fesco 175 17:07:47 <Kevin_Kofler> +1 to allowing this, for the reasons I gave in the comments. 17:07:54 * mitr waves 17:08:02 <Kevin_Kofler> We can't require linking against a system version which doesn't exist yet. 17:08:08 <jds2001> -1, it needs to go in it's own package. 17:08:26 <dgilmore> -1 17:08:27 <jds2001> cryptsetup1.1 or the like. 17:08:37 <mitr> jds2001: That only adds work and does not help anything - it would still be me who maintains that package. 17:08:38 * skvidal apologizes for his lateness - flaky network 17:08:43 <j-rod> Get the system ver up to snuff instead 17:08:44 <Kevin_Kofler> Why? As long as there's no other user, what's the benefit? 17:08:50 <skvidal> I was not able tpo get to my irc proxy 17:08:56 <dgilmore> Kevin_Kofler: it needs to make it a system version 17:09:17 <Kevin_Kofler> That's the plan, but it needs time to get into cryptsetup upstream with a supportable API. 17:09:25 <nirik> mitr: is there urgency in getting this in? or can it not just wait for the update from upstream? 17:09:31 <Kevin_Kofler> Adding random APIs to system libraries isn't that great an idea. 17:09:43 <j-rod> Fwuw, the name volume_key is... Suboptimal... 17:09:45 <notting> i would strongly prefer we not ship something that requires a fork, if upstream is actively working on the functionality 17:09:57 <jwb> notting, agreed 17:10:02 <jds2001> yeah, i thought it was something for adjusting sound or something. 17:10:05 <mitr> nirik: I don't know eactly when new cryptsetup will be released (~10 work items), and volume_key package is necessary to develop dependencies (anaconda in particular) 17:10:13 * nirik just wonders what the hurry is. Is there some reason to get this in sooner than upstream is willing to add that functionality 17:10:33 <Kevin_Kofler> See mitr's comments in the Trac item. 17:10:38 <nirik> mitr: is upstream unresponsive? 17:10:38 <Kevin_Kofler> Anaconda needs it. 17:10:43 <mitr> notting: upstream will review the patch and perhaps request changes, there's not disagreement about the idea - this is not a long-term "fork" 17:10:52 <notting> that being said, the risks for security and bugfixes that would need applied seems identical whether it's bundled or unbundled 17:10:53 <mitr> nirik: Responsive, but not willing to cut a release just for me. 17:11:28 <Kevin_Kofler> If not releasing a stable release with a new feature and major new APIs within a few days is being "unresponsive", then there are a lot of "unresponsive" upstreams... 17:12:39 <nirik> mitr: and the fedora maintainer doesn't want to apply your patches for now before upstream does? 17:12:54 <nirik> is this cryptsetup-luks ? 17:12:57 <pjones> that's certainly not "unresponsive"; it's not unreasonable for upstreams to want to get to particular milestones before cutting releases. 17:13:04 <mitr> nirik: He wants to keep the Fedora package identical to the upstream package. yes, this is cryptsetup-luks. 17:13:05 <notting> nirik: changing the libraries abi locally in fedora would be bad 17:13:09 <Kevin_Kofler> pjones: That's kinda my point. :-) 17:13:14 <pjones> (that might be... responsible?) 17:13:17 <jds2001> pjones: of course not, i dont think anyone was ever claiming it was. 17:13:43 <pjones> so why can't we patch in stuff that's already been committed upstream? 17:13:59 <nirik> I was just asking the status of talking to upstream... :) 17:14:00 <mitr> pjones: It was not committed yet. 17:14:02 <jds2001> we should be able too, not sure why..... 17:14:02 <Kevin_Kofler> Upstream didn't commit this to their trunk yet, they have yet to review the new APIs. 17:14:12 <notting> mitr: is volume_key intended to be the only user of the new ap? 17:14:15 <notting> erm, api? 17:14:18 <pjones> and it's got APIs that get exposed? 17:14:26 <Kevin_Kofler> It's additions to a library. 17:14:30 <Kevin_Kofler> So of course there are new APIs. 17:14:38 <Kevin_Kofler> Which is the whole reason why the bundled copy is needed. 17:14:45 <mitr> notting: I don't know about anything else, but it could appear 17:14:46 <nirik> mitr: why not push out this change until it does land upstream? I know it's needed for anaconda, but can't they defer those changes? 17:14:53 <pjones> So that means somebody is going to code to those, and then upstream is going to change them before committing, and then we're going to have more bugs. 17:14:57 <notting> mitr: hrm, ok 17:15:05 <skvidal> is there someone here who works on anaconda? 17:15:20 <mitr> notting: I guess some proprietary sotware might want it - one more reason _not_ to make the API public until it is finished. 17:15:21 <Kevin_Kofler> pjones: That's exactly why it's not a good idea to just patch them in. 17:15:23 <notting> so, i think it's two questions - do we care about shipping the forked library, and if so, do we care if it's bundled in volume_key? 17:15:26 <Kevin_Kofler> And thus the bundled copy. 17:15:31 <mitr> nirik: There's not that much time left. 17:15:40 <pjones> Kevin_Kofler: well, that's why it's probably fine /once they've been accepted upstream/. 17:15:47 <pjones> but until then, it seems very premature. 17:15:55 <nirik> mitr: the world is about to end? 17:15:57 <notting> if we allow the forked library, i don't have any objections to shipping it bundled with volume_key (since nothing else will use it) 17:16:23 <jds2001> but could anything else benefit from these new API' 17:16:25 <jds2001> 's? 17:16:26 <Kevin_Kofler> Are we in a business to ban forked libraries altogether? 17:16:28 <mitr> nirik: No, I'll spend 3 days removing the cryptsetup-luks dependency. A net loss, IMHO. 17:16:29 <nirik> mitr: fedora releases every 6 months or so... if it doesn't happen this time, why not wait for next cycle? 17:16:34 <pjones> Really we want dlehman around for this discussion. 17:16:38 * jds2001 has a concern that it will end up de facto used. 17:16:45 <pjones> Kevin_Kofler: in general, yes. 17:16:46 <Kevin_Kofler> Libraries can fork just like any other project. 17:16:57 <Kevin_Kofler> And apps will rely on the forks. 17:17:00 <pjones> Kevin_Kofler: that doesn't mean it's not okay in some situations, but it is frowned upon, and rightly so. 17:17:10 <nirik> there is a cost to forks... and should be. 17:17:31 <nirik> mitr: removing the dependency how? moving all that code into your app? 17:17:58 <pjones> So I think there's another concern to be addressed. 17:18:16 <mitr> nirik: moving (and integrating cleanly). Right now I'd rather rather do that work than wait 6 months. 17:18:22 * jds2001 steps away for a few minutes. I propose like 5 more minutes on this topic...there's lots more :) 17:18:28 <pjones> mitr: you said they're not willing to cut a release for us, but they've also not accepted the patch yet. The former seems to be a separate issue from the latter. Is there a reason they haven't taken the patch? 17:18:53 <mitr> pjones: No specific reason I know about - lack of time/priority I guess. 17:19:23 <pjones> It'd really help to know if upstream likes or dislikes the patch. 17:19:26 <ianweller> w/ 45 17:19:28 <ianweller> oops. 17:19:47 <skvidal> pjones: +1 17:19:58 <dgilmore> pjones: agreed 17:20:18 <mitr> pjones: I'm 100% sure upstream will accept the functionality. 17:20:28 <skvidal> mitr: how can you be completely sure? 17:20:37 <pjones> sure, but "the functionality" and "the api change" aren't the same, and we need the stronger guarantee of the latter. 17:20:59 <mitr> Specifics of the patch are my responsibility anyway - both in talking to upstream, and in fixing the bugs that affect volume_key (even more so if it is bundled). 17:21:07 <mitr> skvidal: I talked to mbroz 17:21:20 <dgilmore> mitr: it should not be bundled at all 17:21:32 <skvidal> mitr: and you cannot talk to mbroz again and find out about the patch? 17:21:37 <pjones> bundling it is straight out bad. 17:21:42 <mitr> skvidal: I can't make him review it right now. 17:22:01 <skvidal> mitr: s/make him /ask him to/ 17:22:03 <pjones> well, we've got what, 18 days before it needs to be finished? 17:22:59 <notting> skvidal: mbroz is not cryptsetup upstream 17:23:04 <notting> (unless i missed something) 17:23:11 <skvidal> notting: then how does he know what they will accept? 17:23:13 <mitr> notting: recent change 17:23:43 * jds2001 back, sorry 17:23:46 <notting> mitr: he took over for clemens? 17:24:01 <mitr> notting: http://code.google.com/p/cryptsetup/source/browse/trunk/ChangeLog - mbroz releasing 1.0.7-rc1 17:24:15 <mitr> notting: Apparently, I don't know the exact arrangement. 17:24:39 <nirik> wow...thats a long gap in releases. 17:25:05 <jwb> so we don't know the upstream maintainer arrangement, they haven't reviewed the patch yet, but we're 100% sure it'll go in at some point 17:25:25 <mitr> jwb: If mbroz tells me he is upstream, I trust him :) 17:25:25 <skvidal> jwb: yes, that was my point :) 17:25:32 * jwb hums "one of these things does not belong here" 17:25:47 <mitr> jwb: "the functionality" will go in. "the patch" might not. 17:26:15 <pjones> right, but "the patch" is the thing it's helpful to know about. 17:26:20 <skvidal> and the patch - specifically the API is the issue we need to know about 17:26:22 <notting> proposal: table this for next week, pending further discussions with upstream? 17:26:25 <jds2001> this jsut strikes me as full of potential fail. 17:26:34 <jwb> notting, further logged discussions 17:26:35 <Kevin_Kofler> As I wrote in Trac: I propose we approve this, with the understanding that it's a temporary solution and efforts should be made to get the changes upstreamed into libcryptsetup ASAP. 17:26:36 <pjones> notting: I don't think I actually get a vote here, but +1 17:26:44 <jwb> notting, +1 17:26:46 <jds2001> what if we allow it, then the API's change, then our code is broken...... 17:26:47 <mitr> notting: What do you want to learn by net week in particular? 17:26:54 <Kevin_Kofler> notting: There's not much time. 17:26:59 <jds2001> seems like a viscious cycle of never getting rid of it. 17:27:02 <Kevin_Kofler> Wasting another week will hurt Anaconda. 17:27:10 <Kevin_Kofler> We should just approve this now as a temporary solution. 17:27:10 <notting> mitr: ... a timetable on when a frozen api will be available? 17:27:40 <notting> mitr: ... some sort of status on the patch, whether it's "ignored", "read", "reviewed", or "comittted" 17:27:48 <mitr> <mbroz> (translating) "Fedora will be the first one to have the new release, what more do you want me to say"? 17:27:57 <skvidal> Kevin_Kofler: making hasty decisions b/c of a potential schedule is a bad idea and a worse precedent 17:28:00 <mitr> (from earlier dicussion) 17:28:18 <jwb> mitr, when the release is. or even when the patch will be committed 17:28:28 <jwb> i think everyone would feel better with a committed change 17:28:35 <Kevin_Kofler> skvidal: It's being unable to provide important features due to useless bureaucratic delays which would be the bad precedent. 17:28:47 <pjones> mitr: or alternately if that API is what'll go in. 17:28:59 <jwb> pjones, yes 17:29:00 <skvidal> Kevin_Kofler: there's nothing useless or bureaucratic here - this is just planning 17:29:20 <skvidal> Kevin_Kofler: lest we end up having to REDO this AGAIN - or wose yet maintain a fork forever 17:29:31 <pjones> Kevin_Kofler: I don't think wasting another week will actually hurt us that badly, but really I need dlehman to be sure. 17:29:38 <pjones> Kevin_Kofler: my expectation is that he has other things he also needs to work on that this doesn't block, so it won't actually hurt us that badly. 17:29:47 <pjones> (I also don't think it's fair to call it "wasting another week", but I was quoting you there.) 17:30:01 <pjones> As an anaconda maintainer, I'd prefer we wait and do this once instead of wasting time by revisiting it again and again. 17:30:34 <Kevin_Kofler> Well, in that case I'm OK with waiting for next week, but we need some additional information by then or we'll just have wasted a week. 17:30:46 <mitr> skvidal: "we end up having to REDO it" is me, not FESCo. 17:30:56 <Kevin_Kofler> Ideally, we'd get upstream to commit this into trunk and the Fedora maintainer to backport the patch from trunk. 17:31:04 <dgilmore> pjones: right. i think we need to get the new api stablke and settled upstream and package it correctly 17:31:16 <pjones> dgilmore: yeah. 17:31:19 * nirik is ok also with updating the ticket as info comes in and we can weigh in there over the week before next weeks meeting. 17:31:23 <j-rod> +1 for notting's table it, next 17:31:29 <pjones> Kevin_Kofler: that's not ideally. That's worst-reasonable-case. 17:31:32 <dgilmore> j-rod: +1 17:31:35 <pjones> j-rod: +1 17:31:37 <jds2001> +1 17:31:40 <notting> ok, that's at least 6 or 7 +1 17:31:44 <nirik> agreed. Next. 17:32:04 <jds2001> #agreed tabled for next week when additional information will be available 17:32:23 <jds2001> #topic Adobe CMap files - code or content? 17:32:31 <jds2001> .fesco 177 17:32:55 <Kevin_Kofler> This one is almost philosophical... Always fun to discuss. 17:32:56 <jds2001> good question :) 17:33:13 * jds2001 has been waffling back and forth on this one 17:33:43 <jds2001> Kevin_Kofler: this has VERY practical ramifications. 17:34:06 <notting> it's ... a table. is that even copyrightable? 17:34:09 * notting looks at spot 17:34:18 <Kevin_Kofler> jds2001: Right, that's the big problem here. 17:34:23 * dgilmore thinks its likely content and needs removal 17:34:24 * nirik thinks he would side with spot here... Barely content. 17:34:38 <jds2001> dgilmore: it wouldnt need removal if content. 17:34:47 <notting> dgilmore: content that restricts modification is ok. code that restricts it is not (per guidelines) 17:34:48 <Kevin_Kofler> Thiese are technically code (PostScript) files, but they just contain tables, see e.g. http://www.ghostscript.com/pipermail/gs-cvs/2003-December/003861.html for what they look like. 17:35:02 <dgilmore> jds2001: well i think being unmodifiable makes it unacceptable 17:35:18 <jds2001> dgilmore: as code, yes. non-modifiable content is fine. 17:35:21 * jwb sighs 17:35:51 <Kevin_Kofler> So it's really hard to decide whether we need to apply the stricter rules for code here or not. 17:36:05 <jwb> we could take a practical approach 17:36:27 <jwb> does removal cause breakage? if yes, content. if no, code 17:36:28 <jds2001> there is a free postscript interpreter. 17:36:36 <jds2001> so I view it as content. 17:36:53 <Kevin_Kofler> There's a Free Python interpreter, so all .py files are content??? 17:36:55 <jds2001> barely 17:37:02 <ajax> practically that's pretty similar to the keymap definition files in X 17:37:15 <Kevin_Kofler> jds2001: This argument makes no sense. 17:37:21 <jds2001> ajax: i'd argue they are content as well. 17:37:31 <ajax> which have had some hilarious licenses that we just ignore because they're a) not copyrightable b) not meaningfully modifiable anyway 17:37:31 <Kevin_Kofler> The argument is over what the file actually contains. 17:37:36 <jds2001> Kevin_Kofler: im framing it in terms of a previous FESCo decision. 17:37:36 <notting> ajax: are they considered copyrightable (nigeria aside) 17:37:44 <jds2001> Kevin_Kofler: not by itslef. 17:39:21 <Kevin_Kofler> I think these files are clearly code, not content. We don't even apply the laxer content rules for fonts. 17:39:22 <pjones> so, what is the data used for? 17:39:33 <pjones> I think that is really the determining factor. 17:39:37 <jds2001> pjones: character mapping. 17:39:50 <Kevin_Kofler> They're in code files (.ps), they're used in code just like fonts and the tables within fonts are. 17:39:52 <nirik> pjones: https://bugzilla.redhat.com/show_bug.cgi?id=487510#c5 17:39:54 <buggbot> Bug 487510: medium, low, ---, twaugh, NEW, Licensing issue of ghostscript CMap files 17:40:00 <notting> so, i'm +1 to them being content, as that is how they appear to be used. barely. i'm also interested in a fedora-legal opinion of whether a table of mappings is an actual copyrightable file, in which case the issue is null and void 17:40:22 <jds2001> +1 to notting. 17:40:23 <nirik> I'm with notting. +1 (barely content). 17:40:26 <dgilmore> notting: i can work with that 17:40:27 <jwb> +1 17:40:31 <sharkcz> +1 to notting 17:40:32 <Kevin_Kofler> Fonts aren't "content", so why would these character maps be "content"? 17:40:34 <pjones> jds2001: mapping between what and what? 17:40:35 <Kevin_Kofler> -1 to notting. 17:40:38 <j-rod> +1 for content, just barely 17:41:13 <skvidal> +1 to notting 17:41:14 <Kevin_Kofler> We shouldn't call this "content" just to sweep the legal issues under the carpet. 17:41:32 <j-rod> thus notting's interest in fedora-legal's opinion 17:41:37 <Kevin_Kofler> Next we call the NVidia drivers "content"? 17:41:46 <jds2001> Kevin_Kofler: of course not. 17:41:46 <Kevin_Kofler> Or maybe we call them "firmware", just for fun? 17:41:53 <skvidal> thus notting's interest in fedora-legal's opinion 17:41:59 <dgilmore> Kevin_Kofler: Nvidia drivers are clearly not content 17:42:06 <skvidal> which is why I +1'd notting's suggestion 17:42:16 <jwb> my approach to hyperbole is to ignore it 17:42:30 <dgilmore> jwb: indeed we should 17:42:34 <jds2001> #agreed Adobe CMap files are content, but we're not sure that they are actually copyrightable. 17:42:36 <notting> it would be akin to copyrighting a unicode table, no? 17:42:37 <pjones> So the question in my mind is: is there a reason to modify this? If it is, it seems less like content 17:42:39 <jds2001> NEXT! 17:42:53 <j-rod> so I believe we've now witnessed both reductio ad absurdum *and* post hoc ergo propter hoc logical fallacies so far today... 17:43:10 <jds2001> #topic Docs guides RPM's 17:43:14 <jds2001> .fesco 188 17:43:17 <pjones> If you have to change them to either add a new character codes or new glyph selectors (whatever those are ;), as opposed to just adding more of them in parallel, then they definitely are code. 17:43:24 <jds2001> Sparks: you around? 17:43:28 <Sparks> jds2001: I am... 17:43:29 <pjones> guess we moved on. 17:43:49 <jds2001> pjones: we have, nothing more to be gained from the previous discussion. 17:44:11 <notting> i don't suppose it can make one source rpm, multiple language outputs? 17:44:12 <pjones> jds2001: I think the facts have largely been ignored there, but it's not really my place, so I'll let you move on. 17:44:20 * notting knows jack about the publican input 17:44:25 * dgilmore thinks that having all docs for one language in one srpm would be good 17:44:37 <jds2001> Sparks: you wanna give an overview of what the deal is here? 17:44:37 <Sparks> notting: Publican won't... not natively. 17:44:43 <Sparks> jds2001: Sure 17:44:52 <nirik> pjones: feel free to update the ticket with more info if you find it. ;) 17:44:57 <Sparks> So, thanks for allowing me to come and get direction... 17:44:59 <nirik> can you modify it to? 17:45:07 <Kevin_Kofler> IMHO, publish whatever you want. 17:45:15 <Kevin_Kofler> I don't see no reason why we wouldn't package all languages. 17:45:22 <pjones> nirik: well, I think there's insufficient information there about how they're *used*, and I think that's the determining factor. 17:45:26 <Sparks> the problem is that when Publican creates the SRPM for a particular guide it does it one language at a time... 17:45:29 <Kevin_Kofler> It's up to you folks actually working on the docs to package them. 17:45:35 <nirik> Kevin_Kofler: so we have 42 packages for each guide. 17:45:37 <Kevin_Kofler> Why is this a FESCo issue at all? 17:45:43 <Kevin_Kofler> At most this is something for FPC. 17:45:49 <Sparks> so that means that if all our guides are translated to what the Release Notes are (in 41 languages)... 17:46:07 <Sparks> one can start to see the problem with getting each package approved... having multiple CVS instances... etc. 17:46:21 <notting> yeah, i would prefer publican not do that 17:46:28 <Sparks> The Docs Team is willing to be flexible but we are still looking for direction. 17:46:49 <Sparks> We had thought of just including the en-US version in the repo and having all other RPMs available at docs.fp.o 17:46:51 <nirik> is there something we can do here? I guess I would say make publican not do that, but it's not a FESCo issue really. 17:47:09 <Sparks> nirik: that's easier said than done, unfortunately. 17:47:30 <dgilmore> Sparks: i personally think we should have fedora-docs-xx-XX packages that has all the docs in one language, and have it all available via a web download in pdf and html online viewing 17:47:32 <Sparks> So if we throw them all together into a BIG rpm... that makes it a large download. 17:47:34 <Kevin_Kofler> It's fairly easy to make one huge package out of several independent l10n tarballs. 17:47:47 <Kevin_Kofler> kde-l10n (and kde-i18n before that) have been doing just that for ages. 17:47:53 <notting> Sparks: it boils down to what do you want to do, how much effort you want to do with reviews, updates, etc. not something fesco necessarily needs to 'rule' on 17:48:06 <jds2001> Kevin_Kofler: publican actually produces SRPM's 17:48:13 <Sparks> dgilmore: Yeah... and docs.fp.o will have all the guides in HTML and PDF 17:48:21 <dgilmore> Sparks: :) 17:48:23 <Kevin_Kofler> jds2001: Specfiles can be hand-edited. 17:48:40 <Kevin_Kofler> I see no requirement that the autogenerated specfile must be imported as is. 17:48:46 <Sparks> notting: Yes.. but we also don't want to start dumping a couple hundred RPMs into the system 17:49:05 <j-rod> explode the srpms for each lingo, merge into a singe srpm for each document 17:49:21 <Sparks> Kevin_Kofler: The SPEC files cannot easily be manipulated in Publican. it is a hands-off tool 17:49:34 <jds2001> Sparks: but they can be afterwards. 17:49:35 <Kevin_Kofler> You need to commit the specfile to the CVS anyway. 17:49:38 <j-rod> so maintain your own spec 17:49:44 <jds2001> that's what we're saying.... 17:49:49 <Sparks> jds2001: Yes which is kinda what we were doing with the Release Notes. 17:50:17 <Kevin_Kofler> See e.g. http://cvs.fedoraproject.org/viewvc/rpms/kde-l10n/devel/kde-l10n.spec?revision=1.83&view=markup for the "one SRPM, many tarballs, many binary RPMs" approach. 17:50:19 <Sparks> The problem becomes that if you put them all into a single RPM that RPM becomes a HUGE file 17:50:36 <Kevin_Kofler> What we're doing is we just loop over the extracted tarballs and build them all. 17:50:47 <jds2001> Sparks: put them in subpackages. 17:50:49 <Kevin_Kofler> Then we loop over them and install them all. 17:50:52 <jds2001> the SRPM becomes huge 17:50:55 <Kevin_Kofler> And we have one subpackage for each. 17:51:01 <jds2001> but the subpackages don't. 17:51:05 <sharkcz> what is huge? 17:51:07 <Kevin_Kofler> But yes, the drawback of this approach is that the SRPM gets really, really huge. 17:51:39 <Kevin_Kofler> kde-l10n's SRPM is 217 MB. 17:51:41 * jds2001 thinks kde-i18n is in the range of 200-300MB+ 17:51:47 <Kevin_Kofler> 271 MB actually. 17:51:52 <Kevin_Kofler> (typo) 17:51:53 <Sparks> If the Security Guide package becomes 500 MB... it becomes a little burdonsome on the enduser 17:52:06 <nirik> it would only be the src.rpm 17:52:08 <jds2001> but they never see all 500MB 17:52:12 <nirik> not the binary that anyone would install. 17:52:13 <jds2001> unless they get source. 17:52:23 <pjones> we're talking about a lot of stuff, right? So something's going to be huge, be it the number of srpms or the size of one, right? 17:52:31 <Kevin_Kofler> But I still don't see why that's a FESCo issue. 17:52:41 <Kevin_Kofler> Isn't this something to be sorted out with FPC and/or rel-eng? 17:52:42 <skvidal> jds2001: no one uses the source :) 17:52:46 <Sparks> Okay... so with subpackages... the end user only gets the one file == small? 17:53:02 <jds2001> skvidal: i sync source on my local mirror :D 17:53:02 <nirik> Kevin_Kofler: or just in devel later. ;) 17:53:12 <skvidal> jds2001: and you're clearly nobody :) 17:53:23 <skvidal> Sparks: nod 17:53:40 <nirik> Sparks: so we can help you make it work. ;) See folks in devel later? 17:53:40 <Sparks> Well, I'm good with many SPRMs and smaller files for the end user 17:54:05 <Sparks> nirik: Getting ready to hit the road for NC but we'll get this straightened out soon. 17:54:09 <jds2001> alright, can we move on? 17:54:14 <jwb> i propose nirik helps Sparks and the docs team fix this 17:54:15 <jwb> ;) 17:54:22 <nirik> I'd be happy to assist. 17:54:24 <Sparks> Thanks for the input! 17:54:50 <jds2001> #topic Minimal Platfrom from F11 17:54:54 * skvidal hurries to the border to stop Sparks 17:54:55 <jds2001> .fesco 66 17:55:07 <jds2001> so stickster pinged me about this one. 17:55:10 <notting> #agreed nirik will help Sparks and the docs team with this. not a direct fesco issue. 17:55:30 <jds2001> notting: oops, it's under the wrong heading now. oh well. 17:55:41 <dgilmore> it sounded like it was implemented as it was supposed to have been 17:55:47 <jds2001> #agreed this == previous topic of docs 17:56:07 <notting> yeah, i think this should just be retargeted back at f11 17:56:13 <jds2001> dgilmore: there's no UI around it like hte feature said. 17:56:16 <notting> haha 17:56:30 <jds2001> stickster: you around? 17:56:33 <notting> it's because they're using * Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]] in the feature page. the page actually hasn't been edited for f12 17:56:36 * stickster pops up like groundhog 17:56:46 <jds2001> hehe 17:56:48 <dgilmore> jds2001: right. they did the compos work but neglected to get the anaconda work done 17:56:51 <nirik> we need to get a hold of the feature owner and see whats going on. 17:56:57 * stickster was asked a question about this feature and the feature page is unclear on overall status. 17:57:06 <stickster> nirik: That sounds like a good plan to me. 17:57:22 <nirik> ping feature owner, table and revisit next week? or are they around? 17:57:23 <notting> stickster: see above re: wiki markup. i think it's just a markup error. 17:57:23 <stickster> Note the page itself says F12 is the target, yet it remains at 100% and in the F11 feature list. 17:57:27 <stickster> ah! 17:57:27 <dgilmore> this was the server SIG's work from memory 17:57:31 <dgilmore> sharkcz: ping 17:57:31 <stickster> whoops. 17:57:50 <notting> so i think we should just manually edit the version, and it all will be ok? 17:57:51 <sharkcz> dgilmore: pong - it was parallel to server sig 17:58:09 <dgilmore> sharkcz: this feature. was proposed for the server sig right? 17:58:16 <jwb> proposal: notting to edit the version 17:58:23 <dgilmore> sharkcz: and the anaconda work was not done. 17:58:28 <stickster> The page also links to a kickstart which might use some sprucing up 17:58:30 <Kevin_Kofler> The feature page says: "Owner: Name: Peter Vrabec" 17:58:37 <dgilmore> we did a bad job of checking that the feature was actually complete 17:58:43 <notting> dgilmore: that would be a new page, no? 17:58:59 <jds2001> notting: it seems to be in scope of this feature. 17:59:20 <Kevin_Kofler> I think it doesn't make sense to revisit this feature now, it's a done deal. 17:59:22 <notting> right, but if feature bit A is done for release <foo>, then we do a new page for feature <foo+1> 17:59:48 <dgilmore> notting: i thought,( and id need to go back to irc logs) that we said that this minimal platform was what you would get on a text install unless you used a kickstart 18:00:08 <dgilmore> notting: but for F-122 it will need a new page 18:01:01 <notting> dgilmore: right: 18:01:08 <notting> anaconda.backend.resetPackageSelections() 18:01:08 <notting> anaconda.backend.selectGroup("Core") 18:01:15 <dgilmore> notting: it only says Fedora-12 because they used a variable to define the release 18:01:32 <jwb> have we just come full circle? 18:01:36 <dgilmore> notting: but it did not happen in F-11. 18:01:37 <jds2001> right, so lets just change that and be done???? 18:01:47 <Kevin_Kofler> I'm fixing the targeted release now. 18:01:51 <dgilmore> I need to do a text mode install and check but dcantrell said it was not done 18:01:54 <notting> dgilmore: that change is from march 12 18:02:24 <Kevin_Kofler> Targeted release fixed. 18:02:27 <jds2001> ok, then the graphical ui wasnt done, but dont think we need/want one. 18:02:41 <jds2001> #agreed targeted release fixed. 18:02:43 <jds2001> NEXT! 18:03:01 <jds2001> #topic NM mobile broadband enhancements 18:03:07 <jds2001> .fesco 174 18:03:15 <jds2001> Kevin_Kofler: did you have anything more on this? 18:03:59 <dgilmore> +1 18:04:02 <Kevin_Kofler> I think we're basically OK now. I'd like Summary and/or Detailed Description to make it clear which UIs currently implement it (AFAIK only the GNOME nm-applet). 18:04:16 <jds2001> +1 18:04:21 <Kevin_Kofler> But the important compatibility questions have been addressed. 18:04:25 <jwb> +1 18:04:27 <sharkcz> +1 18:04:34 <notting> +1 18:04:55 <jds2001> #agreed NM mobile broadband F12 feature is accepted. 18:04:57 <Kevin_Kofler> +1 to the feature 18:05:00 <nirik> +1 18:05:18 <skvidal> +1 18:05:27 <jds2001> #topic Feature =Anaconda FCoE 18:05:28 <j-rod> +1 18:05:37 <jds2001> .fesco 179 18:05:47 <j-rod> (for the NM one) 18:05:58 * j-rod slightly distracted atm 18:06:06 <jds2001> +1 18:06:17 <jwb> i have a somewhat dumb question 18:06:18 <Kevin_Kofler> The documentation is not written yet. 18:06:19 <notting> +1 for this. i realize it's unlikely to get much community testing 18:06:33 <skvidal> +1 18:06:36 <sharkcz> +1 18:06:38 <j-rod> +1 18:06:42 <jwb> is this going to have another stupid daemon installed and running by default on all systems? 18:06:43 <nirik> +1, but agreed. A test day might be good? 18:06:43 <dgilmore> +1 with the documentation filled in 18:06:49 <jwb> (like the iscsi stuff...) 18:07:09 <Kevin_Kofler> I'm with dgilmore, +1 to the feature, but the documentation needs to be written ASAP! 18:07:11 <j-rod> ew, yeah, that would... be annoying... 18:07:16 <dgilmore> jwb: hrmm hope not 18:07:34 <jds2001> Kevin_Kofler: we are not commenting on the completeness of the feature at this time. 18:07:39 <jds2001> that comes later. 18:08:08 <jwb> that's somewhat orthogonal to the Feature, but it would be nice if that didn't happen given the previous statements of rarity 18:08:15 <jwb> anyway, +1 overall from me 18:08:18 <jds2001> #agreed Anaconda FCoE feature is accepted. 18:08:20 <notting> jwb: AIUI... the utils are commandline 'attach to this fcoe device'. there's no daemon 18:08:23 <jds2001> jwb: agreed 18:08:45 <dgilmore> jwb: anaconda should only enable the iscsiinitiator if iscsi is used 18:08:49 <jds2001> #topic Feature - extended lifecycle 18:08:55 <jds2001> -ENOTAFEATURE 18:09:02 <skvidal> jds2001: +1 18:09:08 <skvidal> not a feature 18:09:19 <jwb> notting, cool 18:09:20 <dgilmore> jwb: /etc/rc.d/init.d/fcoe-utils there is a daemon 18:09:20 <skvidal> nor does it have a snowballs chance in hell 18:09:38 <jwb> jds2001, +1 18:09:47 <Kevin_Kofler> I also think the feature process is the wrong way to get this approved. 18:10:02 <Kevin_Kofler> So +1 to "not a feature". 18:10:08 <notting> +1 to not a feature, HOWEVER... 18:10:12 <nirik> yeah, pass buck to board? 18:10:23 <notting> i think this sort of falls under fesco's purview somewhat (quantifying resources required, etc.) 18:10:40 <jwb> notting, that is true. but either way, not a Feature 18:10:49 <nirik> notting: agreed. But shouldn't the board say if we want to do this? then fesco should chime in on the tech aspect. 18:10:49 <dgilmore> i think what could be a feature is having a way to move between fedora/CentOs/RHEL 18:10:59 <Kevin_Kofler> So what should we answer? Bring it up again as a task item? 18:11:01 <j-rod> I think this *could* be a feature 18:11:11 <jwb> nirik, that is also a valid point 18:11:15 <j-rod> since its possibly something that would want the associated marketing 18:11:17 <skvidal> dgilmore: -1 - "I want a pony" features are not fun 18:11:20 <Kevin_Kofler> dgilmore: The problem is that it doesn't depend only on us. 18:11:22 <jwb> j-rod, you can market outside of Features 18:11:40 <j-rod> true 18:11:43 <dgilmore> Kevin_Kofler: right. it needs to be done above us 18:11:52 <Kevin_Kofler> And the big technical problem is that if RHEL n is based on Fedora x, Fedora x will have moved on in updates beyond RHEL n's conservative versions. 18:11:59 <Kevin_Kofler> Heck, even Fedora x-1 will! 18:12:12 <jwb> RHEL is not a concern of mine for this at all 18:12:15 <dgilmore> skvidal: essentially i think that having it would make the swarm of we need a extended fedora release go away 18:12:16 <Kevin_Kofler> Compare e.g. kernel and KDE in FC5 and RHEL 5. 18:12:41 <skvidal> dgilmore: it just won't work nicely. Not to mention making it tie to rhel would mean communicating to rhn :( 18:12:49 <Kevin_Kofler> (x=6 here, FC5 is Fedora x-1.) 18:12:50 <jds2001> anyhow..... 18:12:52 <jwb> dgilmore, i don't think we are here to make swarms of people go away 18:13:05 <dgilmore> skvidal: right. it wouldnt be fun 18:13:09 <jds2001> #agreed Extemded Lifecycle does not meet the definition of a feature 18:13:14 <f13> the swarm always builds when the current EL is getting rather old 18:13:16 <notting> should we officially move to board? 18:13:22 <jds2001> more to get to, can we move on..... 18:13:27 <jds2001> notting: sure 18:13:28 <jwb> proposal: ask the Board if an extended lifecycle is something the project should consider 18:13:51 <dgilmore> f13: right 18:13:53 <j-rod> +1 for 'ask the board' 18:13:56 <f13> at least this proposal has something of a measurable goal and plan other than "hey leave buildsystem running and maybe people will use it!" 18:13:59 <jds2001> #agreed this is deferred to the Board for consideration if an extended lifecycle is desired. 18:14:00 <notting> +1 for ask the board 18:14:10 <skvidal> +1 ask the board 18:14:13 <sharkcz> +1 18:14:18 <dgilmore> +1 18:14:22 * nirik nods. This is a higher level direction, needs board 18:14:27 <Kevin_Kofler> -1, this is just "hot potato" handling of proposals. 18:14:43 <jwb> +1 for my proposal 18:14:47 <jwb> or really, niriks 18:14:56 <jds2001> Kevin_Kofler: so what do you propose we do, drop it on the floor? 18:15:03 <j-rod> fwiw, I think this would meet both at least #1 and #5 of the criteria for calling something a feature 18:15:05 <jds2001> that surely wouldn't be good. 18:15:12 <Kevin_Kofler> jds2001: Approve it within FESCo. 18:15:16 <jds2001> anyhow...... 18:15:18 <f13> Kevin_Kofler: weren't you just questioning why a proposal was being looked at by FESCo ? 18:15:25 <jds2001> Kevin_Kofler: we can't do that. 18:15:31 <jwb> jds2001, we have majority vote to move to the Board 18:15:38 <jds2001> yep 18:15:40 <Kevin_Kofler> f13: I was saying it's not a feature, I wasn't saying it shouldn't be a FESCo task. 18:16:06 <jds2001> #topic Feature - Fedora Moblin 18:16:07 <Kevin_Kofler> And I was saying moving to RHEL isn't easily possible, but that wasn't the proposal we're voting on! 18:16:11 <jds2001> .fesco 181 18:16:32 <jwb> Kevin_Kofler, if the board things it's worth doing as an official thing, we can decide how to do it at that point 18:16:38 * nirik notes the spins part of this needs to use the spins process. 18:16:41 <jwb> s/things/thinks 18:17:04 * jds2001 hasnt really had a chance to read feature pages from here on down. 18:17:12 * jds2001 does that real quick 18:17:24 <j-rod> +1 for adding the moblin bits. only 10% done makes it seem like its going to have trouble being ready in time though. 18:17:41 <notting> +1. please tell the feature owner to link to review tickets in the feature definition :) 18:17:45 <Kevin_Kofler> Would the use of "Moblin" be a trademark issue? 18:17:50 <nirik> yeah, +1, and note again they need to use the spins process for a spin, but I suspect they will not make it in time. 18:17:59 <jds2001> bag 18:18:02 <jds2001> bah 18:18:02 <jwb> i'm ok either way on this one. i think it might be good to revisit after the packages are in-distro and the spin is approved by the spins SIG 18:18:10 <dgilmore> +1 the spin part needs to go through the spins approval 18:18:12 <jds2001> Work with Fedora QA to ensure that we have sufficient coverage 18:18:13 <sharkcz> +1 18:18:20 * jds2001 *hates* features that say this. 18:18:29 <jwb> jds2001, yeah. that's not feasible 18:18:51 <j-rod> wait, there's a "Fedora QA" ? ;) 18:19:07 <f13> j-rod: thanks. 18:19:25 <notting> Kevin_Kofler: moblin is not a trademark 18:19:42 <j-rod> f13: no problem, any time... :) 18:19:44 <notting> (at least, not in the US) 18:19:55 <jwb> it's a good thought to be concerned with though 18:19:58 <jds2001> +1 to the feature, don't think it will make it, spins process needs to be used. 18:20:04 <jwb> +1 18:20:07 <jds2001> A real test plan would be a plus too. 18:20:11 * j-rod watches out for jlaska's wrath... 18:20:13 <skvidal> +1 w/QA 18:20:27 <Kevin_Kofler> +1 but needs separate spin approval 18:21:08 <Kevin_Kofler> As for QA: it's always hard to write a test plan for a complete desktop environment. 18:21:10 <jds2001> #agreed Moblin feature is approved, with the understanding that the spins component will need to go through the spins process. 18:21:18 <Kevin_Kofler> There's no way to test it exhaustively. 18:21:48 <f13> Kevin_Kofler: it doesn't have to be perfect 18:21:50 * nirik nods. Way too much there... 18:21:51 <f13> but there should be something there 18:21:53 <jds2001> #topic KDE 4.3 Feature 18:21:58 <f13> like "every menu item launches" 18:22:04 <jds2001> .fesco 182 18:22:05 <f13> or "can log in from login manager" 18:22:19 <f13> QA is just looking for something we can measure the feature against for success/fail 18:22:25 <Kevin_Kofler> +1 to KDE 4.3 18:22:26 * jds2001 has the same comments aboutt he lack of a test plan here. 18:22:33 <jwb> is KDE 4.3 akin to a 4.0 release? 18:22:47 <jwb> i don't know the numbering schemes 18:22:54 <jds2001> you mention testing integration with various parts of the distro 18:22:57 <Kevin_Kofler> It's akin to 4.2 which was accepted as a feature. 18:22:57 <notting> jwb: kde doesn't do odd/even, if that's what you mean. 18:23:02 <nirik> +1 here. Thanks for making it a feature. ;) 18:23:03 <jds2001> but there's no way to do that. 18:23:09 <notting> +1 to kde 4.3. 18:23:12 <jds2001> +1 at any rate 18:23:14 <Kevin_Kofler> Plus we have Solid DeviceKit and PolicyKit 1 integration in the works. 18:23:16 <jwb> notting, ok. i was mostly just asking if it was to be considered a "rough" release like 4.0 was 18:23:16 <sharkcz> +1 18:23:22 <jwb> +1 to kde 4.3 18:23:29 <Kevin_Kofler> jds2001: ltinkl and jreznik are working on those integration features right now. 18:23:36 <jds2001> Kevin_Kofler: cool. 18:24:00 <Kevin_Kofler> We may also get fingerprint reading in KDM in, no promises though. (There's code out there, but there are known issues.) 18:24:09 <jds2001> #agreed KDE 4.3 feature is accepted. 18:24:36 <jds2001> #topic Open Sharedroot - Featire 18:24:41 * jds2001 cant type 18:24:47 <Kevin_Kofler> I also wrote a draft test plan for Phonon-GStreamer earlier today. 18:25:21 <jds2001> .fesco 183 18:26:06 <Kevin_Kofler> So the problem with this one is that they're using a third-party repository. 18:26:29 <jds2001> right, I think these packages are supposed to be in Fedora. 18:26:30 <j-rod> my understanding is that that's only until the packages are accepted 18:26:39 <Kevin_Kofler> We need this stuff to actually get into Fedora, i.e. reviewed as packages, or patched into the kernel for kernel modules (no, we're not going to debate separate kmods today ;-) ). 18:26:44 <notting> -1, for two reasons. 1) they're using a third party repo. 2) if they're not using a third party repo, i think a secondary (or is that tertiary now) initramfs setup is a bad bad bad idea 18:27:09 <j-rod> the 'yet another initrd' part is my only real concern 18:27:21 <j-rod> kinda the opposite direction of dracut 18:27:35 <j-rod> perhaps these two camps should talk... :) 18:27:44 <notting> scope is listed as "Except from the small changes that have to be accepted for the initprocess. Everything else is already working for FC11, RHEL5 and RHEL4. So only the migration to FC12 has to be made.". that implies they're not submitting comoonics stuff 18:27:46 <jwb> they probably should, but i don't think it's grounds for dismissal 18:28:03 <marcg_> It was me to add this feature. We don't have a problem to integrate into dracut (new initramfs) but were not sure what you would want. 18:28:09 <Kevin_Kofler> It's not a Fedora feature if it requires outside repositories. 18:28:10 <jwb> erm, my comment was about the duplicate initrd thing. not the packages 18:28:22 <jds2001> Kevin_Kofler: my understanding is it won't 18:28:27 <jds2001> marcg_: is that correct? 18:28:37 <j-rod> oh. hrm. I'd ASSumed the packages were under review... 18:28:40 <jds2001> the outside repo is temporary until these packages are in Fedora? 18:28:40 <jwb> marcg_, are you going to submit the packages needed to fedora? 18:29:02 <marcg_> Yes we are going to submit all packages which are of interest. 18:29:35 <notting> ah, ok, that should be listed under 'scope' 18:29:36 <jds2001> cool, do you have a tracker bug for all the reviews? 18:29:42 <marcg_> We've also already talked to the developer of dracut and also think that it would be no problem to integrate the initrd part into that. 18:29:45 <j-rod> 85% complete seems slightly optimistic if you've got multiple packages that still need to go through review... :) 18:30:11 <jds2001> marcg_: that would be preferred. 18:30:21 <notting> my concern is also that (as it stands now), it's essentailly a secondary initramfs boot setup, a secondary cluster suite setup, etc. etc. 18:30:41 <marcg_> And have a fedora11 open-sharedroot cluster running with dracut. So basically 85% is because it's already running but we were not sure what else we needed to do. 18:31:12 <jwb> so the integration into dracut is already done? 18:31:22 <Kevin_Kofler> What definitely needs to be done is to get the packages reviewed and approved for Fedora. 18:31:28 <marcg_> nooting: It's not really a secondary cluster suite setup. Whereever we can we'll integrate into what's already there. 18:31:35 <jwb> Kevin_Kofler, yes. that's probably step 1 18:31:58 <Kevin_Kofler> Hopefully you have a second person working with you, otherwise the reviews will take a long time. 18:32:00 <notting> marcg_: well, when i see a package called comoonics-clustersuite ... 18:32:02 <marcg_> jwb: for us yes. But we need to talk to the dracut developer again. 18:32:39 <Kevin_Kofler> You need one submitter and one reviewer, ideally both already sponsored, to get things done fast. 18:32:40 <marcg_> notting: comoonics-clustersuite is just a abstraction layer that fits on redhat-cluster oracle cluster or "no" cluster and whatever will come later. 18:33:41 <dgilmore> marcg_: like libvirt abstracts different virt technologies? 18:33:57 <marcg_> dgilmore: more or less yes. 18:34:14 <notting> marcg_: does it still require disabling selinxu? 18:34:26 <dgilmore> marcg_: ok. without everything in fedora its not a feature 18:34:52 <jds2001> dgilmore: rhcs is in fedora i think 18:35:02 <marcg_> notting: I didn't test it with enabled selinux. 18:35:08 <notting> ick 18:35:21 <dgilmore> jds2001: right but this works with it it sounds like 18:35:26 <jlaska> j-rod: prepare for wrath ;) 18:35:35 <marcg_> It was initially based on rhcs. Yes. Those guys know about sharedroots. 18:36:20 <j-rod> jlaska: I'm waiting patiently for it... ;) 18:36:24 <dgilmore> marcg_: we cant evaluate it as a fetaure until you work to get it all in fedora. which would include working to get whatever initramfs stuff you need into dracut 18:36:25 <marcg_> But it's more or less an extension of any clustered or distributed filesystem when used as root filesystem. 18:36:51 <jlaska> j-rod: I was in another side-bar ... are you looking for QA input on a feature? 18:37:20 <jds2001> jlaska: nah, j-rod was trying to tell us there is no Fedora QA :D 18:37:36 <j-rod> jlaska: no, I was just being a smart-ass about an earlier feature that included a "talk to Fedora QA" bit in it... :) 18:37:43 <marcg_> dgilmore: ok (the dracut thing that's perfectly ok for us) and the tools for managing cdsl and the issues we have with the initprocess. 18:38:10 <jlaska> lemme know if we need some input from the QA group ... I'll be happy to lend $0.02 and ask for input from the larger team 18:38:48 <notting> marcg_: how much of the comoonics repo are you looking at bringing in? i mean, that's 500k of python scripts 18:38:59 <notting> which seems like an awful lot of infrastructure 18:39:21 <marcg_> No it's not that big, basically we can cut it down to about 20 classes. 18:40:01 <marcg_> It just the cluster abstraction layer and the cdsl management. All other classes are for more advanced usages. 18:40:06 <notting> still, strikes me a little odd. we already have rhcs, which is configured one way,and now you have this other infrastructure on top of it that's being brought in 18:40:25 <dgilmore> marcg_: ok sof for now we will deny the feature. when you have a plan for getting everything into fedora and dracut. we can re-evaluate. as it stands its not ok. there can be no referneces to outside repos. 18:40:35 <jds2001> to me it's just a service on top of rhcs, right? 18:40:43 <dgilmore> notting: indeed. but i guess i can see using it like libvirt 18:40:54 <Kevin_Kofler> dgilmore: Well, outside repos for testing until the packages get accepted is quite common. 18:40:58 <Kevin_Kofler> The TeXLive feature had them too. 18:41:14 <jwb> dgilmore, i think you mean defer the feature 18:41:23 <dgilmore> jwb: sure 18:41:30 <jds2001> yeah, im fine with deferring this 18:41:32 <j-rod> I'm fine w/the outside repo, as long as its clear this is only for testing pending the package being included in fedora 18:41:33 <notting> dgilmore: libvirt makes sense if you're planning on switching out the underlying implementation. i don't think we're swapping fedora's cluster support out for oracle cluster suite any time soon 18:41:39 <j-rod> ...which the feature is dependent upon 18:41:43 <Kevin_Kofler> j-rod: +1 18:42:05 <jds2001> notting: no, but a consumer of this could. 18:42:07 <dgilmore> notting: we may not. but if we had both in admins only need to know one way to setup a cluster 18:42:25 <dgilmore> notting: what that cluster is becomes less relevant 18:42:29 <marcg_> Because of the abstraction layer. There are many customers using nfs sharedroot without rhcs. 18:42:31 <j-rod> I don't see why we can't just vote on this feature now either, with the simple caveat that it should use dracut and all packages need to be in fedora 18:42:35 <Kevin_Kofler> notting: Isn't btrfs from Oracle? Yet it's likely to become the next default FS. 18:42:57 <Kevin_Kofler> We shouldn't assume we won't ever use something just because of who wrote it, nor even based on the current license (OpenJDK anyone? Licenses can change). 18:43:10 <marcg_> the layer is just for querying the cluster configuration 18:43:13 <dgilmore> j-rod: its way incomplete for whats really needed 18:43:26 <notting> Kevin_Kofler: to use your earlier reductio ad absurdum argument, then we should write an abstraction layer for using windows libc. after all, they might open it. 18:43:33 <j-rod> well, if its still incomplete at feature freeze, then it doesn't get in 18:43:48 <j-rod> doesn't mean we can't approve the idea of the feature 18:44:08 <notting> dgilmore: right. but then i think that should be coordinated with the people already working on clustering... 18:44:14 <f13> don't be afraid to let features fail, just ensure they have a reasonable contingency plan 18:44:34 <dgilmore> notting: ill agree to that 18:44:40 <abadger1999> j-rod: +1 18:45:12 * nirik nods. I'd be ok with approving it based on it getting packages in and stuff merged. 18:45:26 <nirik> if not, it goes to next release and contingency plan gets used. 18:45:36 <Kevin_Kofler> Yeah. 18:46:00 <j-rod> ok, so basically, what say we vote on approving the feature w/the caveats that 1) it needs to use dracut, 2) all packages *must* be in fedora and 3) needs to be coordinated w/other cluster offerings and the people working on them 18:46:02 <jds2001> contingency plan is "we dont have this", since we're not switching out massive pieces of infrastructure 18:46:35 <jds2001> +1 to this feature with the contingencies that j-rod mentioned. 18:46:43 <Kevin_Kofler> +1, same 18:46:45 <dgilmore> +1 to j-rod 18:46:47 <sharkcz> +1 18:46:50 * skvidal will brb 18:46:57 <j-rod> +1 from me, obviously 18:46:59 <jwb> +1 i guess 18:47:08 <nirik> +1 18:47:32 <jds2001> #agreed Opensharedroot is approved with the following caveats 1) it needs to use dracut, 2) all packages *must* be in fedora and 3) needs to be coordinated w/other cluster offerings and the people working on them 18:47:57 * notting votes 0 18:48:05 <jds2001> #topic virtgpxe feature 18:48:12 <jds2001> .fesco 184 18:48:23 <j-rod> +1 18:48:28 <jds2001> +1 18:48:30 <j-rod> etherboot is dead 18:48:34 <nirik> +1 18:48:40 <Kevin_Kofler> +1, the logic makes sense and it's already done. 18:48:40 <nirik> cool stuff. 18:48:42 <j-rod> gpxe replaces it, no-brainer 18:48:42 <jwb> +1 18:48:46 <sharkcz> +1 18:48:46 <dgilmore> +1 18:49:18 <jds2001> #agreed gpxe feature is accepted 18:49:23 <notting> +1 18:49:35 <jds2001> #topic XI2 feature 18:49:40 * j-rod has something at 3pm, hoping we can plow through the last few issues quick... :) 18:49:41 <jds2001> .fesco 185 18:49:44 <j-rod> +1 18:50:27 <nirik> +1 no brainer again. Backward compat. 18:50:31 <sharkcz> +1 18:50:39 <jwb> +1 18:50:56 <jds2001> +1 18:51:08 <notting> +1 18:51:08 <Kevin_Kofler> There's a new libXi, is that API-compatible? 18:51:13 <Kevin_Kofler> Or will both versions be provided? 18:51:19 <nirik> it's compatible. 18:51:36 <Kevin_Kofler> OK, so +1 to the feature. 18:51:58 <jds2001> #agreed XI2 feature is accepted 18:52:14 <jds2001> #topic feature - yum langpack plugin 18:52:19 <jds2001> .fesco 186 18:52:51 <Kevin_Kofler> This one needs changes to kde-i18n and kde-l10n which aren't listed under "Scope". 18:52:52 <j-rod> +1 18:53:15 <notting> Kevin_Kofler: true. although that should just be a Provides: additions 18:53:21 <jds2001> maybe they didnt know? 18:53:26 <j-rod> "when base packages with langpacks" 18:53:35 <j-rod> does that mean @base ? 18:54:15 <Kevin_Kofler> Actually we already have some Provides which might be sufficient. 18:54:25 <Kevin_Kofler> kde-l10n-German Provides: kde-l10n-de and same for the KDE 3 kde-i18n. 18:54:39 <notting> Kevin_Kofler: as long as the iso codes match, yeah, that should do it 18:55:08 <jds2001> +1 18:55:10 <nirik> +1 here. 18:55:11 <notting> but... i'm still 0 on this. i'm concerned about the implementation and how it will work with anaconda and tree building 18:55:17 <jds2001> i wanna get through the last one. 18:55:22 <sharkcz> +1 18:55:24 <Kevin_Kofler> +1 to the feature. 18:55:31 <ajax> notting: i'd like to know how it interacts with livecd creation too. 18:55:35 <Kevin_Kofler> If any KDE changes are needed, I can take care of them. 18:55:49 <notting> let me rephrase. i'm -1 without more details 18:56:17 <j-rod> hrm. hadn't considered impact on livecd and anaconda tree building... 18:56:26 <Kevin_Kofler> (KDE packaging changes – AIUI no changes to the desktops themselves are planned at this stage) 18:56:27 <jds2001> yeah 18:56:30 <j-rod> do those happen w/yum-utils installed? 18:56:46 <jds2001> can we defer til we get further info? 18:56:52 <notting> j-rod: they 'can'? i don't know if pungi uses plugins. anaconda would need code to use specific ones 18:57:15 <j-rod> ok, I'll go from +1 to 0, 'needinfo' 18:57:28 <jds2001> same here 18:57:54 <Kevin_Kofler> So you're proposing to ask for more information and defer to next week? 18:57:58 <j-rod> yes 18:58:15 <j-rod> generally for it, but want to know that its not going to hose over livecd and anaconda in anyway 18:58:27 <jds2001> #agreed further information on the impact to pungi, anaconda, and livecd-tools is needed. 18:58:35 <Kevin_Kofler> Yeah, 18:58:44 <Kevin_Kofler> +1 to that (further info needed). 18:59:02 <jds2001> #topic VirtIO serial 18:59:06 <Kevin_Kofler> The KDE Live CD should also be tested, we definitely don't want to have all the kde-l10n-* dragged in. 18:59:07 <jds2001> .fesco 187 18:59:16 <jds2001> last one 18:59:56 <notting> +1. seems uneventful. 18:59:56 <j-rod> +1 19:00:08 <sharkcz> +1 19:00:08 <jds2001> +1 19:00:38 <nirik> +1 19:00:45 <Kevin_Kofler> +1 19:01:11 <jds2001> #agreed virtio serial feature is accepted. 19:01:24 <jds2001> that's all I had 19:01:39 <dgilmore> +1 19:01:44 <jds2001> anyone else have anything pressing? 19:01:54 <jds2001> or can I put a fork in this? 19:02:01 <j-rod> fork it 19:02:08 <jds2001> #endmeeting -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
