fedora-meeting
LOGS

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