20:06:17 <jds2001> #startmeeting FESCo townhall
20:06:17 <zodbot> Meeting started Thu May 31 20:06:17 2012 UTC.  The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:06:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:06:51 <jds2001> #meetingname FESCo townhall
20:06:51 <zodbot> The meeting name has been set to 'fesco_townhall'
20:07:06 <nirik> (it started the meeting, just didn't change the topic)
20:07:15 <jds2001> didnt know if it worked if the bot had no voice :)
20:07:27 <nirik> yeah, it just couldn't change the /topic
20:07:52 <jds2001> #topic introductions
20:08:10 <jds2001> this is the FESCo townhall, would the candidates like to introduce themselves?
20:08:26 <jds2001> top to bottom on the wiki :)
20:08:26 <pjones> Hi, I'm Peter Jones, and I work on Fedora.
20:08:37 <pjones> Oh you want us to order them.  Oops.
20:08:42 <jds2001> pjones, sgallagh, nirik, affix, t8m
20:09:01 <jds2001> pjones: you were first anyhow :)
20:09:26 <sgallagh> Hi, I'm Steve Gallagher and I'm an upstream developer, Red Hat employee and just survived my first term as a member of FESCo.
20:09:30 <pjones> Last one of these we didn't bother with introductions since we figured http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations#Introductions would suffice.
20:10:12 <jds2001> ahh, whatever :)
20:10:14 <notting> jds2001: where do i fit in?
20:10:20 <jds2001> im flexible, however you want to do it :)
20:10:29 <jds2001> notting: didnt see you show up :)
20:10:46 <jds2001> notting: last, i guess
20:10:46 <nirik> I'm Kevin Fenzi. I'm the Fedora Infrastructure lead working for Red Hat for the last year or so. I've been involved in Fedora since about 2005 and a RHL user since 3.0.3. I try and help others get stuff done in Fedora.
20:10:56 * nirik has a trigger finger again. sorry.
20:13:33 <jds2001> #info candidate info can be found at http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
20:14:04 <jds2001> so how this works is folks can ask questions over in #fedora-townhall-public and I can queue them up to ask the candidates.
20:14:13 <t8m> As I've already typed it - I'm Tomáš Mráz, Red Hat employee in Security Engineering for some years, and a FESCo member for one term.
20:16:49 <jds2001> so, lacking questions in -public, I'll ask one myself: how can the boot process of Fedora be improved? Anything is fair game here.
20:17:28 <jds2001> (UEFI, systemd, GPT-on-BIOS-boot, etc)
20:17:42 <pjones> jds2001: Well, for one, I'm busy implementing a feature for grub2 where we can tell if the previous boot failed and thus select a remedial action from the bootloader.
20:18:09 <pjones> There are probably ways that aren't *so* specific to bootloader technology, but I've got my head down pretty deep on this aspect.
20:18:12 <notting> 1) we could only support one hardware platform. that would simplify things. more seriously, a 'safemode' boot as pjones suggests can be useful
20:18:39 <nirik> A: well, from the FESCo side all we can do is help get the people doing the work whatever we can. ;) We are at the mercy of other forces, so we will have to do the best we can for Fedora.
20:19:30 <t8m> that's really a question for pjones :) but certainly the current state of grub2 as in Fedora 17 in comparison to grub 1 in regards to easy configurability etc. is quite bad - and I don't say that's pjones to be blamed for that
20:19:41 <pjones> notting: yo dog I'm cool with supporting only one hardware platform, but can it *not* be the mac?
20:19:57 <pjones> t8m: working on it.
20:20:14 <t8m> pjones, great
20:20:34 <sgallagh> 1) At the risk of saying "me too", I agree that there's little we can do directly as members of FESCo, other than encouraging and facilitating upstream efforts here.
20:20:40 <t8m> from the FESCo perspective we can probably just encourage pjones to continue work on it
20:20:50 <notting> 1) also, on-demand lvm/device mapper/etc activation would be nice.
20:20:51 <sgallagh> And helping mitigate the move to UEFI and secure bootloaders as best as possible
20:21:06 <sgallagh> s/mitigate/mitigate issues with/
20:21:18 <pjones> t8m: I am assuming he means the entire boot process, not just the first 100ms (or 5 seconds...) of it.
20:21:51 <pjones> sgallagh: yeah, doing what we can there too.  I don't think he actually meant this as a question about bootloaders.
20:22:26 <jds2001> pjones: no, the entire process was fair game :)
20:22:52 <jds2001> but we have another question now if we're done here...
20:23:07 <sgallagh> I'd like to put a little pressure on the graphical boot team to get some useful information for the luks password prompt
20:23:59 <jds2001> #topic 16:18 < calimocho> Q: what is something that fedora is doing wrong or missing? How can it be fixed?
20:25:08 <pjones> Well, there's a split between the things that need to be encouraged and the people with the purse strings - from fesco perspective, we see a lot of things, especially infrastructure things, that'd it would be nice to be able to address by more direct applications of manpower.
20:25:20 <pjones> But of course we don't control manpower - we can't direct people to work on specific things.
20:25:38 <pjones> That's worth working with the board to find some better plans for.
20:25:42 <sgallagh> 2) Well, pjones beat me to the same answer, so yeah
20:25:58 <nirik> A: Thats pretty broad. ;) I think there are many areas where we can keep improving, but don't feel are "broken". I'd like to try and get more contributors, perhaps look at other areas where we might be able to do this. I'd like us to make sure we are good for content producing. I think we all agree our feature process could be revamped.
20:26:27 <notting> 2) we need more continuous integration, automated testing, feeding of those results back into the system, and using it for actions. Fixing that... is a lot of interested manpower to work on the infrastructure.
20:27:05 <t8m> 2) I'm afraid this is too unspecific question. Maybe some better coordination between various teams and and individual maintainers. And sure more hands in the infrastructure would be nice but that will be hardly fixed without monetary incentives.
20:27:18 <sgallagh> 2) I'd also think one thing we need to improve is our bodhi update mechanism. I've raised concerns about dealing with inter-package updates in the past, and I'd like to continue to drive for better dependency handling.
20:27:36 * nirik notes bodhi 2.0 is under development now.
20:28:31 <sgallagh> Yes, and I'm trying to insinuate myself into as many discussions on it as possible :)
20:30:27 <jds2001> ok, let's get more controversial (and back to boot!)
20:30:40 <jds2001> #topic What do you think of the proposal to use Microsoft as a signing authority for all systems implementing secure boot?  http://mjg59.dreamwidth.org/12368.html
20:31:22 <nirik> 3) I think it sucks. But sadly it looks like the best choice of a bunch of bad options. I'd love for their to be a better way, but I can't see one based on what I know...
20:31:43 <sgallagh> 3) I think the proposal as written is making the best of a bad situation. Boot malware is a real threat that needs to be mitigated, and pki cryptography is a difficult problem.
20:32:36 <sgallagh> 3) I will note that the question is a bit misleading. MS is simply the path of least effort for valid signing, but it's still possible to generate your own authority and trust that.
20:32:56 <pjones> 3) I really don't like that we're in this position, but I've worked quite a bit to try to get us into some other position, and that really didn't work.  So now I'm working on making us be able to stay installable on new hardware.
20:32:57 <sgallagh> I'm going to be pushing the FreeIPA/Dogtag teams to look into ways to make this easy
20:32:58 <t8m> 3) I think Fedora should not be hasty to use the MSFT signed key. We definitely should implement solutions to be able to use it but we should not actively promote the dependency on proprietary data.
20:33:29 <t8m> 3) Even at expense of requiring users to switch the secure boot off or sign&load their own keys
20:34:10 <pjones> t8m: I'm not sure why you think we're being hasty.  We discussed other options with other vendors (hardware and software) for most of a year, which was private because that's the only way we were allowed to be in the conversation.  We're still looking for other solutions.
20:34:22 <notting> 3) It's ugly. I would greatly prefer a vendor-neutral CA, but there does not appear to be an initiative to create one of those (and Fedora certainly isn't going to be that)
20:34:24 <pjones> t8m: but just because we don't like the situation doesn't mean we shouldn't act on it.
20:34:25 <t8m> 3) And I do not agree this really solves the problem of boot malware or that the problem of boot malware is so dire.
20:34:37 <pjones> notting: also see my email on that topic.
20:35:51 <pjones> t8m: perhaps we can talk about the first part of that in another venue.  The latter part - it doesn't matter how dire it is.  The hardware vendors will disable our ability to install without first tweaking the firmware.
20:36:08 <notting> 3) Probably the simplest solution would be for the creators of UEFI systems to work together on this , as they can certainly exert more pressure than Fedora ever could.  If the issue were to come to FESCo, my initial lean would be to approve it.
20:36:48 <t8m> pjones, there will be no push against hw vendors to not make the boot locked then
20:37:52 <pjones> t8m: we an ubuntu have been the only voice against it.  the hardware vendors would rather close off the attack vector, and while you don't believe this does that, they do.
20:38:12 <pjones> ^and
20:38:25 * nirik doesn't think trying to inconvience our users a lot would push vedors much either. It would just make our users mad and upset.
20:38:25 <jds2001> anyhow, shall we move on?
20:38:46 <notting> 3) as nirik said, Fedora is not operating from a position of leverage here
20:39:10 <pjones> jds2001: sure!
20:39:14 <jds2001> #topic 16:25 < mdomsch> Q: There is a good argument to be made that the current Fedora / EPEL structure isn't suitable for 3rd parties to leverage.  For example, maintaining multiple releases of  higher-level cloud stacks (OpenStack, CloudStack, Eucalyptus, ...) within the distribution.  Do you think Fedora should be usable for such, and if so, what changes would  you propose to enable such?
20:39:35 <jds2001> http://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/
20:41:11 <sgallagh> 4) I'm sure that argument could be made for EPEL, but I disagree in terms of Fedora.
20:41:20 <nirik> 4) I think many cloud stacks are still under rapid development, and may not yet be something that is very suitable for EPEL (being a longer term stable type setup). Perhaps a EPEL advanced tech repo or something would be a better fit, but thats going to be work to implement. Or perhaps it would make sense for them to wait until a time when they have a stable setup they are willing to support for years.
20:41:29 <sgallagh> 4) EPEL  has all sorts of upgrade and compatibility restrictions that Fedora doesn't have
20:41:51 <pjones> 4) I think I'd be interested, as somebody who has to approve fedora features, I'd be interested in proposals to modify our packaging tools to make that sort of thing simpler.
20:42:12 <t8m> 4) I'm not really sure this is a problem that FESCo can solve. This is rather question for board.
20:42:13 <sgallagh> As far as inclusion in Fedora, I think the main issue is ISVs developing atop their own dependency stacks and needing to work out a way to get those dependencies packaged first.
20:43:25 <pjones> t8m: I really don't think it's a problem for the board except in the "should this be a priority" aspect. I think it's a problem for people developing our infrastructure - do we want to make it easier for them?  there are certainly things we could do, but they require re-prioritizing other things for finding more people to work on the problems.
20:44:13 <notting> 4) It would be nice if Fedora had a better ISV presence, certainly. Of course, the support lifecycle makes it problematic for deploying services, which limits the practical use.  From an ISV perspective, it is much easier for them to keep their single stack working on released products, rather than working through the Fedora development cycle to keep it continually working there. Not sure there are easy answers.
20:44:36 <sgallagh> At the end of the day, it's a cost-value proposition: Is maintaining packages (and their dependencies) a value-add from the ISV's perspective? Usually the answer is that the costs outweigh the value unless you happen to have an evangelist on staff.
20:45:10 <t8m> pjones, who gives directions for infrastructure people for what is the priority? isn't that board?
20:45:28 <notting> 4) Especially given that the incentive for ISVs to adhere to assorted Fedora guidelines just isn't there
20:45:50 <pjones> t8m: yes, that's why I said it's not the board's problem /except/ for prioritizing things.  But if individuals want to help building tools to do more, they can do it without the board.
20:46:06 <pjones> t8m: and if it came to fesco as a feature, I'd certainly encourage it.
20:47:16 <t8m> 4) on the other hand I can see that perhaps some of the packaging rules are overly restrictive and that might prevent some ISVs from entering Fedora but then it is a question for FPC only if there is concrete conflict FESCo can come in play
20:48:41 <jds2001> im fresh out of questions over in -public :)
20:52:08 <jds2001> ok, we have some...
20:52:14 <jds2001> #topic When it comes to approving new features, are you willing to trust maintainers to do things right or are there features you would never approve?  If so, what kinds, and for  what reasons?
20:52:39 <pjones> of course there are features we would never approve - there have been in the past, and there will be again.
20:52:59 <pjones> for example, we would never approve of a secondary arch becoming primary if it would be /completely/ disruptive to the existing primary arches.
20:52:59 <sgallagh> Yes, there have been many occasions where we've said "no"
20:53:02 <notting> 5) Of course there are features that would never get approved. Heck, a couple of weeks ago someone submitted a ticket about packaging yum repo files with enabled=0 in their packages that pointed to fedorapeople
20:53:21 <sgallagh> In some cases that's "No, it's not ready", in others it's fundamentally disapproved.
20:53:51 <nirik> 5) yeah, as others have noted we have said no to features before. Often because there was no one doing the work, or they had not seen a better already implemented solution to their plan.
20:54:33 <nirik> 5) I think even these are good to have though, because sometimes someone will see a feature like that and start working on it, or get ideas on how to better solve it. There's nothing wrong with saying no and getting a better thing in the end.
20:55:04 <t8m> 5) Surely there are features that would never get approved. Some examples were already written above.
20:55:36 <pjones> sgallagh: certainly - as in my previous example, when this has come up we've helped to lay out a plan for improving the situation
20:56:16 <sgallagh> pjones: I don't disagree in the slightest.
20:56:24 <jds2001> we have one more that i'd like to get to if folks have time
20:56:41 * sgallagh is fine with that
20:56:42 * jds2001 realizes we're running over here a bit
20:57:06 * nirik is ok with that
20:57:19 <jds2001> #topic What role do you want to see secondary arches take in future development?
20:57:42 <pjones> I think if anything secondaries are going to be a much bigger deal in the future
20:58:09 <pjones> as the market moves towards various embedded platforms, for example, those platforms will spend some time as secondaries, and at the same time, they'll become more important and influential
20:58:35 <sgallagh> I think we're going to see a rapid shift towards ARM platforms in the near future (2-3 years) and Fedora needs to be prepared for that.
20:58:47 <notting> 6) I'd like to see them more active; that's obviously a truism, though. For secondary arches that are emerging in the market, they should help drive new features that help them
20:59:02 <sgallagh> Besides ARM, I expect to see a tendency towards obsolescence in the currently-available secondary arches
20:59:05 <nirik> I think we are going to see a lot more from arm in particular, and I am looking forward to them joining in as a primary (assuming they do, which I think likely). I think we may also hopefully make it easier moving forward for other secondary arches... like perhaps x32 if someone(s) are willing to drive that.
21:00:08 <pjones> sgallagh: I think there's always going to be something new and upcoming that's disruptive, and we're going to have to work with that, even if we can't predict what the next one will be right now.
21:00:47 <sgallagh> pjones: Sure, which is why I limited my comment to *currently-available* secondary arches :)
21:01:14 <sgallagh> I mean, I suppose it's *possible* that s390 will suddenly revitalize... but I'm not betting on it.
21:01:32 <t8m> 6) Surely the ARM efforts already made secondary architectures more interesting and active thing and I actually think it is very good to have the software built on multiple architectures as it eliminates subtle bugs that could go unnoticed if built only on single or two architectures
21:02:35 <pjones> sgallagh: Well, IBM has recently become more involved with ppc, for example.  I don't see any reason it couldn't become more important again with more people available to put work into it.
21:02:44 <notting> 6) in a real sense, we have multiple categories of secondary arches now ... emerging technologies (arm), corporate interest ones (power, s390), and windmill-tilting (sparc). so, each of these would likely interact differently
21:02:45 <sgallagh> t8m: Agreed. I for one have been bitten several times lately by endianness and alignment issues.
21:05:02 <pjones> same as it ever was
21:06:26 <jds2001> well, I think that's all the time that we've got. Anyone have any closing remarks?
21:07:25 <notting> pjones: asking yourself how you got here?
21:07:33 <nirik> Do get out and vote!
21:07:45 <jds2001> nirik: +10000
21:07:48 <sgallagh> Closing remark: Fedora is a wonderful environment of dissenting viewpoints all working towards a better future. I'm excited to be a part of it.
21:07:53 <t8m> This time no closing remarks.
21:07:57 <sgallagh> So vote! (Preferably for me)
21:08:02 <nirik> or rather since it's all electronic, stay in and vote. ;)
21:08:12 <pjones> Vote for me.  Then vote for some other people with smaller numbers!
21:08:40 <notting> Vote your feelings, your conscience, your preference for colors, or whatever. But please, get involved.
21:09:36 <jds2001> alrighty, thanks everyone!
21:09:42 <jds2001> #endmeeting