[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

FESCo meeting summary for 2009-07-10

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
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
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
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
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
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
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.
for what they look like.
17:35:02 <dgilmore> jds2001: well i think being unmodifiable makes it
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
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
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.
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
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
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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]