17:00:13 <sgallagh> #startmeeting FESCO (2012-05-14)
17:00:13 <zodbot> Meeting started Mon May 14 17:00:13 2012 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:13 <sgallagh> #meetingname fesco
17:00:13 <sgallagh> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
17:00:13 <sgallagh> #topic init process
17:00:13 <zodbot> The meeting name has been set to 'fesco'
17:00:13 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
17:00:26 <nirik> hello.
17:01:07 <mitr> Hello all
17:01:26 * notting is here
17:01:33 <pjones> kneel before me
17:01:42 <pjones> er, wait, wrong meeting
17:01:44 <pjones> I meant to say
17:01:45 <pjones> hello
17:01:49 <nirik> pjones: you missed the /nick zod before that. ;)
17:01:51 * limburgher here, standing defiantly
17:02:08 <mmaslano> hi
17:02:31 <sgallagh> mjg59 and t8m?
17:03:01 <t8m> hello
17:03:13 <mjg59> Yo
17:03:25 <sgallagh> #info limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m all present
17:03:39 <nirik> wow. full house. ;)
17:03:47 <sgallagh> Ok, to the best of my knowledge, we have no follow-up business today.
17:03:59 <sgallagh> So we'll go straight to new business
17:04:03 <sgallagh> #topic #847 Request to have guidance on growing use of LLVM
17:04:04 <sgallagh> .fesco 847
17:04:06 <zodbot> sgallagh: #847 (Request to have guidance on growing use of LLVM) – FESCo - https://fedorahosted.org/fesco/ticket/847
17:04:55 <sgallagh> So my understanding is that some packages have decided to start using an alternate toolchain from gcc, and the concern is for supportability?
17:05:00 <nirik> I think if we get a growing number of things using llvm, we will also grow our ability to fix it.
17:05:07 <pjones> I think we should advise people to use llvm only where it's appropriate.
17:05:16 <limburgher> pjones:  or required?
17:05:24 <pjones> limburgher: if it's required, it's appropriate.
17:05:26 <nirik> sgallagh: yeah.
17:05:28 <sgallagh> My I assume LLVM produces ELF binaries?
17:05:30 <t8m> I think llvm should be used only when it is really required.
17:05:32 <pjones> sgallagh: yes
17:05:36 <notting> nirik: i don't follow that line of reasoning. the number of apps that use filesystem features is not commensurate to the number of people competent to fix the VFS
17:05:42 <pjones> sgallagh: though it doesn't /have/ to, but sure.
17:05:48 <limburgher> t8m: That smells like a nascent policy. :)
17:06:08 <nirik> well, if people start using it and it breaks, they would either stop using it, or find a way to fix it, no?
17:06:18 <sgallagh> pjones: The real question I guess is whether a shared library built with LLVM will work with an app compiled in GCC and vice-versa
17:06:21 <mitr> nirik: LLVM is fairly easy to change... if you want to do small changes.  Real features still require non-trivial expertise.
17:06:26 <nirik> not push that out to 'we can't ship foo because llvm doesn't work right'
17:06:40 <pjones> sgallagh: and if it doesn't, it's broken and people will file bugs and we'll have another discussion?
17:06:41 <notting> also, 'usage of LLVM' is vague. two separate areas of use: 1) using LLVM libs as a linked compiler for things (llvmpipe)  2) using clang as a system-level compiler
17:06:41 <mitr> sgallagh: There is an ABI, at least for C
17:06:43 <mjg59> I'm a big fan of having one way to do things
17:06:52 <mjg59> And I think that for C, that should typically be gcc
17:07:07 <sgallagh> pjones: Yes, I'm just trying to establish a base level of knowledge before I make any judgements
17:07:10 <mjg59> But gcc doesn't support the full set of features that clang supports, and there are going to be some packages that benefit from that
17:07:29 <pjones> sgallagh: the answer is: yes, it is supposed to be using the same abi
17:07:38 <mmaslano> I guess the guidance should be: gcc compilation must work
17:07:44 <pjones> mjg59: to say nothing of llvmpipe?
17:07:49 <pjones> mmaslano: eh?
17:07:51 <notting> mjg59: how does hfsplus-tools 'benefit' from clang? i'm confused what the feature is here, other than 'was written to build with it'
17:08:02 <mitr> My concern is that we have toolchain-based features fairly frequently (security-relevant, e.g. ExecShield, relro, or plain optimization, e.g. better ELF hashing), and supporting two separate compilers makes introducing such features at least twice as hard.
17:08:05 <pjones> mmaslano: if you're not choosing to use gcc, why must gcc compilation work?
17:08:09 <mjg59> notting: gcc doesn't support blocks
17:08:31 <pjones> notting: it won't compile with gcc.  there's not much hope.
17:08:32 <notting> does clang use the binutils linkers, etc?
17:08:33 <mitr> mmaslano: "must work" doesn't say which one will e used...
17:08:43 <notting> or gold, or ...?
17:09:15 <mmaslano> well I read in the ticket: While this represents a good technology advance, Fedora is heavily invested (in staffing, experience) with GCC.
17:09:56 <mitr> mmaslano: if a package is built with llvm, I can't see how it matters that it "can" build with gcc
17:10:11 <notting> proposal-that-is-way-too-technical: if your code *can* build with gcc, it *must* be built with gcc. if it can't, please consider working on porting it.
17:10:24 <t8m> notting, I like it
17:10:26 <mitr> notting: sounds like a good policy for today.
17:10:37 <pjones> notting: I'm honestly not convinced we're not better off avoiding the "you must use this tool" game.
17:10:54 <mmaslano> notting: yes, I was looking for something like that. Thanks
17:10:56 <sgallagh> jonmasters: Do you want to make any comments on this? You opened the request.
17:11:27 <mitr> Long-term, I suppose there are two concerns: 1) if we ever switched from gcc, how would that work?  flag day in a single Fedora release?, and 2) what makes using gcc/llvm in parallel from using, say, gcc and ocaml in parallel?
17:11:34 <nirik> it seems to me stuff like this shakes out without a mandate from a govenering body, but perhaps I'm wrong.
17:11:35 <notting> so, for mjg59's hfsplus-tools example, it could be 'considered porting. not worth the effort at this time'.
17:11:48 <pjones> notting: there's a lot of stuff using cmake, which I don't happen to like much - why aren't we talking about banning cmake?
17:11:50 <sgallagh> notting: I could agree with that. As mentioned above, we have numerous security policies such as relro that we have in place for GCC
17:11:58 <t8m> mitr, for 2) you can hardly compile ocaml code with gcc :D
17:12:06 <mjg59> notting: It's not even infeasible to port it, but it would represent a (likely permanent) divergence from upstream
17:12:20 <mitr> t8m: same for current hfsplus - the two are not a subset/superset
17:12:43 <t8m> mitr, and I don't think we should deny hfsplus just because it doesn't compile with gcc
17:12:44 <mitr> mjg59: btw. how do blocks differ from gcc nested functions?  Syntax only?
17:12:55 <pjones> nirik: I think you're right.  furthermore, given the... lackluster feature support of gcc in terms of, for example, why didn't we have a llvmpipe-like-library a decade ago...
17:13:02 <pjones> nirik: frankly I'd like to encourage the competition.
17:13:04 <mitr> t8m: right, that's my concern.
17:13:11 <mjg59> mitr: Other than that, not hugely. Implementation-wise - gcc's nested functions require an executable stack.
17:13:16 <notting> pjones: i don't think llvmpipe-type-library-usage is even up for discussion, here?
17:13:20 <pjones> mjg59: and a lot of vomit
17:13:22 <t8m> mitr, in the nottings proposal there is no such thing
17:13:33 <notting> ok, let's restate:
17:13:52 <notting> - clang should only be used for packages which use clang-specific C extensions.
17:14:19 <t8m> notting, that's fine as well
17:14:25 <sgallagh> notting: +1
17:14:25 <pjones> notting: no, I was just saying that's an example where I think gcc needs more encouragement to do something useful.  there are others, and I think we should be encouraging a healthy amount of competition between gcc and clang/llvmpipe/etc. instead of saying "don't use this it's bad because we don't understand it that well mmmkay?"
17:14:34 <notting> pjones: what i want to avoid is having to deal with divergent weirdness from upstreams for $random_package_X that decided to build with clang this release
17:14:55 <pjones> notting: I don't see how any policy we make will affect that
17:15:08 <mjg59> notting: I'm fine with that, but I think we should arguably go further and encourage standardisation on toolchain in other respects as well
17:15:09 <notting> or, god forbid, someone trying to run "alternatives --configure cc"
17:15:30 <notting> is salimma around?
17:15:31 <pjones> I can certainly be convinced to vote against clang as an alternatives option for gcc ;)
17:15:46 <pjones> That's not going to take a lot of convincing, even.
17:15:49 <mitr> mjg59: I have difficulty asking for that with straight face, considering that the old Fedora Core packaging merge reviews still aren't all done...
17:16:04 <mjg59> Anyway, can we punt this off to packaging?
17:16:13 <mjg59> It sounds like a perfectly reasonable packaging guideline
17:16:15 <notting> currently there are two packages that build with clang
17:16:15 <nirik> it's not a guideline, it's policy
17:16:20 <t8m> nirik, +1
17:16:38 <notting> it's a policy that would land in the packaging guidelines
17:16:39 <mjg59> nirik: If it's a policy of "should" then it's a guideline :p
17:16:55 <mitr> packaging guidelines are policies... but whatever
17:17:18 <nirik> proposal: FESCo suggests that packages using clang/llvm carefully consider such use against standard toolchain use. No other guideance at this time. Revisit if there's an issue?
17:17:22 <t8m> I think that FESCo should decide on the base direction and FPC can fine tune it
17:17:32 <notting> nirik: -1, i'd prefer something stronger
17:17:37 <t8m> nirik, -1
17:17:41 <limburgher> t8m, notting +1
17:17:58 <nirik> ok. counter proposal? :)
17:18:01 <mjg59> I'm fine with notting's proposal
17:18:10 <sgallagh> nirik: -1, I'm still in favor of notting's proposal
17:18:13 <t8m> I'm fine with either of notting's proposal
17:18:20 * nirik reads back up for nottings proposal
17:18:25 <notting> proposal: Packages may only build with clang if they use clang-specific language extensions.
17:18:32 <mmaslano> I like notting's proposal
17:18:45 <mmaslano> +1
17:18:48 <drago01> why is this specific to clang
17:18:49 <pjones> I don't particularly like either of notting's proposals.  I don't think we need to ban clang, even in such a weak way.
17:18:49 <sgallagh> +1
17:18:51 <t8m> +1
17:18:54 <nirik> but then anyone could add such? I suppose it stops people from switching for no reason
17:18:54 <drago01> what about $otherccompiler ?
17:18:55 <limburgher> +1
17:18:57 <notting> proposal-addition-that-I-would-hope-I-wouldn't-need-to-specify: don't add clang-specific usage in patches ;)
17:19:02 <pjones> drago01: it isn't, that's just the only other real option
17:19:22 <limburgher> nirik: If they care enough to switch, they probably want something it has that gcc doesn't.
17:19:34 <mitr> limburgher: clang's diagnostics, perhaps?
17:19:47 <drago01> pjones: no idea open64? my point was just "make this generic"
17:19:47 <sgallagh> notting: Perhaps: "Packages may only build with an alternative compiler to gcc if upstream requires compiler-specific language extensions"
17:20:02 <pjones> limburgher: which is why I think we should be encouraging them
17:20:04 <notting> sgallagh: i'll take that. +1
17:20:05 <limburgher> mitr:  Maybe.
17:20:10 <mjg59> Can we also define a standard lisp implementation?
17:20:13 <pjones> drago01: meh.  I don't think it matters, practically.
17:20:30 <mitr> +1 - I don't particularly like the banning of clang as a general policy, but given that there is 0 push to make clang the default, I think it is fine for the current 1-2? years
17:20:31 * nirik is with pjones here.
17:20:36 <pjones> mjg59: now you're arguing against something you've said you're okay with?
17:20:47 <limburgher> pjones:  I think this clarifies things, and helps people move forward.
17:20:54 <pjones> limburgher: I don't see how?
17:20:55 <nirik> anyhow, I think there's enough votes to pass notting's proposal?
17:21:07 <notting> nirik: i prefer sgallagh's wording, tbh
17:21:11 <nirik> or we could vote on sgallagh's
17:21:12 <mjg59> pjones: I think there's value in consistency here
17:21:13 <pjones> what does it clarify?  for whom?  Who has been struggling on moving forward because they couldn't figure out if they should use gcc or not?
17:21:17 <t8m> +1 for the sgallagh's proposal as well
17:21:30 <mjg59> pjones: If we're defining a standard C toolchain we should do the same for other languages that have multiple options
17:21:31 <pjones> mjg59: oh, you're *genuinely* saying we should pick a standard lisp?
17:21:35 <sgallagh> #proposal "Packages may only build with an alternative compiler to gcc if upstream requires compiler-specific language extensions"
17:21:44 <mjg59> pjones: If possible, sure
17:21:48 <t8m> sgallagh, +1
17:21:54 <sgallagh> mjg59: Open a ticket for next week, please
17:22:27 <pjones> sgallagh: can we not rush to vote on this while we're still discussing it?
17:22:29 <notting> pjones: so, you're saying that this proposal is solving a non-problem?
17:22:31 <mitr> mjg59: That will run into the same problem - different implementations do not have a feature subset/superset relationship - and in a worse way than clang/gcc
17:22:38 <mjg59> mitr: Right
17:22:39 <pjones> notting: I'm saying it's making an existing problem worse
17:22:51 <mjg59> mitr: I just don't think there's a fundamental difference between C and any other language
17:22:56 <limburgher> pjones: No idea.  But now instead of wondering, walking into a minefield, they at least know what we think currently.
17:23:02 <t8m> pjones, how so?
17:23:04 <mjg59> And I don't think solving this argument purely for C is very helpful
17:23:17 <pjones> the existing problem being that gcc is unfortunately academic and often fails to provide a more useful tool, and clang is showing them how to do it better.  if we discourage clang, we discourage gcc improving as well.
17:23:55 <notting> i think attempting to redirect gcc development via our packaging policies is not the most direct of a lever
17:23:55 <drago01> mjg59: yeah that makes sense to me
17:23:58 <mitr> mjg59: Right, I see that - OTOH there are "soft" differences": in practice C is a dominant language that makes it more important, and has a dominant implementation (and we do take advantage of the dominancy of said implementation)
17:24:11 <t8m> maybe we could allow also using clang where upstream is encouraging it as well?
17:24:13 <pjones> notting: so we're trying to influence *every* upstream instead of just the one?
17:24:23 <t8m> s/clang/alternative compiler/
17:24:47 <mitr> t8m: That runs straight into the "new features in toolchain" problem
17:24:49 <mjg59> Ok, so obvious straw-man argument:
17:24:55 <drago01> "use the compiler prefered by upstream"
17:25:10 <pjones> drago01: and that, I could get behind.
17:25:11 <nirik> drago01: +1
17:25:13 <mjg59> Red Hat has much more engineering support for Gnome than for KDE. We should change the packaging guidelines to request that everyone consider porting their applications to GTK.
17:25:15 <t8m> I'd just like to prevent switching random packages to clang just because the pkg maintainer likes it.
17:25:29 <pjones> mjg59: you know how I feel about that :)
17:25:48 <mitr> pjones: OTOH, I've been doing some work with LLVM, and at least 2-3 years ago it was a toy compared to gcc in many respects.  Sure, a toy that produced working code, but...
17:25:53 <pjones> t8m: and that's fair, but that's not what the earlier policy suggests - in fact it's much more modest
17:26:33 <mitr> So I'm not really fond of cheering on switching to clang right now - but I definitely don't want to close the door forever
17:26:34 <mjg59> I agree that (at least for now) we should encourage people to use gcc rather than clang where possible, but I also believe that about several other components
17:26:35 <notting> how is the policy of "only use if you don't have an alternative" more modest?
17:26:40 <pjones> mitr: sure - but if an upstream picked it, then we're trusting their code and implicitly saying we don't trust their makefile to run something sane to build it?  and we're saying they didn't know what they were doing when they chose how to compile it?
17:26:50 <t8m> pjones, well I'd like to be a slightly more strict however I'd be fine even with this modest policy better than nothing
17:27:06 <mitr> pjones: clang may be "sane", but suppose it doesn't have FORTIFY_SOURCE - which one is more important?
17:27:24 <pjones> notting: that policy encourages people to use gcc instead of clang when upstream has chosen clang and merely not written something /incompatible/ with gcc.  I think that's a bad plan.
17:27:27 <mitr> (Note: I haven't checked whether it supports that or not)
17:27:33 <notting> pjones: examples?
17:27:37 <pjones> mitr: fair point
17:28:09 <pjones> notting: admittedly, I have none - but that's partly because we're discussing this at a time when there are 2 packages in the distro that use clang.  which is to say we're being rather aggressive about discussing it.
17:28:23 <mjg59> #proposal: Since making this decision involves deciding whether we want Fedora to be a platform or a software collection, ask the board first
17:29:05 <notting> my concern is much the same as mitr's - we use the compilation environment to set platform features (fortify source, relro, debuginfo generation, etc. etc. etc.). hence, we benefit for uniformity in all but the most extreme (i.e., won't work otherwise) cases
17:29:10 <mjg59> Rationale: Platforms have one implementation of each component
17:29:13 <mitr> mjg59: I can't see that we can be purely one or the other, ever
17:29:29 <notting> does clang even product compatibile debuginfo, for example?
17:29:31 * nirik doesn't think fedora will be a platform, but sure you could ask the board.
17:29:50 <pjones> notting: and I think that's a fair discussion, but I'm not sure we that means it's time to take action
17:30:14 <pjones> s/we //
17:30:15 <t8m> but policy can be always changed
17:30:27 <t8m> if it is not adequate any more
17:30:27 <pjones> t8m: yes, but it's harder to change a policy than make a new one
17:30:31 <notting> pjones: on the other hand, i think that it makes a fine policy to *not* do something unusual without a Really Good Reason
17:30:34 <sgallagh> Yes, the policy that's sensible today may be revised in a year
17:31:27 <t8m> I still think either notting's/sgallagh proposal or the 'follow upstream' proposal can get enough votes today
17:31:40 <mitr> notting: Well... how _do_ we currently support languages with non-gcc compilers?  Are we fine with what we do there?  Is there something that we can/need to improve in that respect, and could it be applied to clang as well?  (Most likely, lack of manpower will kill any such push)
17:32:16 <sgallagh> mitr: In most cases (python, R, Java) we have a single implementation
17:32:24 <t8m> mitr, most non-C languages do not have buffer overflows
17:32:50 <t8m> so no need for things such as FORTIFY_SOURCE
17:32:50 <notting> sgallagh: techncially, we have 4 python runtimes, at least
17:32:52 <nirik> (well, python and java have multiple versions too, but thats not a big deal)
17:32:55 <mitr> t8m: I suppose...
17:33:05 <limburgher> nirik: Speak for yourself. :)
17:33:12 <notting> sgallagh: only two of them get used, and only one by the majority
17:33:37 <sgallagh> notting: Ok, I suppose I should have limited myself to compiled languages rather than interpreted.
17:33:40 <pjones> sgallagh: I'm not really seeing how the policy is sensible today.  have we had some giant problem with the current state of affairs?
17:33:43 <notting> we're at ~30 m inutes? vote, continue discussion, or...?
17:33:49 <limburgher> And we have Guidelines around how to support both, but you have to support the default.
17:34:28 <limburgher> I'm ready to vote, but it seems like there's more discussion desired, and that's fine with me.
17:34:29 <sgallagh> I think we're fairly well polarized on the issue at this point.
17:34:29 * nirik also doesn't see the big problem today. If some maintainer switches a critpath package to use it, and it breaks, we ask them to change back? or get upstream to help fix clang, or ?
17:34:45 <notting> pjones: the example would be one large portion of the OS (yum? pygobject3? something else) wanting to move their stack to ABI-incompatible pypy
17:34:56 <mitr> pjones: our choices basically are 1) hope that clang won't gain traction, 2) give up on toolchain-based features for the future, 3) find enough qualified people to work on the llvm toolchain to maintain parity, 4) minimize use of clang.
17:35:04 <mjg59> If the concern people have is that clang doesn't necessarily support the full set of functionality that we expect from gcc, then we should probably check that before making a decision
17:35:05 <notting> pjones: you're saying we should not standardize against that now?
17:35:14 <t8m> mitr, +1
17:35:26 <pjones> notting: do we have some reason to believe that pypy would decide to make everything abi incompatible?
17:35:36 <notting> pjones: it *is* now
17:35:43 <pjones> oh, huh.  well, okay :)
17:35:54 <mjg59> But I do see mitr's point
17:36:19 <notting> to mitr's point, i would rather do #4, and revisit later ,than #1 and deal with the fallout
17:36:21 <mjg59> It's a problem if we can't enable useful functionality across the distribution unless the people doing the work on one compiler don't also do it on the other
17:36:25 <nirik> if some big upstream switched to use it, how could we forbid it? carry gcc patches locally to the end of time? at some point we have to follow what the people who write our software do
17:36:55 <nirik> anyhow, we should vote or table for more info, IMHO
17:37:11 <mitr> nirik: extending gcc is also an option, at least in theory
17:37:12 <limburgher> Follow upstream seems logical, to a point.
17:37:31 <pjones> mjg59: so we can't use blocks or clang's diagnostic features until gcc implements them?
17:37:53 <pjones> (okay, argue against blocks, fine.  diagnostic features?  surely those are useful functionality?)
17:38:17 <sgallagh> pjones: Can you expound a bit on the diagnostic features?
17:38:24 <sgallagh> Are we just talking about its static analysis stuff?
17:38:29 <t8m> diagnostic features can be used with local builds not necessarily have to be used within the distro packages
17:38:31 <mjg59> clang is much better at producing useful errors
17:38:36 <mitr> sgallagh: e.g. http://clang.llvm.org/diagnostics.html
17:38:37 <sgallagh> Because individual projects can take advantage without doing so in the final packages
17:38:46 <t8m> yeah
17:38:59 <pjones> sgallagh: http://clang.llvm.org/diagnostics.html
17:40:14 <mitr> Proposal: Ask gcc and llvm maintainers for opinion about maintaining features in both at the same time, and revisit next week
17:40:22 <pjones> t8m: sgallagh: you can't be serious?  now you want people to conditionalize their build on whether it's local or distro?
17:40:31 <t8m> pjones, why not??
17:40:37 <mitr> (I'm not sure that it will change anything - but we really didn't have expert input so far)
17:40:47 <nirik> everyone wants to test things twice. not.
17:40:49 <pjones> t8m: because it's a giant pain in the ass that's going to lead to even more bugs?
17:41:11 <notting> mitr: -1... i think we have enough information here to make a reasonable proposal judgement, and now we're just going in circles around the drain
17:41:37 <pjones> mitr: I don't really think that has any chance of getting anywhere?
17:41:42 * nirik also thinks we are circling. Perhaps a final proposal to vote on?
17:41:53 <sgallagh> pjones: I meant upstreams can build with clang if they want to run diagnostics, but RPM builds should always be GCC
17:42:07 <sgallagh> *where possible
17:42:24 <pjones> sgallagh: so then when there's a bug in one or the other, all of upstream's testing is invalid
17:43:08 <mitr> notting: How many people have llvm programming experience here?  My experience is somewhat outdated already... but yeah, not looking forward to another 40 minutes next week.
17:43:14 <sgallagh> pjones: State your proposal, I will state mine, everyone can vote on the two.
17:43:17 <sgallagh> Is that reasonable?
17:43:23 <t8m> sgallagh, +1
17:43:26 <mmaslano> sgallagh: sounds fine
17:44:20 <sgallagh> #proposal Packages may only build with an alternative compiler to gcc if upstream does not support gcc
17:44:21 <pjones> sgallagh: my proposal is that this doesn't merit changing our policies at this time
17:44:31 <t8m> sgallagh, +1
17:44:35 * nirik is with pjones on this one.
17:44:37 <sgallagh> (I've made that slightly simpler than before, to allow upstream more leeway)
17:44:48 <t8m> pjones, -1
17:44:57 <mitr> sgallagh: "support" means "is able to build with", or "recommends"?
17:45:29 <mjg59> Eh. I think I'm starting to lean more towards pjones here.
17:45:34 <sgallagh> mitr: I suppose recommends is probably closer to what I meant.
17:45:56 <mitr> In that case I'm... not sure there is any difference between the two :)
17:46:02 <sgallagh> But with a stronger preference towards gcc if possible
17:46:34 <sgallagh> mitr: A recommendation is different from a mandate
17:46:42 <notting> +1 to sgallagh's proposal
17:46:43 <sgallagh> "We prefer clang but work with gcc" -> GCC
17:46:48 <notting> i'd prefer it be stronger
17:47:10 <limburgher> +1 sgallagh
17:47:12 <mitr> I'd prefer it to be a bit stronger, but can be +1 to sgallagh's proposal
17:47:18 <t8m> pjones, if $random maintainers start patching their packages to build with clang will we make the policy?
17:47:25 <mmaslano> +1 for sgallagh
17:47:32 <sgallagh> I'm willing to revise the text of it if you have better phrasing
17:47:53 <pjones> t8m: is there any evidence anybody is clamoring to do that?
17:48:03 <pjones> t8m: if that becomes a thing, I'm all for more discussion
17:48:18 <t8m> I see 6 votes for sgallagh's proposal.
17:48:40 <t8m> (if sgallagh votes for it)
17:48:46 <sgallagh> +1 ;-)
17:49:10 <sgallagh> Clearly not a consensus, but I think that's a decision at least
17:50:06 <nirik> indeed. shall we move on?
17:50:18 <mmaslano> please
17:50:27 <t8m> :)
17:50:30 <sgallagh> #agreed Packages may only build with an alternative compiler to gcc if upstream does not support gcc (6 +1)
17:50:37 <sgallagh> #topic #849 Build and host request for French live ISOs
17:50:37 <sgallagh> .fesco 849
17:50:40 <zodbot> sgallagh: #849 (Build and host request for French live ISOs) – FESCo - https://fedorahosted.org/fesco/ticket/849
17:51:01 <notting> this is a fesco issue?
17:51:17 <sgallagh> I think this is more Board+Releng
17:51:18 <pjones> doesn't seem like it.
17:51:20 <notting> i suppose as those above releng, it is
17:51:22 <t8m> sgallagh, +1
17:51:36 <nirik> we have not done any official localized spins/releases.
17:51:38 <notting> historically we don't host localized live images, *i think*
17:51:51 <nirik> I think we have had other requests in the past we turned down too.
17:52:09 <t8m> I think this should be really decided by board
17:52:10 <sgallagh> nirik: Whether to host localized images or not sounds like it should be a Board policy decision
17:52:16 <mitr> Is this something for http://fedoraproject.org/wiki/Spins_Process ?
17:52:20 <mjg59> Yeah, I really don't think this is for us
17:52:57 <sgallagh> #proposal Send this to the Fedora Advisory Board
17:53:08 <t8m> sgallagh, +1
17:53:29 <notting> +1. suggest releng and infrastructure join the discussion there
17:53:31 <nirik> sure, I suppose so.
17:53:56 <pjones> yeah
17:54:46 <mjg59> +1
17:54:48 <mmaslano> +1
17:55:33 <sgallagh> I count 7 +1, assuming nirik's "I suppose so" counts
17:55:39 <nirik> yes, +1
17:55:58 <mitr> +1, I suppose (... what _is_ the right process here?  but at least it is in the right direction)
17:56:47 <notting> mitr: historically, "we don't do this". changing the "we don't do this" is not exactly our decision. so, ... punt!
17:56:50 <sgallagh> who's missing?
17:57:26 <sgallagh> limburgher: Just for the record?
17:58:15 <sgallagh> #agreed Send this to the Fedora Advisory Board (8 +1)
17:58:16 <limburgher> +1
17:58:21 <sgallagh> #undo
17:58:21 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x2964ec10>
17:58:23 <sgallagh> #agreed Send this to the Fedora Advisory Board (9 +1)
17:58:30 <limburgher> Sorry. :)
17:58:31 <sgallagh> Your timing is impeccable
17:58:36 <limburgher> As always.
17:58:36 <sgallagh> #topic #850 Unmounting USB devices is unsafe in Fedora 17
17:58:37 <sgallagh> .fesco 850
17:58:38 <zodbot> sgallagh: #850 (Unmounting USB devices is unsafe in Fedora 17) – FESCo - https://fedorahosted.org/fesco/ticket/850
17:59:30 <limburgher> This worries me.
17:59:39 <sgallagh> This is apparently considered a very serious blocker for F17, but we have a disconnect between the Gnome folks and the rest of Fedora.
17:59:59 <nirik> so, this is a nasty bug. I'd love a workaround of some kind. I don't think a clean fix is possible in the time we have.
18:00:06 <sgallagh> I don't like the phrase "loss of user data" at all
18:00:18 <mjg59> This is no worse than F15 or F16, right?
18:00:18 <mclasen> I think it is more a disconnect between kparal and us than 'the rest of fedora' but nevermind
18:00:21 <mitr> nirik: Depends on what "clean" means - apparently we can have a working GUI, just not "the" GUI
18:00:31 <mitr> mjg59: No, this works fine in F1[56]
18:00:35 <sgallagh> mclasen: Sorry, didn't mean to overdramatize
18:00:37 <nirik> mjg59: no.
18:00:44 <mjg59> Ok, that's less attractive
18:00:46 <t8m> I think some quick/nasty hack is really needed.
18:00:52 <nirik> anyhow, it is a blocker... so... what can we do to help out here?
18:01:02 <mjg59> "Easiest" "solution" would be to just mount all removable media sync, regardless of filesystem
18:01:15 <t8m> nirik, say, that we support the QA decision for making it blocker?
18:01:27 <mjg59> Then unmount would have nothing to write back
18:01:39 <nirik> I suppose... it then seems not too pointfull to bring it to us. ;)
18:01:41 <mitr> mjg59: Is the Linux kernel actually guaraneeing that "sync" implies "sudden unmount won't lose data"?
18:01:48 <mjg59> mitr: No
18:01:51 <pjones> mjg59: which isn't a terrible idea anyway...
18:01:56 <sgallagh> nirik: Apparently it's bouncing back and forth between blocker and non-blocker
18:01:59 <mjg59> pjones: It kind of is for people with USB hard drives
18:02:03 <sgallagh> nirik: QA says blocker, GNOME says not
18:02:30 <pjones> fair enough I guess if those are showing as removeable... the one I've got doesn't.
18:02:34 <limburgher> I fail to see how this wouldn't be.
18:02:46 <mclasen> the dialog is simply not there anymore, it was removed in the move from udisks to udisks2 at the beginning of the year - since this was not noticed until very late, I doubt that the problem is as serious as its made out to be....
18:02:48 <mjg59> I don't find David's position hugely compelling, given that several recognisable brands don't have LEDs
18:02:51 <sgallagh> mclasen: Would you mind stating your position?
18:03:17 <pjones> mjg59: yeah, relying on LED feedback from usb devices is clearly a non-starter
18:03:19 * kparal is also present
18:03:24 <t8m> not enough users lost data for it being a blocker?
18:03:28 <mitr> mclasen: Given how few people actually use the alpha/beta releases... I don't find it that surprising.
18:03:31 <mitr> sgallagh: Well, GNOME does not decide what blocks Fedora releases - the concern is whether GNOME can/will work with us to fix it.
18:03:37 <mjg59> mitr: There's no way to guarantee that pulling out the stick won't lose data. The stated problem is that the unmount call to udisks returns before the kernel umount() has completed.
18:03:37 <notting> my understanding is that there is general agreement that the apps should be fixed in the long run. the question is the feasibility of fixing the apps RIght Now?
18:03:39 <t8m> mitr, +1
18:03:45 <mjg59> mitr: If there are dirty buffers then that umount() can take a while
18:03:47 <pjones> t8m: not enough users noticed losing data and correctly tracked it back to this for it to be a blocker?
18:04:00 <t8m> pjones, perhaps ;)
18:04:07 <mjg59> mitr: Mounting sync means that there should never be dirty buffers
18:04:08 <limburgher> mjg59: Which I greatly prefer to lost baby pictures.
18:04:10 <nirik> notting: yeah, before release... we are very low on time unless we slip a lot
18:04:46 <mitr> nirik: I've been told we have at least until the end of this week, we will slip for other reasons
18:04:50 * nirik isn't sure what a workaround here would look like. I guess the sync mount would be one.
18:04:52 <mjg59> mclasen: So if we don't want to hold for any kind of UI rework or app changes, how are you with mounting everything sync? It should mostly mitigate the problem, at the cost of a lot of performance.
18:05:05 <mclasen> it is a feature that was simply removed; it would have to be reimplemented, and I don't have anybody standing by to do that within the few days that remain until ga...
18:05:38 <limburgher> Then I say mount sync.  Better slow than unreliable.
18:05:39 <sgallagh> mclasen: Hypothetically, how much time (estimated) would it take to reimplement if you had a resource available.
18:05:42 <mclasen> I don't have any opinion on mounting sync - if that fixes the problem, fine with me
18:05:52 <nirik> mitr: well, we should not count on that. Things could align. ;)
18:05:53 <mjg59> Let me check with some fs people
18:05:55 <mitr> sgallagh: There is already a tentative plan at https://bugzilla.redhat.com/show_bug.cgi?id=819492#c24
18:06:15 <notting> mitr: only hits one of two apps
18:06:41 <mitr> notting: Right, I'm really not happy about having this feedback a per-application patch, but we are already in suboptimal land, so...
18:06:57 <mitr> mclasen: Any opinion on feasibility of the plan linked above?
18:07:15 <t8m> mitr, isn't the solution preferred by upstream also per-app?
18:07:52 <mclasen> mitr: not sure that that would do much good tbh - we don't run nautilus by default anymore
18:07:56 * nirik isn't sure we are going to solve this in our meeting here... how about we say "yes, this is a problem, we will work with folks to try and come up with a solution for the blocker'?
18:08:16 <limburgher> nirik: Yes, at least affirming the blockerosity.
18:08:33 <t8m> nirik, +1
18:09:03 <sgallagh> Yes, +1 blocker
18:09:05 <mitr> nirik: I think we sort of need to decide soon - because if it is not a release blocker, it needs to be fairly prominent in release notes, which have already been frozen long ago
18:09:17 <mitr> but +1 for affirming the blocking status
18:09:26 <mmaslano> it's blocker +1
18:09:29 <mjg59> Sure, +1
18:09:36 <limburgher> +1
18:10:17 <notting> +1 to blocker. too much risk of data corruption
18:10:30 <nirik> mitr: yeah, I have no desire to overrule qa here... I think it could possibly be a release note/loud announcement thing, but I'm fine with it being a blocker too.
18:10:43 <pjones> yes, +1
18:11:26 <sgallagh> #agreed USB unmounting issue is a blocker, needs immediate attention (9 +1)
18:11:34 <sgallagh> #topic #851 F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng
18:11:34 <sgallagh> .fesco 851
18:11:36 <zodbot> sgallagh: #851 (F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng) – FESCo - https://fedorahosted.org/fesco/ticket/851
18:11:38 <mjg59> +1
18:11:48 <t8m> +!
18:11:52 <t8m> +1 that is
18:11:56 <pjones> +¡
18:11:57 <mmaslano> +1
18:11:59 <nirik> +1
18:12:16 <pjones> (joking, also +1)
18:12:17 <notting> (aside: stop the -ng naming already)
18:12:18 <notting> +1
18:12:22 * mclasen doesn't agree, but will happily review a patch to mount sync
18:12:26 <mitr> Talked with Jaromir quite a lot about this - note that we already use the procps-ng tree in F1[567] - but this is the first time we are consolidating to upstream version (with ~50 Fedora-specific patches removed)
18:12:49 <sgallagh> +1
18:12:57 <mitr> So, this is primarily a package renaming + incompatible changes (which will, sadly, probably not be all enumerated)
18:13:00 <mitr> +1
18:13:02 <limburgher> +1
18:13:03 <nirik> notting: should rename to procpsKit-ng ? :)
18:13:19 <notting> *shrug* they bumped the version number. just call it procps.
18:13:26 <limburgher> Fedora Unix-ng?
18:14:12 <mmaslano> I guess other distro are also using and developing it :)
18:14:47 <sgallagh> #agreed Feature procps-ng is accepted (9 +1)
18:14:52 <sgallagh> #topic #852 F18 Feature: OpenShift Origin - https://fedoraproject.org/wiki/Features/OpenShift_Origin
18:14:52 <sgallagh> .fesco 852
18:14:53 <zodbot> sgallagh: #852 (F18 Feature: OpenShift Origin - https://fedoraproject.org/wiki/Features/OpenShift_Origin) – FESCo - https://fedorahosted.org/fesco/ticket/852
18:15:05 <pjones> this is the next X-Men sequel?
18:15:16 <t8m> when looking at the util-linux->util-linux-ng->util-linux then procps should really skip the -ng step
18:15:21 <limburgher> pjones:  Jinx
18:15:29 <mjg59> +1
18:15:30 <nirik> +1
18:15:31 <limburgher> +1
18:15:33 <sgallagh> +1
18:15:34 <pjones> sure, +1
18:15:34 <notting> +1
18:15:34 <t8m> +1
18:15:37 <mmaslano> +1
18:15:37 <mitr> +1
18:16:02 <sgallagh> #agreed Feature: OpenShift Origin is accepted (9 +1)
18:16:06 <sgallagh> #topic #853 F18 Feature: New Installer UI - https://fedoraproject.org/wiki/Features/NewInstallerUI
18:16:06 <sgallagh> .fesco 853
18:16:08 <zodbot> sgallagh: #853 (F18 Feature: New Installer UI - https://fedoraproject.org/wiki/Features/NewInstallerUI) – FESCo - https://fedorahosted.org/fesco/ticket/853
18:16:13 * pjones is +1
18:16:21 <nirik> +1. hope it makes it. ;)
18:16:32 <sgallagh> I'
18:16:40 <mjg59> +1
18:16:41 <sgallagh> I'm somewhat concerned about the lack of a text UI
18:16:46 <sgallagh> What does this mean for headless installation?
18:16:52 <t8m> +1
18:16:59 <pjones> sgallagh: the text UI has been declared and announced deprecated for like a dozen releases now?
18:17:07 <mmaslano> +1
18:17:08 <t8m> I suppose kickstart installs will be supported
18:17:09 <mitr> sgallagh: "use VNC", I suppose - although it hasn't been explicitly mentioned.  Can anone confirm that?
18:17:10 <mjg59> sgallagh: It means VNC or Kickstart
18:17:11 <pjones> headless -> vnc as usual
18:17:26 <notting> my concern is the oh-no-contingency-plan factors in the case of unforseen delays and or problems. that being said, i don't know what we can do to satisfy all concerns of that sort at this time, so.... +1
18:17:37 <pjones> mitr: kickstart will still work as well
18:17:55 <sgallagh> Ok, as long as we have a kickstart guarantee.
18:18:00 <limburgher> +1  Though I don't love skipping textmode for a release. . .
18:18:03 <sgallagh> This was not called out in the Feature
18:18:28 <sgallagh> Light +1
18:18:30 <mitr> pjones: I don't really view that as an interactive alternative - but I'm perfecly fine with VNC
18:18:44 <t8m> will the existing kickstarts be compatible?
18:18:50 <mitr> +1 - let's see how that hub/spoke model works out
18:18:59 <notting> sure, i can amend with: 'please mention the removal of the TUI more broadly'
18:19:10 <mitr> t8m: pykickstart has a very comprehensive backward compatibility mechanism
18:19:21 <notting> t8m: 'as much as they are for any other new release'
18:19:25 <pjones> sgallagh: the new design involves running the entire installation /as/ a kickstart.  kickstart is certainly guaranteed :)
18:19:33 <sgallagh> pjones: Works for me
18:19:35 <t8m> notting, fine
18:19:43 <notting> for example, i could imagine firewalld causing changes to the firewall line in kickstart
18:19:51 <sgallagh> #agreed Feature: New Installer UI is accepted (9 +1)
18:20:01 <t8m> notting, I understand
18:20:11 <sgallagh> #topic Next week's chair
18:20:21 <sgallagh> Who's foolish enough to volunteer for next week?
18:20:32 <t8m> heh I can do
18:20:38 <mjg59> Works for me
18:20:47 <sgallagh> #agreed t8m will chair the 2012-05-21 meeting
18:20:53 <sgallagh> #topic Open Floor
18:20:54 <nb> ?
18:21:14 <sgallagh> nb: Do you have something for Open Floor?
18:21:30 <nb> yes
18:21:34 <nb> Does FESCo think that the potential issues with removable media should be noted in the Release Notes? If so, I will coordinate with docs team to try to get that added.
18:21:49 <notting> it should certainly be in the release notes if it doesn't get changed
18:21:51 <mjg59> Let's see if there's a reasonable workaround first
18:21:51 <sgallagh> nb: Our current view is that we need a solution
18:21:55 * mitr still hopes for a software fix
18:22:01 <notting> but that's too soon to say "put it in there now"
18:22:04 <sgallagh> But if none is reached, yes we'll need a call-out in the release notes
18:22:05 <tibbs|w> Will someone open an FPC ticket for the compiler thing?
18:22:26 <nb> ok
18:22:49 <nirik> well, if we don't get a solution we need to either delay until we do, or demote it from being a blocker. ;)
18:22:52 <mitr> nb: We will probably only know for sure about a day before the final iso is spun... so, I don't know.
18:23:14 <mitr> nb: Perhaps just give the docs team a heads up to let them prepare if they can?
18:23:23 <nb> yeah
18:23:24 <sgallagh> tibbs|w: I'll take care of opening that ticket after the meeting
18:23:33 <sgallagh> #action sgallagh to file FPC ticket for new compiler policy
18:23:40 <nb> that or maybe I could add a "There may be a potential issue with removable media, check http://wikipage for more info?
18:23:41 <nirik> we also need a board ticket about the localized composes
18:24:02 <nb> we can usually get changes pushed ASAP if we need to amke a last minute change
18:24:05 <sgallagh> I guess I'll do that too
18:24:07 <nb> as long as final RC hasn't been spun yet
18:24:21 <nb> so if we want to wait, that can be done too
18:24:35 <sgallagh> #action sgallagh to file an Advisory Board ticket for the localized compose
18:26:01 <nirik> I'll note as just a FYI, that election nominations are currently open, but close very soon: https://fedoraproject.org/wiki/Elections
18:26:11 <notting> hey, saves me from doing it
18:26:13 <notting> thx
18:26:48 <sgallagh> nirik: Also, I believe we do not as yet have enough nominees to hold a vote
18:26:58 <nirik> yeah, need more.
18:27:18 * mitr counts 6 nominees for 5 seats
18:27:48 <sgallagh> mitr: Yeah, election policy requires 7 nominees for 5 seats, IIRC
18:27:49 <notting> ... one of which was added in the last two minutes
18:27:55 <mitr> Ah
18:28:16 <notting> (give or take, via caching)
18:28:31 <nirik> well, it seems to call for 6.25... but I don't know where we find .25 nominee
18:28:51 * sgallagh bites back several snarky answers
18:29:24 <pjones> I know one other person who was at least /considering/ running who's not on there yet
18:29:47 <sgallagh> notting: Are you stepping down?
18:29:51 <notting> no
18:29:59 <notting> just hadn't got around to adding myself to the list yet
18:30:03 <pjones> Well, then we've got 7 just as soon as you edit the wiki
18:30:04 <sgallagh> ah ok
18:30:17 * limburgher pokes notting with stick toward wiki
18:30:45 <notting> ... done.
18:31:00 <sgallagh> Ok, any other business?
18:32:32 <limburgher> None here.
18:32:46 * nirik has nothing
18:33:00 <sgallagh> I'll close out the meeting in two minutes if no one has anything else
18:35:13 <sgallagh> #endmeeting