18:00:38 <nirik> #startmeeting FESCo Townhall (2014-01-31)
18:00:38 <zodbot> Meeting started Fri Jan 31 18:00:38 2014 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:38 <nirik> #topic introduction
18:00:57 <nirik> Welcome everyone to our FESCo townhall.·
18:00:57 <nirik> This is your chance to ask candidates for FESCo questions.·
18:00:57 <nirik> Some candidates are traveling today and are unable to attend.·
18:00:57 <nirik> Candidates have also been asked questions on the wiki in the questionare:·
18:00:57 <nirik> https://fedoraproject.org/wiki/Elections/Questionnaire#Fedora_Engineering_Steering_Committee_.28FESCo.29
18:00:59 <nirik> I'll take questions asked in #fedora-townhall-public and ask them in order to candidates.·
18:01:01 <nirik> Please preface your answer with the number of the question you are answering.·
18:02:09 <nirik> if the candidates would like to give a short introduction of themselves first, we can then move right on to questions. ;)
18:02:16 <nirik> abadger1999 / mitr: are you here?
18:02:30 <mitr> yes, hello
18:05:02 <abadger1999> Hey I'm here now.
18:05:30 <nirik> can you all give a short intro on who you are and why you are running for fesco?
18:06:04 <kylem> Hi, I'm Kyle McMartin. I've worked for Red Hat for several (almost 7) years and have been involved heavily in Fedora for the entire time. My expertise is in the kernel, and some of you may remember me from being a Fedora kernel maintainer. Nowadays I've been heavily involved in ARM and AArch64. I'd like to bring this technical expertise to FESCo (I was on it several years ago, but didn't run for a second term.)
18:07:20 <abadger1999> Hi, I'm Toshio Kuratomi.  I've been a long time Fedora Packager, Packaging Committee member, member of hte infrastructure team.  Served of fesco and the board in the past.  I'm running for fesco to hopefully help with coordinating changes due to fedora.next.
18:07:32 <mitr> [introduction] My name is Miloslav Trmač; Currently I'm a FESCo and Server WG member, and a security architect at Red Hat. I've been a contributor since Red Hat (non-Enterprise) Linux times, and I have worked on all parts of the technology stack (from kernel through basic infrastructure to desktop and web applications). Author of the Fedora signing server.   I want to ensure the new Fedora products, and the larger package ecosystem aroun
18:07:34 <mitr> d them, form a coordinated and well-integrated universe.
18:08:00 <nirik> excellent. welcome all, lets move on to questions. :)
18:08:18 <nirik> reminder: please preface your answers with the question number you are answering. :)
18:08:28 <nirik> #topic question one
18:08:31 <nirik> 1. From mhare: With the fast pace of changes in the core codebase powering the Linux platform today, how do you balance compatibility with technical progress?
18:10:20 <kylem> 1/ I'm not entirely sure what we want to define compatibility is... very little of the platform has changed. We've done an excellent job ensuring old-style init scripts work, that we continue to ship older libraries so they continue to work (think gtk1 through gtk3...), and so forth. I'd be able to better answer if it was more specific.
18:12:23 <mitr> 1. "The Linux platform" (i.e. the core API) is actually remarkably stable (but also shrinking, with introduction of containers towards just kernel + libc it seems).  Outside of that (command line, GUI, other libraries) we've always distinctly favored technical progress over compatibility.  It seems that compatibility just hasn't been valued that much; if it _were_ valued, there are known technical solutions (library/symbol/SDK versioning)
18:12:25 <mitr> that would require some, but fairly small, changes to the core tooling - but it doesn't seem too likely.  Within the Server WG we've been talking about providing a stable API for the new "server roles" as something fairly small, which we _know_ to be valuable; we'll see whether that can succeed.
18:13:21 <mitr> (... "we know to be valuable" to have an API for managing servers, not to have something fairly small)
18:13:22 <abadger1999> 1/ Traditionally Fedora has valued progress over compatibility and let other products (like rhel/centos) assume the compatibility burden.  I think that we need to swing the balance somewhat if we're going to appeal more to server use cases but we have to be careful not to swing the balance too much as it takes more contributor time to do more compatibility work.
18:14:10 <nirik> moving on to question 2...
18:14:22 <nirik> #topic question 2
18:14:24 <nirik> 2. From mayorga: Many GNU/Linux distributions has adopted rolling release scheme. Do you think that it would fit well for Fedora?
18:14:53 <abadger1999> 1/ Of present prposals I've seen, I favour keeping a fauirly fast moving system and having stable platforms built on top of it.  Things like scls, backwards compat stacks, images that run on fedora, etc.
18:15:36 <abadger1999> 2/ In the old days we talked about having a Fedora Core on a release cycle and a Fedora Extras on a rolling release.  I think it might make sense to consider such a split again.
18:16:16 <abadger1999> 2/ I don't think that having the entirety of the distribution be rolling is necessarily a good fit for the target audiences that the new Fedora products are looking to address.
18:16:37 <kylem> 2/ It really depends. Obviously I'm in favour of rawhide always working, and it's improved markedly in the last few years. That said, many other distributions have the luxury of being able to take advantage of us having debugged integration issues in upstream projects first, so they may have an easier time of it. I think it comes down to balancing what our value of "First" is. Many of the Fedora core components are maintained by the upstr
18:16:48 <mitr> 2. Currently, not at all; we don't are not even close to having the necessary tooling to ensure quality/ability of users to upgrade (currently getting a Fedora release out requires extraordinary feats of heroism from the Fedora QA, which we just can't be doing weekly-release-to-weekly-release).  I _would_ like the QA tooling and the upgrade mechanisms to become so good that upgrades became completely painless or even invisible, and then w
18:16:50 <mitr> e could consider a rolling release - but I don't think it's likely within the next, say, 5 years.
18:16:53 <kylem> 2-cont/ which is a major boon for users, since fixes get in first too.
18:18:02 <nirik> ok, moving on to question 3 then...
18:18:13 <nirik> #topic question 3
18:18:16 <nirik> 3. From pjones: Do you think that distributing or closed source software, or metadata that would set it up to be installed, is in any way compatible with our technical goals /or/ the foundations listed at: https://fedoraproject.org/wiki/Foundations ?  And if so, how?
18:20:22 <kylem> 3/ As long as Freedom is a pillar (and the first listed, despite not being alphabetically sorted, probably intentionally ;-) I think we should continue to strive to make sure the whole system is as free as possible, without compromises.
18:21:07 <kylem> 3-cont/ For instance, years ago, we could have compromised freedom and shipped the nvidia driver, like Ubuntu does. But would nouveau work (fairly amazingly) well on such a broad range of laptops if we had?
18:21:19 <kylem> s/laptops/hardware/
18:21:36 <abadger1999> 3/ I think it is compatible with some of our technical goals.  I think that the foundations can easily be interpreted as incompatible  (and are presently being interpreted that way).  In particular, for a lot of people, the freedom foundation means that we shouldn't be pointing to nonfree software, that's up to someone else to do.  To be clear , though -- I'm not 100% opposed to that foundation changing, I'd just want it to be a conscious
18:21:37 <abadger1999> decision that can be applied consistently to all of our choices.
18:22:03 <mitr> 3. (This is the authority of Board, not FESCo, to decide.  Within FESCo, if elected, I will always leave this to the Board)  We haven't had any explicit technical goals; I'll for now assume technical goals to be a subset of the more general "advancing software ... freedom". Distributing closed source software is explicitly contrary to the Freedom Foundation ("releases that are ... 100% legally redistributable for everyone").  I don't see
18:22:05 <mitr> distributing metadata is incompatible with the Foundations, and I don't think "willful ignorance" of proprietary software is at all helpful to the Freedom Foundation; in fact, it may even depreive us of the ability to educate the user about Free Software, or to promote Free Software (which _is_ required by the Freedom foundation).  See my election questionnaire for my more detailed thoughts.
18:22:27 <kylem> 3-cont2/ We don't make it purposefully difficult to install such things, either. So I really don't see what the fuss is about.
18:23:07 <abadger1999> mitr: Good point about the essential question of compatibility with the foundations being a Board question.  That's something I agree with.
18:23:23 <nirik> we have a 3b followup (and later another related one)...
18:23:27 <nirik> 3b. From randomuser: Do you consider shipping repo files, pointers to metadata, pointers to a third party, or other forms of indirectly providing third party software to users to be an acceptable compromise?
18:23:48 <abadger1999> 3b/ no.
18:25:16 <abadger1999> 3b/ I think the Board decision from last week eliminated those.  However, it was a close vote in the Board so eventually we would need more input from them as to where the dividing line of acceptable vs not-acceptable is.
18:25:19 <kylem> 3b/ No. I don't see shipped-but-disabled-by-default as any better than curl -O http://some/place/foo.repo, really, so why would we make such a compromise?
18:26:57 <mitr> 3b. This is the authority of Board, not FESCo, to decide.  Within FESCo, if elected, I will always leave this to the Board)   I don't see it as forbidden/incompatible in the first place; giving users useful Free Software and educating them about Free Software is IMHO more important than pretending that non-Free sotware doesn't exist.
18:27:16 <nirik> ok, moving on to 4 then?
18:27:23 <nirik> #topic question 4
18:27:26 <nirik> 4. From williamjmorenor: What do you think about fedora.next? do you think rolling releases or longer support are possible?" is that what you were meaning?
18:27:38 * nirik fails cut and paste. sorry
18:29:11 <kylem> 4/ I'm hugely in favour of beginning to define more criteria around what makes up a Fedora release. I think it's a good first step towards rolling releases, since it ensures we all know what we have to satisfy and keep working. It'll be very interesting to see how it plays out, and balancing the (possibly conflicting) viewpoints is something I hope to be able to do while on FESCo.
18:30:42 <mitr> 4. I'm afraid we'll _really_ know what Fedora.next does only after the first release is shipped.  I do hope to get increased focus on the products, and integrating them well, as opposed to just hoping that upstreams will produce individual components that happen to together make an usable product.  Rolling releases haven't AFAIK been considered within Fedora.next; longer support has been discussed but so far there isn't a consensus in tha
18:30:44 <mitr> t direction.  Longer support might be possible _if_ we restrict the number of simultaneously supported releases, so that the overall burden on maintainers isn't increased; and with longer support / time between releases, there would be a larger need for compatibility stacks (both for backward and forward compatibility).
18:31:33 <mitr> 4cont.  (Such a longer support has been discussed in the Server WG, but again so far we are all operating with the assumption of keeping all products on the same, more or less unchanged, schedule.)
18:33:04 <kylem> 4-cont/ One of the problems we have presently is getting karma for updates to older releases. It remains to be seen how we can play that with longer term support. Possibly if we committed to things for longer, people would be more likely to stay on older releases. But I think we might want to stagger it so only security fixes or other targetted backports went into those for people not comfortable upgrading immediately.
18:34:20 <kylem> 4-cont2/ Additionally, it's less likely that users on older releases will be active members of the community, since, I'd back-of-napkin it to say probably 80% of our contributors are on the latest-stable releases, running updates and updates-testing.
18:35:08 <abadger1999> \4 I think fedora.next is essential for giving value to our sponsor.  There are different parts to the fedora.next proposal that I like for different reasons but I think they come with some high costs as well -- it remains to be seen whether we can pay those costs or not.  The multiple Products give us the ability to address the different things that contributors want to produce in a more sensible way.  But it has a high cost in terms of
18:35:10 <abadger1999> needing to build and promote different Products.  And in the question of how much we can share current resources vs have new ones (like whether we can continue to have a single yum repo or will need to have new ones with conflicting packages).
18:35:16 <abadger1999> 4/ The proposal for rings and stacks seems like it may not bear fruit in time for F22 but it is the area of the fedora.next proposals that I think has more potential to address your question of rolling releases.  We can start dividing up the package set and some parts will operate on some rules (like updates policy) that do not apply to others.  This will have a heavy burden in terms of coordination and will very likely need to have new
18:35:18 <abadger1999> infrastructure to support it (new repositories, new build targets, and a whole lot more).
18:36:28 <nirik> ok, on to question 5.
18:36:33 <nirik> #topic question 5
18:36:35 <nirik> 5. from inode0: Do you see any persuasive technical reasons to either include or exclude spins from being treated in manner similar to now in the future? Or is this just a branding/marketing question in your mind?
18:38:46 <kylem> 5/ Not having thought a lot about this, as I'm not a consumer of spins... So maybe I'm putting my foot in my mouth, but I don't particularly see why it would be unreasonable to expect them to form their own working groups. I haven't really thought about it enough to say anything conclusively though.
18:40:01 <abadger1999> 5/ I think that resources (I mostly mean manpower when I talk about resources) may become scarce as we start to try to do more things to enable fedora.next.  So I'm not sure that we're going to be able to continue to create spins alongside the products and the other changes.  I think I'd like to see them either become part of a cohesive strategy that includes the Products as well or become something that aren't produced nad QA'd officially by
18:40:02 <abadger1999> the project but that we're happy to host.
18:40:39 <kylem> 5-cont/ I do think they bring a lot of value though, especially things like the design suite, in making it easy to novice users to try to accomplish specific tasks on a live image or whatnot.
18:41:07 <mitr> 5. I don't really see any branding issues.  What I do see suggested most is that the increased requirements on Fedora Infrastructure are a noticeable burden (although not a critical problem); I suppose that would be a technical reason, especially coupled with the fact that we don't know how rel-eng of F21 will look at all (multiple repos/composes?  Separate QA process?).  On balance, I'd much prefer for spins to stay within the Fedora uni
18:41:09 <mitr> verse, infrastructure and general ecosystem / group of people.  If you are doing something cool with Fedora, it's better if it happens _within_ Fedora so that Fedora can take your needs and your users into account.
18:42:29 <nirik> ok, question 6 (a bit more related to the non free software questions eariler)
18:42:30 <abadger1999> 5/ I think technically we could continue to produce them in the same manner as we do now alongside the products but only if there were enough new people who step up to work on accomplishing that... I don't think the present manpower will be able to do that and all the new things.
18:42:45 <nirik> #topic question 6
18:42:48 <nirik> 6. From robyduck: Aren't you worried to loose *core* contributors in change of ubuntu-like end-user, if we point to 3d party repos? It is already easy to install 3d party software, so what in your eyes is the main goal of the proposal to change the foundations?
18:44:24 <kylem> 6/ As answered previously, I'm against pointing to 3rd party repos by default. I think it could lessen the perceived quality of Fedora too, if, say, fairly core libraries need to be updated in the 3rd party repo, and end up breaking things from Fedora updates.
18:46:38 <abadger1999> 6/ yes.  I would be concerned about that and the argument that the new users who we might gain aren't as likely to be committed contributors as those we might lose does sound logical to me.  OTOH, I do know that one of the first things I personally do after installing fedora is to enable the flash repository so if the contributor base was actually accepting of the idea of pointing to non-free software I owuldn't be opposed.  Luckily, I'm not
18:46:39 <abadger1999> on the Board so I don't have to examine closely the correctness of those gut instincts.
18:48:03 <mitr> 6. (This is the authority of Board, not FESCo, to decide.  Within FESCo, if elected, I will always leave this to the Board.)  Yes, loosing core contributors is an important worry; we need the foundations to reflect the community _as it is_ (which is, AFAICT, very passionate about FOSS), not _as it would just now be convenient to be_.  I don't think "Ubuntu-like end user" is the change in question; non-Free software is just as wanted by va
18:48:05 <mitr> rious technically knowledgeable users.  I somewhat disagree that "it's already easy to install 3rd party software" - yes, it is quite easy by standards of 10-5 years ago, but it's noticeably more difficult than the current state of the art (Windows, Android, iOS, _everything_ has an integrated app store/installation mechanism)
18:48:49 <mitr> 6cont.  So I don't see any other main goal than to just make software installation easy.
18:49:36 <nirik> ok, 7 (this is the last question I have queued currently, so perhaps after this we do a short open floor and close out the hour)
18:49:40 <nirik> #topic question 7
18:49:43 <nirik> 7. from mayorga: Should QA process be as rigorous for user-space packages as it is for kernel-space ones?
18:51:58 <abadger1999> 7/ I would think that user-space vs kernel-space wouldn't be a great place to make a division in QA but I'm not on the QA team so I largely defer to what they say when they make proposals.
18:52:01 <kylem> 7/ I don't understand the question, truly. For all updates, regardless of kernel or userspace, we require testers to provide karma. That said, the kernel is a much bigger piece of software than any random userspace package, and can fail in novel and unexpected ways, despite rigorous testing.
18:52:30 <mitr> 7. I don't know that kernel goes through an exceptionally rigoorus QA process _within Fedora_.  The kernel does go through a lot of testing upstream, and has a culture of being extremely careful about not introducing code breaking changes.  I do think many user-space upstreams would benefit their users by adopting similar policies - but there really are areas where we need much more experimentation and freedom to change the design, it's n
18:52:32 <mitr> ot an one-size-fits-all matter.
18:53:09 <kylem> 7-cont/ Justin has been doing some excellent work to first-pass filter failing kernels though, which is should provide some comfort. But again, something that sits close to the hardware requires myriads of combinations to be tested to feel confident in it.
18:53:22 <abadger1999> 7/ I would see a more appropriate place to make a division between critpath packages (or a new definition of what is critical to the basic system) and other packages.  Or between things we think a large number of people are using vs things that are very niche.
18:55:10 <nirik> ok, would everyone like to sum up or just mention anything else you would like to that voters might be interested in your take on...
18:55:19 <nirik> #topic final thoughts
18:56:37 <kylem> Thanks Kevin for moderating this. I think every candidate has a lot to offer FESCo. I think as parting words, I'd just encourage people to speak up and get involved in what you believe in, which is probably pretty good advice in general. :)
18:56:49 <mitr> Thanks for the questions and hearing me out.  (And if you thing I'm wrong about something, please tell me.)
18:57:43 <kylem> Thanks also to all the other candidates, sadly not everyone could be here because of their involvement in community events. I think they'd appreciate an opportunity to post their thoughts on the above questions, so hopefully we could put their answers on the wiki or whatnot.
18:58:02 <kylem> and thanks to those who were here to listen. :)
18:58:37 <nirik> thanks everyone!
18:58:47 <nirik> Please do remember to vote.
18:58:55 <abadger1999> Thanks, nirik, for moderating and others for the questions.  I'm sorry that the question that came up most is something I want to punt ot the Board but it just seems like the heart of it is an overall Project strategy, not technical.
18:59:37 <nirik> #endmeeting