17:00:13 #startmeeting FESCO (2012-05-14) 17:00:13 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:13 #meetingname fesco 17:00:13 #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 17:00:13 #topic init process 17:00:13 The meeting name has been set to 'fesco' 17:00:13 Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 17:00:26 hello. 17:01:07 Hello all 17:01:26 * notting is here 17:01:33 kneel before me 17:01:42 er, wait, wrong meeting 17:01:44 I meant to say 17:01:45 hello 17:01:49 pjones: you missed the /nick zod before that. ;) 17:01:51 * limburgher here, standing defiantly 17:02:08 hi 17:02:31 mjg59 and t8m? 17:03:01 hello 17:03:13 Yo 17:03:25 #info limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m all present 17:03:39 wow. full house. ;) 17:03:47 Ok, to the best of my knowledge, we have no follow-up business today. 17:03:59 So we'll go straight to new business 17:04:03 #topic #847 Request to have guidance on growing use of LLVM 17:04:04 .fesco 847 17:04:06 sgallagh: #847 (Request to have guidance on growing use of LLVM) – FESCo - https://fedorahosted.org/fesco/ticket/847 17:04:55 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 I think if we get a growing number of things using llvm, we will also grow our ability to fix it. 17:05:07 I think we should advise people to use llvm only where it's appropriate. 17:05:16 pjones: or required? 17:05:24 limburgher: if it's required, it's appropriate. 17:05:26 sgallagh: yeah. 17:05:28 My I assume LLVM produces ELF binaries? 17:05:30 I think llvm should be used only when it is really required. 17:05:32 sgallagh: yes 17:05:36 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 sgallagh: though it doesn't /have/ to, but sure. 17:05:48 t8m: That smells like a nascent policy. :) 17:06:08 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 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 nirik: LLVM is fairly easy to change... if you want to do small changes. Real features still require non-trivial expertise. 17:06:26 not push that out to 'we can't ship foo because llvm doesn't work right' 17:06:40 sgallagh: and if it doesn't, it's broken and people will file bugs and we'll have another discussion? 17:06:41 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 sgallagh: There is an ABI, at least for C 17:06:43 I'm a big fan of having one way to do things 17:06:52 And I think that for C, that should typically be gcc 17:07:07 pjones: Yes, I'm just trying to establish a base level of knowledge before I make any judgements 17:07:10 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 sgallagh: the answer is: yes, it is supposed to be using the same abi 17:07:38 I guess the guidance should be: gcc compilation must work 17:07:44 mjg59: to say nothing of llvmpipe? 17:07:49 mmaslano: eh? 17:07:51 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 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 mmaslano: if you're not choosing to use gcc, why must gcc compilation work? 17:08:09 notting: gcc doesn't support blocks 17:08:31 notting: it won't compile with gcc. there's not much hope. 17:08:32 does clang use the binutils linkers, etc? 17:08:33 mmaslano: "must work" doesn't say which one will e used... 17:08:43 or gold, or ...? 17:09:15 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 mmaslano: if a package is built with llvm, I can't see how it matters that it "can" build with gcc 17:10:11 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 notting, I like it 17:10:26 notting: sounds like a good policy for today. 17:10:37 notting: I'm honestly not convinced we're not better off avoiding the "you must use this tool" game. 17:10:54 notting: yes, I was looking for something like that. Thanks 17:10:56 jonmasters: Do you want to make any comments on this? You opened the request. 17:11:27 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 it seems to me stuff like this shakes out without a mandate from a govenering body, but perhaps I'm wrong. 17:11:35 so, for mjg59's hfsplus-tools example, it could be 'considered porting. not worth the effort at this time'. 17:11:48 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 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 mitr, for 2) you can hardly compile ocaml code with gcc :D 17:12:06 notting: It's not even infeasible to port it, but it would represent a (likely permanent) divergence from upstream 17:12:20 t8m: same for current hfsplus - the two are not a subset/superset 17:12:43 mitr, and I don't think we should deny hfsplus just because it doesn't compile with gcc 17:12:44 mjg59: btw. how do blocks differ from gcc nested functions? Syntax only? 17:12:55 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 nirik: frankly I'd like to encourage the competition. 17:13:04 t8m: right, that's my concern. 17:13:11 mitr: Other than that, not hugely. Implementation-wise - gcc's nested functions require an executable stack. 17:13:16 pjones: i don't think llvmpipe-type-library-usage is even up for discussion, here? 17:13:20 mjg59: and a lot of vomit 17:13:22 mitr, in the nottings proposal there is no such thing 17:13:33 ok, let's restate: 17:13:52 - clang should only be used for packages which use clang-specific C extensions. 17:14:19 notting, that's fine as well 17:14:25 notting: +1 17:14:25 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 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 notting: I don't see how any policy we make will affect that 17:15:08 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 or, god forbid, someone trying to run "alternatives --configure cc" 17:15:30 is salimma around? 17:15:31 I can certainly be convinced to vote against clang as an alternatives option for gcc ;) 17:15:46 That's not going to take a lot of convincing, even. 17:15:49 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 Anyway, can we punt this off to packaging? 17:16:13 It sounds like a perfectly reasonable packaging guideline 17:16:15 currently there are two packages that build with clang 17:16:15 it's not a guideline, it's policy 17:16:20 nirik, +1 17:16:38 it's a policy that would land in the packaging guidelines 17:16:39 nirik: If it's a policy of "should" then it's a guideline :p 17:16:55 packaging guidelines are policies... but whatever 17:17:18 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 I think that FESCo should decide on the base direction and FPC can fine tune it 17:17:32 nirik: -1, i'd prefer something stronger 17:17:37 nirik, -1 17:17:41 t8m, notting +1 17:17:58 ok. counter proposal? :) 17:18:01 I'm fine with notting's proposal 17:18:10 nirik: -1, I'm still in favor of notting's proposal 17:18:13 I'm fine with either of notting's proposal 17:18:20 * nirik reads back up for nottings proposal 17:18:25 proposal: Packages may only build with clang if they use clang-specific language extensions. 17:18:32 I like notting's proposal 17:18:45 +1 17:18:48 why is this specific to clang 17:18:49 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 +1 17:18:51 +1 17:18:54 but then anyone could add such? I suppose it stops people from switching for no reason 17:18:54 what about $otherccompiler ? 17:18:55 +1 17:18:57 proposal-addition-that-I-would-hope-I-wouldn't-need-to-specify: don't add clang-specific usage in patches ;) 17:19:02 drago01: it isn't, that's just the only other real option 17:19:22 nirik: If they care enough to switch, they probably want something it has that gcc doesn't. 17:19:34 limburgher: clang's diagnostics, perhaps? 17:19:47 pjones: no idea open64? my point was just "make this generic" 17:19:47 notting: Perhaps: "Packages may only build with an alternative compiler to gcc if upstream requires compiler-specific language extensions" 17:20:02 limburgher: which is why I think we should be encouraging them 17:20:04 sgallagh: i'll take that. +1 17:20:05 mitr: Maybe. 17:20:10 Can we also define a standard lisp implementation? 17:20:13 drago01: meh. I don't think it matters, practically. 17:20:30 +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 mjg59: now you're arguing against something you've said you're okay with? 17:20:47 pjones: I think this clarifies things, and helps people move forward. 17:20:54 limburgher: I don't see how? 17:20:55 anyhow, I think there's enough votes to pass notting's proposal? 17:21:07 nirik: i prefer sgallagh's wording, tbh 17:21:11 or we could vote on sgallagh's 17:21:12 pjones: I think there's value in consistency here 17:21:13 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 +1 for the sgallagh's proposal as well 17:21:30 pjones: If we're defining a standard C toolchain we should do the same for other languages that have multiple options 17:21:31 mjg59: oh, you're *genuinely* saying we should pick a standard lisp? 17:21:35 #proposal "Packages may only build with an alternative compiler to gcc if upstream requires compiler-specific language extensions" 17:21:44 pjones: If possible, sure 17:21:48 sgallagh, +1 17:21:54 mjg59: Open a ticket for next week, please 17:22:27 sgallagh: can we not rush to vote on this while we're still discussing it? 17:22:29 pjones: so, you're saying that this proposal is solving a non-problem? 17:22:31 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 mitr: Right 17:22:39 notting: I'm saying it's making an existing problem worse 17:22:51 mitr: I just don't think there's a fundamental difference between C and any other language 17:22:56 pjones: No idea. But now instead of wondering, walking into a minefield, they at least know what we think currently. 17:23:02 pjones, how so? 17:23:04 And I don't think solving this argument purely for C is very helpful 17:23:17 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 i think attempting to redirect gcc development via our packaging policies is not the most direct of a lever 17:23:55 mjg59: yeah that makes sense to me 17:23:58 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 maybe we could allow also using clang where upstream is encouraging it as well? 17:24:13 notting: so we're trying to influence *every* upstream instead of just the one? 17:24:23 s/clang/alternative compiler/ 17:24:47 t8m: That runs straight into the "new features in toolchain" problem 17:24:49 Ok, so obvious straw-man argument: 17:24:55 "use the compiler prefered by upstream" 17:25:10 drago01: and that, I could get behind. 17:25:11 drago01: +1 17:25:13 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 I'd just like to prevent switching random packages to clang just because the pkg maintainer likes it. 17:25:29 mjg59: you know how I feel about that :) 17:25:48 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 t8m: and that's fair, but that's not what the earlier policy suggests - in fact it's much more modest 17:26:33 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 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 how is the policy of "only use if you don't have an alternative" more modest? 17:26:40 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 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 pjones: clang may be "sane", but suppose it doesn't have FORTIFY_SOURCE - which one is more important? 17:27:24 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 (Note: I haven't checked whether it supports that or not) 17:27:33 pjones: examples? 17:27:37 mitr: fair point 17:28:09 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 #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 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 Rationale: Platforms have one implementation of each component 17:29:13 mjg59: I can't see that we can be purely one or the other, ever 17:29:29 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 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 s/we // 17:30:15 but policy can be always changed 17:30:27 if it is not adequate any more 17:30:27 t8m: yes, but it's harder to change a policy than make a new one 17:30:31 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 Yes, the policy that's sensible today may be revised in a year 17:31:27 I still think either notting's/sgallagh proposal or the 'follow upstream' proposal can get enough votes today 17:31:40 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 mitr: In most cases (python, R, Java) we have a single implementation 17:32:24 mitr, most non-C languages do not have buffer overflows 17:32:50 so no need for things such as FORTIFY_SOURCE 17:32:50 sgallagh: techncially, we have 4 python runtimes, at least 17:32:52 (well, python and java have multiple versions too, but thats not a big deal) 17:32:55 t8m: I suppose... 17:33:05 nirik: Speak for yourself. :) 17:33:12 sgallagh: only two of them get used, and only one by the majority 17:33:37 notting: Ok, I suppose I should have limited myself to compiled languages rather than interpreted. 17:33:40 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 we're at ~30 m inutes? vote, continue discussion, or...? 17:33:49 And we have Guidelines around how to support both, but you have to support the default. 17:34:28 I'm ready to vote, but it seems like there's more discussion desired, and that's fine with me. 17:34:29 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 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 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 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 pjones: you're saying we should not standardize against that now? 17:35:14 mitr, +1 17:35:26 notting: do we have some reason to believe that pypy would decide to make everything abi incompatible? 17:35:36 pjones: it *is* now 17:35:43 oh, huh. well, okay :) 17:35:54 But I do see mitr's point 17:36:19 to mitr's point, i would rather do #4, and revisit later ,than #1 and deal with the fallout 17:36:21 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 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 anyhow, we should vote or table for more info, IMHO 17:37:11 nirik: extending gcc is also an option, at least in theory 17:37:12 Follow upstream seems logical, to a point. 17:37:31 mjg59: so we can't use blocks or clang's diagnostic features until gcc implements them? 17:37:53 (okay, argue against blocks, fine. diagnostic features? surely those are useful functionality?) 17:38:17 pjones: Can you expound a bit on the diagnostic features? 17:38:24 Are we just talking about its static analysis stuff? 17:38:29 diagnostic features can be used with local builds not necessarily have to be used within the distro packages 17:38:31 clang is much better at producing useful errors 17:38:36 sgallagh: e.g. http://clang.llvm.org/diagnostics.html 17:38:37 Because individual projects can take advantage without doing so in the final packages 17:38:46 yeah 17:38:59 sgallagh: http://clang.llvm.org/diagnostics.html 17:40:14 Proposal: Ask gcc and llvm maintainers for opinion about maintaining features in both at the same time, and revisit next week 17:40:22 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 pjones, why not?? 17:40:37 (I'm not sure that it will change anything - but we really didn't have expert input so far) 17:40:47 everyone wants to test things twice. not. 17:40:49 t8m: because it's a giant pain in the ass that's going to lead to even more bugs? 17:41:11 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 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 pjones: I meant upstreams can build with clang if they want to run diagnostics, but RPM builds should always be GCC 17:42:07 *where possible 17:42:24 sgallagh: so then when there's a bug in one or the other, all of upstream's testing is invalid 17:43:08 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 pjones: State your proposal, I will state mine, everyone can vote on the two. 17:43:17 Is that reasonable? 17:43:23 sgallagh, +1 17:43:26 sgallagh: sounds fine 17:44:20 #proposal Packages may only build with an alternative compiler to gcc if upstream does not support gcc 17:44:21 sgallagh: my proposal is that this doesn't merit changing our policies at this time 17:44:31 sgallagh, +1 17:44:35 * nirik is with pjones on this one. 17:44:37 (I've made that slightly simpler than before, to allow upstream more leeway) 17:44:48 pjones, -1 17:44:57 sgallagh: "support" means "is able to build with", or "recommends"? 17:45:29 Eh. I think I'm starting to lean more towards pjones here. 17:45:34 mitr: I suppose recommends is probably closer to what I meant. 17:45:56 In that case I'm... not sure there is any difference between the two :) 17:46:02 But with a stronger preference towards gcc if possible 17:46:34 mitr: A recommendation is different from a mandate 17:46:42 +1 to sgallagh's proposal 17:46:43 "We prefer clang but work with gcc" -> GCC 17:46:48 i'd prefer it be stronger 17:47:10 +1 sgallagh 17:47:12 I'd prefer it to be a bit stronger, but can be +1 to sgallagh's proposal 17:47:18 pjones, if $random maintainers start patching their packages to build with clang will we make the policy? 17:47:25 +1 for sgallagh 17:47:32 I'm willing to revise the text of it if you have better phrasing 17:47:53 t8m: is there any evidence anybody is clamoring to do that? 17:48:03 t8m: if that becomes a thing, I'm all for more discussion 17:48:18 I see 6 votes for sgallagh's proposal. 17:48:40 (if sgallagh votes for it) 17:48:46 +1 ;-) 17:49:10 Clearly not a consensus, but I think that's a decision at least 17:50:06 indeed. shall we move on? 17:50:18 please 17:50:27 :) 17:50:30 #agreed Packages may only build with an alternative compiler to gcc if upstream does not support gcc (6 +1) 17:50:37 #topic #849 Build and host request for French live ISOs 17:50:37 .fesco 849 17:50:40 sgallagh: #849 (Build and host request for French live ISOs) – FESCo - https://fedorahosted.org/fesco/ticket/849 17:51:01 this is a fesco issue? 17:51:17 I think this is more Board+Releng 17:51:18 doesn't seem like it. 17:51:20 i suppose as those above releng, it is 17:51:22 sgallagh, +1 17:51:36 we have not done any official localized spins/releases. 17:51:38 historically we don't host localized live images, *i think* 17:51:51 I think we have had other requests in the past we turned down too. 17:52:09 I think this should be really decided by board 17:52:10 nirik: Whether to host localized images or not sounds like it should be a Board policy decision 17:52:16 Is this something for http://fedoraproject.org/wiki/Spins_Process ? 17:52:20 Yeah, I really don't think this is for us 17:52:57 #proposal Send this to the Fedora Advisory Board 17:53:08 sgallagh, +1 17:53:29 +1. suggest releng and infrastructure join the discussion there 17:53:31 sure, I suppose so. 17:53:56 yeah 17:54:46 +1 17:54:48 +1 17:55:33 I count 7 +1, assuming nirik's "I suppose so" counts 17:55:39 yes, +1 17:55:58 +1, I suppose (... what _is_ the right process here? but at least it is in the right direction) 17:56:47 mitr: historically, "we don't do this". changing the "we don't do this" is not exactly our decision. so, ... punt! 17:56:50 who's missing? 17:57:26 limburgher: Just for the record? 17:58:15 #agreed Send this to the Fedora Advisory Board (8 +1) 17:58:16 +1 17:58:21 #undo 17:58:21 Removing item from minutes: 17:58:23 #agreed Send this to the Fedora Advisory Board (9 +1) 17:58:30 Sorry. :) 17:58:31 Your timing is impeccable 17:58:36 As always. 17:58:36 #topic #850 Unmounting USB devices is unsafe in Fedora 17 17:58:37 .fesco 850 17:58:38 sgallagh: #850 (Unmounting USB devices is unsafe in Fedora 17) – FESCo - https://fedorahosted.org/fesco/ticket/850 17:59:30 This worries me. 17:59:39 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 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 I don't like the phrase "loss of user data" at all 18:00:18 This is no worse than F15 or F16, right? 18:00:18 I think it is more a disconnect between kparal and us than 'the rest of fedora' but nevermind 18:00:21 nirik: Depends on what "clean" means - apparently we can have a working GUI, just not "the" GUI 18:00:31 mjg59: No, this works fine in F1[56] 18:00:35 mclasen: Sorry, didn't mean to overdramatize 18:00:37 mjg59: no. 18:00:44 Ok, that's less attractive 18:00:46 I think some quick/nasty hack is really needed. 18:00:52 anyhow, it is a blocker... so... what can we do to help out here? 18:01:02 "Easiest" "solution" would be to just mount all removable media sync, regardless of filesystem 18:01:15 nirik, say, that we support the QA decision for making it blocker? 18:01:27 Then unmount would have nothing to write back 18:01:39 I suppose... it then seems not too pointfull to bring it to us. ;) 18:01:41 mjg59: Is the Linux kernel actually guaraneeing that "sync" implies "sudden unmount won't lose data"? 18:01:48 mitr: No 18:01:51 mjg59: which isn't a terrible idea anyway... 18:01:56 nirik: Apparently it's bouncing back and forth between blocker and non-blocker 18:01:59 pjones: It kind of is for people with USB hard drives 18:02:03 nirik: QA says blocker, GNOME says not 18:02:30 fair enough I guess if those are showing as removeable... the one I've got doesn't. 18:02:34 I fail to see how this wouldn't be. 18:02:46 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 I don't find David's position hugely compelling, given that several recognisable brands don't have LEDs 18:02:51 mclasen: Would you mind stating your position? 18:03:17 mjg59: yeah, relying on LED feedback from usb devices is clearly a non-starter 18:03:19 * kparal is also present 18:03:24 not enough users lost data for it being a blocker? 18:03:28 mclasen: Given how few people actually use the alpha/beta releases... I don't find it that surprising. 18:03:31 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 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 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 mitr, +1 18:03:45 mitr: If there are dirty buffers then that umount() can take a while 18:03:47 t8m: not enough users noticed losing data and correctly tracked it back to this for it to be a blocker? 18:04:00 pjones, perhaps ;) 18:04:07 mitr: Mounting sync means that there should never be dirty buffers 18:04:08 mjg59: Which I greatly prefer to lost baby pictures. 18:04:10 notting: yeah, before release... we are very low on time unless we slip a lot 18:04:46 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 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 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 Then I say mount sync. Better slow than unreliable. 18:05:39 mclasen: Hypothetically, how much time (estimated) would it take to reimplement if you had a resource available. 18:05:42 I don't have any opinion on mounting sync - if that fixes the problem, fine with me 18:05:52 mitr: well, we should not count on that. Things could align. ;) 18:05:53 Let me check with some fs people 18:05:55 sgallagh: There is already a tentative plan at https://bugzilla.redhat.com/show_bug.cgi?id=819492#c24 18:06:15 mitr: only hits one of two apps 18:06:41 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 mclasen: Any opinion on feasibility of the plan linked above? 18:07:15 mitr, isn't the solution preferred by upstream also per-app? 18:07:52 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 nirik: Yes, at least affirming the blockerosity. 18:08:33 nirik, +1 18:09:03 Yes, +1 blocker 18:09:05 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 but +1 for affirming the blocking status 18:09:26 it's blocker +1 18:09:29 Sure, +1 18:09:36 +1 18:10:17 +1 to blocker. too much risk of data corruption 18:10:30 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 yes, +1 18:11:26 #agreed USB unmounting issue is a blocker, needs immediate attention (9 +1) 18:11:34 #topic #851 F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng 18:11:34 .fesco 851 18:11:36 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 +1 18:11:48 +! 18:11:52 +1 that is 18:11:56 +¡ 18:11:57 +1 18:11:59 +1 18:12:16 (joking, also +1) 18:12:17 (aside: stop the -ng naming already) 18:12:18 +1 18:12:22 * mclasen doesn't agree, but will happily review a patch to mount sync 18:12:26 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 +1 18:12:57 So, this is primarily a package renaming + incompatible changes (which will, sadly, probably not be all enumerated) 18:13:00 +1 18:13:02 +1 18:13:03 notting: should rename to procpsKit-ng ? :) 18:13:19 *shrug* they bumped the version number. just call it procps. 18:13:26 Fedora Unix-ng? 18:14:12 I guess other distro are also using and developing it :) 18:14:47 #agreed Feature procps-ng is accepted (9 +1) 18:14:52 #topic #852 F18 Feature: OpenShift Origin - https://fedoraproject.org/wiki/Features/OpenShift_Origin 18:14:52 .fesco 852 18:14:53 sgallagh: #852 (F18 Feature: OpenShift Origin - https://fedoraproject.org/wiki/Features/OpenShift_Origin) – FESCo - https://fedorahosted.org/fesco/ticket/852 18:15:05 this is the next X-Men sequel? 18:15:16 when looking at the util-linux->util-linux-ng->util-linux then procps should really skip the -ng step 18:15:21 pjones: Jinx 18:15:29 +1 18:15:30 +1 18:15:31 +1 18:15:33 +1 18:15:34 sure, +1 18:15:34 +1 18:15:34 +1 18:15:37 +1 18:15:37 +1 18:16:02 #agreed Feature: OpenShift Origin is accepted (9 +1) 18:16:06 #topic #853 F18 Feature: New Installer UI - https://fedoraproject.org/wiki/Features/NewInstallerUI 18:16:06 .fesco 853 18:16:08 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 +1. hope it makes it. ;) 18:16:32 I' 18:16:40 +1 18:16:41 I'm somewhat concerned about the lack of a text UI 18:16:46 What does this mean for headless installation? 18:16:52 +1 18:16:59 sgallagh: the text UI has been declared and announced deprecated for like a dozen releases now? 18:17:07 +1 18:17:08 I suppose kickstart installs will be supported 18:17:09 sgallagh: "use VNC", I suppose - although it hasn't been explicitly mentioned. Can anone confirm that? 18:17:10 sgallagh: It means VNC or Kickstart 18:17:11 headless -> vnc as usual 18:17:26 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 mitr: kickstart will still work as well 18:17:55 Ok, as long as we have a kickstart guarantee. 18:18:00 +1 Though I don't love skipping textmode for a release. . . 18:18:03 This was not called out in the Feature 18:18:28 Light +1 18:18:30 pjones: I don't really view that as an interactive alternative - but I'm perfecly fine with VNC 18:18:44 will the existing kickstarts be compatible? 18:18:50 +1 - let's see how that hub/spoke model works out 18:18:59 sure, i can amend with: 'please mention the removal of the TUI more broadly' 18:19:10 t8m: pykickstart has a very comprehensive backward compatibility mechanism 18:19:21 t8m: 'as much as they are for any other new release' 18:19:25 sgallagh: the new design involves running the entire installation /as/ a kickstart. kickstart is certainly guaranteed :) 18:19:33 pjones: Works for me 18:19:35 notting, fine 18:19:43 for example, i could imagine firewalld causing changes to the firewall line in kickstart 18:19:51 #agreed Feature: New Installer UI is accepted (9 +1) 18:20:01 notting, I understand 18:20:11 #topic Next week's chair 18:20:21 Who's foolish enough to volunteer for next week? 18:20:32 heh I can do 18:20:38 Works for me 18:20:47 #agreed t8m will chair the 2012-05-21 meeting 18:20:53 #topic Open Floor 18:20:54 ? 18:21:14 nb: Do you have something for Open Floor? 18:21:30 yes 18:21:34 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 it should certainly be in the release notes if it doesn't get changed 18:21:51 Let's see if there's a reasonable workaround first 18:21:51 nb: Our current view is that we need a solution 18:21:55 * mitr still hopes for a software fix 18:22:01 but that's too soon to say "put it in there now" 18:22:04 But if none is reached, yes we'll need a call-out in the release notes 18:22:05 Will someone open an FPC ticket for the compiler thing? 18:22:26 ok 18:22:49 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 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 nb: Perhaps just give the docs team a heads up to let them prepare if they can? 18:23:23 yeah 18:23:24 tibbs|w: I'll take care of opening that ticket after the meeting 18:23:33 #action sgallagh to file FPC ticket for new compiler policy 18:23:40 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 we also need a board ticket about the localized composes 18:24:02 we can usually get changes pushed ASAP if we need to amke a last minute change 18:24:05 I guess I'll do that too 18:24:07 as long as final RC hasn't been spun yet 18:24:21 so if we want to wait, that can be done too 18:24:35 #action sgallagh to file an Advisory Board ticket for the localized compose 18:26:01 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 hey, saves me from doing it 18:26:13 thx 18:26:48 nirik: Also, I believe we do not as yet have enough nominees to hold a vote 18:26:58 yeah, need more. 18:27:18 * mitr counts 6 nominees for 5 seats 18:27:48 mitr: Yeah, election policy requires 7 nominees for 5 seats, IIRC 18:27:49 ... one of which was added in the last two minutes 18:27:55 Ah 18:28:16 (give or take, via caching) 18:28:31 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 I know one other person who was at least /considering/ running who's not on there yet 18:29:47 notting: Are you stepping down? 18:29:51 no 18:29:59 just hadn't got around to adding myself to the list yet 18:30:03 Well, then we've got 7 just as soon as you edit the wiki 18:30:04 ah ok 18:30:17 * limburgher pokes notting with stick toward wiki 18:30:45 ... done. 18:31:00 Ok, any other business? 18:32:32 None here. 18:32:46 * nirik has nothing 18:33:00 I'll close out the meeting in two minutes if no one has anything else 18:35:13 #endmeeting