16:00:48 <siXy> #startmeeting FESCo-Town-Hall-2010-05-14
16:00:48 <zodbot> Meeting started Fri May 14 16:00:48 2010 UTC.  The chair is siXy. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:19 <siXy> uhh.  that should have done something.
16:02:50 <zodbot> siXy: Error: Can't start another meeting, one is in progress.
16:02:59 <siXy> #meetingname FESCo-Town-Hall-2010-05-14
16:02:59 <zodbot> The meeting name has been set to 'fesco-town-hall-2010-05-14'
16:03:12 <siXy> ok sorry about htat everyone, this should work now.
16:03:18 <siXy> Welcome to the first townhall meeting for FESCo candidates
16:03:50 <siXy> most people are here now, it seems
16:04:18 <siXy> I'd like to point everyone to http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations and also ask each candidate to make a short introduction of themselves
16:04:35 <siXy> As always folks are free to ask questions over in #fedora-townhall-public and I will queue them up and ask them
16:04:52 <siXy> who wants to go first?
16:05:05 <notting> hi, my name is Bill Nottingham, and I'm a fedoraholic.
16:05:33 <notting> i'm an engineer at Red Hat, and I've been active in Fedora since ... before it started, probably.
16:06:14 <mclasen> i'm Matthias Clasen. i work in the desktop team at Red Hat
16:06:23 <mclasen> I've been invovled with Fedora since 2004
16:06:37 <jforbes> My name is Justin Forbes, I am an engineer at Red Hat, and work on virtualization and cloud sig among other things
16:06:37 <mclasen> and I'm doing a lot of the gnome updates
16:06:57 <jforbes> I have been started with Fedora porting FC1 to x86_64
16:07:10 <SMParrish> I'm Steven Parrish, member of the KDE-SiG and maintainer of Fedora for the OLPC
16:08:06 <kylem> I'm Kyle, I've been working in the Fedora team at Red Hat for the last 3 years-- I work on the kernel in Fedora and upstream and a few other things.
16:08:31 <brunowolff> I'm Bruno Wolff. I have an interest in free software and games. I work with the Spins SIG, package some game related stuff and have
16:08:56 <brunowolff> been participating in Fedora Engineering Services.
16:10:08 <siXy> ok, unfortunately we still seem to miss nirik, however I'm just going to go ahead with the first question and he can catch up later
16:10:26 <siXy> 1. DiscordianUK> Why should we choose you out of all the other candidates?
16:12:08 <notting> well, there are lots of good candidates. you don't have to choose just me.
16:12:35 <notting> but i'd like to think that i've had a good record of judgement in my time on fesco, and have generally been able to make the right choices for fedora
16:12:40 <brunowolff> I think there are other candidates who you should rank higher than me, but I think I worked enough on the technical side of
16:12:57 <brunowolff> Fedora that I will make reasonable decisions on FESCO.
16:13:18 <siXy> as an update/clarification, mathstuf adds: what distinguishes you as a candidate for FESCo?
16:13:36 <mclasen> I hope that I have proven some judgement and ability in my past contributions to Fedora. That might convince you to give me one of your votes.
16:13:43 <jforbes> I can honestly say we have a good group of candidates here...  I can say that I generally make sound decisions, and have Fedora's best interests in mind
16:13:44 <brunowolff> I also can accept a concensus decision once one is reached and worked toward the agreed upon goal and not reopen things that
16:13:51 <brunowolff> have been agreed to repeatedly.
16:13:59 <kylem> I think I bring a unique perspective to FESCo, having been a Debian developer in a previous
16:14:02 <kylem> life and working for Canonical on Ubuntu in a previous job. I think this broad range of
16:14:05 <kylem> experience gives me a solid foundation to critically assess issues presented to FESCo by the
16:14:08 <kylem> community.
16:14:25 <SMParrish> There are lots of good candidates, and you dont have to chose just one.  I am a volunteer who wants to help steer Fedora along and to improve our processes and methodologies in a way that will  benefit Fedora as a whole
16:14:49 <mclasen> one thing that might differentiate me is that I'm an active GNOME developer and can bring some of that perspective to the table.
16:14:53 <brunowolff> Unfortunately I don't make as good as a liason as some of the other candidates who are on other key teams.
16:15:25 <siXy> ok, thankyou.
16:15:28 <siXy> 2 inode0> what is the most troubling issue you see facing FESCo currently and what do you think needs to be done to fix it?
16:16:32 <brunowolff> I think we need to come to an agreement as a project on what our policy is for when and what kinds of updates packagers should be making.
16:16:45 <notting> fesco specifically, not fedora in general?
16:16:59 <brunowolff> In the end the Board may be involved in that, but I think FESCO will be making a recommendation.
16:17:14 <mclasen> I think we need to be a bit more courageous in setting directions and making sure that there is one thing that we all build together
16:17:25 <mclasen> instead of everybody building his own little thing
16:17:44 <SMParrish> IMO the updates policy is the most pressing need.  We need a policy that will insure stability in our releases with creating hoops for the maintainers to jump through.
16:17:57 <notting> 'with'?
16:18:00 <mclasen> with or without ?
16:18:06 <kylem> I think the most troubling issue I've observed recently is there seems to be a schism in the
16:18:09 <SMParrish> without   lol
16:18:09 <kylem> community that seems to be very distrustful of FESCo. I believe this stems from the lack of
16:18:12 <kylem> a coherent vision for Fedora, and working on producing one, while it might not make everyone
16:18:16 <kylem> happy, will at least give us a better definition of what we're attempting to achieve.
16:19:07 <jforbes> I think the biggest issue is balancing the needs of the distribution with packagers needs... We can't just piss everyone off, and we have to have some faith in our packagers, but we also have a responsiblity to our users
16:19:40 <siXy> 3. jreznik> how do you want to solve (technical) conflicts between various groups in Fedora - for example if one person wants to remove something others depend upon?
16:19:44 <notting> i think that a troubling issue in fesco is the acrimony that has come to recent meetings and discussions. but that's more symptomatic of fedora as a whole. i'd agree that having some sort coherency in goals that we're working for can and would help with that. if we're all talking past each other with what we want, it's not really surprising that conflicts occur
16:20:38 <brunowolff> I think that is going to be very dependent on the specific circumstances.
16:20:52 <mclasen> I think technical issues almost always have a technical solution, so I would see my role in such a conflict mostly as bringing the parties together to work that out.
16:21:33 <notting> jreznik: i think you need to move in both ways. people should be careful to not remove things others are depending on without warning, but people who depend on deprecated solutions must also be willing to take up maintenance of those solutions when others have moved on
16:21:51 <SMParrish> Their has been alot of conflict in many of the recent meetings.  We need to have more civil discussions and be willing to listen to everyones point of view before jumping to a decision.
16:22:47 <SMParrish> Everyone needs to realize that Fedora is more than just Gnome and what the desktop group does effects more than just themselves
16:23:19 <kylem> I agree with mclasen, you can't solve a political problem with a technical solution, nor can you
16:23:22 <kylem> do the reverse. We need to be willing to make compromises, as notting points out, and work
16:23:25 <kylem> together for the betterment of Fedora as a whole, not just our little packaging niches. This
16:23:28 <kylem> ties back to our target audience. Do we make this OS just for ourselves, or out of a broader
16:23:31 <kylem> act of community?
16:23:56 <jforbes> I think that has to be resolved on a case by case basis.  You can't remove something that others depend on without at least giving another option and time to adapt
16:24:27 <notting> jforbes: right. but at some point, i'd like to not have consolehelper in the default install
16:24:34 * jforbes thinks we should prepend our answers with the question number so that this is easier to decipher
16:24:53 <jforbes> notting: of course, time to adapt is not infinite
16:25:08 <siXy> ok, thankyou for your answers - I think it's time for the next question:
16:25:16 <siXy> 4. NthDegree> What are the plans regarding security policies for packaging with Fedora?  (i.e. if a potential compromise of RH/Fedora servers were to occur again)
16:26:19 <jforbes> Well, I would prefer to be proactive and prevent it from happening than reactive and doing damage control
16:26:21 <brunowolff> If it were up to me I would be a lot more open. But I don't think that as a non Redhat person, I'll be in a position to know stuff
16:26:40 <brunowolff> that the community as a whole doesn't with regard to a security incident.
16:27:21 <SMParrish> I don't believe we should advertise what our security plans and responses are.  That would just give the hackers a guide on how to get around what we have in place.  I do believe once there is an incident it needs to be reported to the community and the community be kept in the loop
16:27:48 <notting> 4) i'm not sure what the questioner means by 'security policies for packaging'. the infrastructure group has a security response plan - is that what you mean?
16:27:53 <brunowolff> Other than the secrecy things seemed to be done reasonably. You need to make very sure that the packages being distributed
16:28:16 <brunowolff> haven't been compromised. Depending on the event that may or may not be easy to determine.
16:28:18 <notting> to be honest, security policy for the project itself w.r.t compromises is more of a board thing anyway
16:28:47 <mclasen> yeah, the response to incidents like the mentioned one lies mostly with IS/ rel-eng, I would think. And questions wrt to openness of response lie mostly with the board.
16:28:53 <kylem> 4. I don't understand the question, so I'll reinterpret it slightly. I think that more
16:28:56 <kylem> oversight is necessary, and that the major concern is likely that a proverpackager gets
16:28:59 <kylem> compromised and there is a problematic commit made and nobody notices from the commits mail
16:29:02 <kylem> emitted. That said, I was a little dismayed at the level of disclosure, and it would
16:29:05 <kylem> certainly be nice if Fedora's infrastructure was further separated so that decisions could be
16:29:08 <kylem> made differently from Red Hat's. I understand this may not be easy to do, so some compromise
16:29:11 <kylem> is necessary.
16:29:13 <siXy> in clarification: NthDegree> I'm referring to how a compromise where packages may be altered would be handled
16:29:51 <mclasen> if the question is about packaging, we do have a security guideline now, and I think that FESCo will make sure to keep that document uptodate and relevant, but that is more concerned with security of the system where the packages are installed, not where they are built
16:29:55 <notting> when the last incident occured, we took the package repo offline, did a comparison of cvs and the lookaside against pristine upstream sources, and i do believe made a comparsion of built packages against CVS content
16:30:10 <brunowolff> The compromised packages would need to get security updates and I'm sure the event would get plenty of coverage on linux
16:30:45 <brunowolff> news sites to let people know to do updates and check for problems with their systems if they had a bad version installed.
16:31:16 <siXy> ok, I think we can move to the next question now.
16:31:24 <siXy> 5. jreznik/NthDegree> What is your position on features that aren't quite ready, or significant feature changes just before a freeze?  How do you handle removal of features? (for example: Xen was removed quite abruptly)
16:32:00 <brunowolff> Significant feature changes right before a freeze are bad. This cause problems for other project members who can be affected
16:32:21 <brunowolff> by these and not have a lot of time available immediately to deal with unexpected changes.
16:32:32 <jforbes> Heh, xen was a bit of a special case, it was a massive drain on resources because upstream never moved to a more recent kernel.  That was a 100k line patch to keep forward porting, and frankly it was just impossible to keep up
16:32:49 <notting> i'm not sure Xen was removed right before a freeze, was it? it was abrupt in that it was yanked from one major release to the next.
16:33:21 <jforbes> The decision on xen was published pretty early
16:33:22 <notting> to be fair, fesco as a rule hasn't  *reverted* many, if any, feature. although we've removed them from the advertised list
16:33:26 <mclasen> We have had our share of not-quite complete features, and in some cases it may have been better to hold them back for a release. In general, I think that our qa efforts will help us make that decision better, in the future. I fully agree on late, big changes. That is a bad habit.
16:33:27 <kylem> 5. I don't think Xen should have been added in the first place, for the same reasons we don't
16:33:31 <kylem> allow kmods in Fedora proper. I think a lot of the discussion comes down to needing a very
16:33:34 <kylem> hard line policy on what "freeze" means. I think we need to rethink our release cycle a bit and
16:33:35 <SMParrish> Features that are not ready should be defered until the next release.  As far as removal of an existing feature, we should be giving people as much advance notice as possible.  There should also be open discussion as to why its being removed and what can be used in its place
16:33:38 <kylem> spend more time polishing.
16:33:59 <kylem> (Addition: No-Frozen-Rawhide means this is much nicer to do.)
16:34:51 <siXy> ok, thanks everyone, let's keep moving
16:34:54 <siXy> 6. mether> As a independent contributor, what do you perceive as the positive/negative things from having Red Hat as a sponsor?
16:34:54 <jforbes> For general features, adding just before the feature freeze is not uncommon, that's unfortunately the nature of deadlines.
16:35:32 <mclasen> do RH employees get to answer that ?
16:35:42 <brunowolff> They sponsor a lot of important things in Fedora and give us a pretty free hand.
16:36:24 <brunowolff> Really the only problem I've had with them is that the description of the security event was held back much longer than appeared
16:36:53 <brunowolff> necessary. The public report much later didn't seem to have anything in it that warranted keeping it secret that long.
16:37:20 <SMParrish> I think RH does a good job of playing hands off with Fedora.  They do hold the purse strings though and I'm not sure if thats a good thing or not.
16:37:37 <siXy> the questioner has sadly just timed out.  RH people: feel free to answer or not as you want.
16:38:00 <brunowolff> They seem to go out of their way to make Fedora forkable. I love this and earns a lot of trust from me.
16:38:07 <kylem> 6. I'm biased since I work for Red Hat, and am given pretty free reign to work (I think at
16:38:11 <kylem> least :) Comparing with, say, Debian, which relies on a number of sponsors for infrastructure
16:38:14 <kylem> and hosting, I think Fedora benefits from having a single point of contact. As a downside,
16:38:18 <kylem> I think Fedora is probably overly centralized as a result, but I could be wrong, and I'd be
16:38:21 <kylem> happy to be corrected.
16:38:24 <jforbes> I have been both an independant contributer and am now a RH employee.  I can't really see a whole lot of negative to the RH sponsorship of Fedora, other than perhaps some resources are not as separated from RH resources, allowing Fedora to do things a bit differently.  As for positives, there is a great amount of effort and resources that RH does allocate to Fedora.  And they still understand the importance of the community here, adn don't rule i
16:38:30 <SMParrish> My biggest complaint is that RH is a Gnome shop and that the other desktops KDE, XFCE etc feel like second class citizens and I would like to see that change
16:39:35 <mclasen> it is hard to see how fedora would maintain the intrastructure it has without Red Hat's backing. On the flip side, we sometimes tied to infrastructure that may not be ideal, such as RH bugzilla
16:39:48 <brunowolff> Unfortunately I agree with Steve and I think it is important to have someone representing one of the nongnome desktops on both
16:40:02 <brunowolff> FESCO and the Board.
16:40:37 <notting> there has always been someone representing non-gnome desktops on FESCO, afaict.
16:40:43 <notting> (at least, a maintainer of one)
16:41:11 <siXy> ok, thankyou everyone.  We have a new question:
16:41:13 <jforbes> I don't think anyone is specifically anti KDE or XFCE, just a matter of available resources and people
16:41:24 <siXy> 7. NthDegree> How do you plan to proceed with XACE and/or PolicyKit integration on the desktop?
16:41:47 <brunowolff> I think it's more not always thinking about how things might affect the other desktops.
16:42:02 <siXy> NthDegree adds, by way of explanation: it's a big differentiator between Fedora and every other distro, so i'd love to know what the plans are
16:42:23 <kylem> 7. I don't feel qualified to answer the question without further research, but if there's a
16:42:27 <kylem> specific problem that just requires code, I'd be happy to pitch in to make things happen.
16:43:06 <brunowolff> I haven't looked at that recently, but I think the direction they are going sounds good. Their goal of not having people
16:43:11 <notting> i think policykit is already fairly well integrated into GNOME, and is being integrated into KDE as they work on it. don't know that we're planning on having XACE desktop policy any time soon for general use; i'd defer to dwalsh on that
16:43:41 <mclasen> PolicyKit integration is well underway, and is proceeding on its own, without FESCo involvement, I'd say. I am not so sure if XACE has a large relevance to the Fedora user base, frankly, since it is mostly about MLS and labelling documents, etc. Dan Walsh has been doing interesting things with SELinux on the desktop though, eg. his kiosk spin
16:43:42 <brunowolff> constantly enter passwords as good. The glitch that got a lot of discussion had to do with the project being in an inbetween
16:43:46 <jforbes> 7. I think the most important thing is for FESCo to not hinder the progress being made there.
16:44:08 <brunowolff> state. I think changing the default access was the right thing at that time.
16:44:20 <SMParrish> I'm not up to speed in XACE, but as far as PolicyKit goes I feel it is a good thing.  Its already integrated in Gnome and is coming along for KDE.
16:44:41 <notting> until someone tells me otherwise, i will assume that XACE remains at the state of 'you turn it on and everything breaks'
16:44:44 <mclasen> and I still hope to work with dwalsh on a generally useful guest user for Fedora desktops (that might or might not involve selinux, but probably not XACE)
16:45:05 <brunowolff> That's one of the areas where all of the desktop teams should be engaged early.
16:46:40 <brunowolff> mls is hard to do. I played with just mcs and found that things don't work well at all.
16:47:07 <brunowolff> The labelling isn't sane.
16:48:34 <brunowolff> I think it will need application support for mcs to be at all useful.
16:48:41 <siXy> I'm afraid we are running a bit dry on questions, so I will ask one.  How important do you believe it is to accommodate users on low bandwidth connections, and how agressive should we be in reducing the size of updates, both generally and 0-day?
16:49:00 <notting> i think those questions are unrelated
16:49:11 <notting> reducing the number/size of updates helps everyone
16:49:19 <brunowolff> I think with the worldwide reach that seems to be Fedora's target, we need to have some reasonable support for people
16:49:32 <brunowolff> with lowbandwidth connections.
16:49:33 <mclasen> I think we should be agressive in reducing the size of the updates. while it makes fedora impossible to use over low bandwidth, it makes it miserable to use everywhere
16:49:58 <mclasen> and reducing the volume helps with increasing the quality
16:50:17 <jforbes> I would agree with notting there, I have plenty of bandwidth, and cannot say that I enjoy he massive amount of updates either, even installing from a local mirror
16:50:26 <mclasen> specifically for 0day, I think we can tweak our new branched processes to reduce the size
16:50:33 <notting> i don't want to specifically exclude people with lower bandwidth. however there's eventually going to be a firefox security update, and it's not going to be small
16:50:38 <mclasen> simply by reminding people to get their updates out of testing before we go in the rc phase
16:51:07 <notting> so ideas like deltas can help in that case for lower-bandwidth users
16:51:28 <mclasen> I was surprised myself by a few old-update mails from bodhi after we already entered rc this cycle...
16:52:15 <SMParrish> Having a clear updates policy will help with the quality of the updates but I fear we will always have a large number of updates during a release cycle.    Delta RPMs help with the download size but I'm not sure what else we can do to get the bits to the masses
16:53:33 <jforbes> Part of the issue is the sheer number of packages.  F13 seems to promote a smaller default install, which will hopefully help in that regard.  Smaller spins can also be of help for those with less bandwidth
16:53:37 <kylem> 8. I think with No-Frozen-Rawhide, the pressure to keep things always updated boils down to
16:53:40 <brunowolff> Outside of FESCO, their might be things ambassadors can do to help. But delta rpms help. Though addressing the current
16:53:40 <kylem> whether the maintainer is capable of fixing issues in the code, or if uploading a new major
16:53:44 <kylem> version is the only way they can update a package. I think a clear update policy is necessary
16:53:47 <kylem> to both avoid the churn, and ensure releases focus on bug fixes and security. The next release
16:53:50 <kylem> is only ever six months away, which means things do not need to be maintained for an undue amount
16:53:53 <kylem> of time
16:53:54 <brunowolff> size limitaion is something that should also be done.
16:55:58 <siXy> 9. tcpip4000> Can you think of any way to show each fedora package in an easy way to create the rpm from sources and patches (eg: http://packages.ubuntu.com/, http://www.debian.org/distrib/packages)?
16:56:58 <notting> that looks like it could be done as more interfaces to pkgdb? or fedora-community.
16:57:01 <kylem> Can you clarify? Some type of post-processing could certainly be done on the CVS tree to generate a web page similar to that if it was of value, I suppose?
16:57:05 <mclasen> our packagedb has gotten a very nice facelift recently, which brings us a lot closer to those examples, together with the fedora-community website
16:57:57 <brunowolff> It might be worth righting this up. It isn't that hard to rebuild from srpms as the source, patches and instructions for
16:58:01 <notting> yes. although i think we need to find a way to get people more active with the new pkgdb
16:58:08 <brunowolff> building are all in the src rpm.
16:58:22 <SMParrish> I agree with the previous comments, pkgdb and Fedora Community are good resources for that type of info.
16:58:29 <notting> if the most discussed apps are reivsor, galeon, and terminator... we're not getting a lot of uptake (no insult meant to those apps)
16:59:45 <mclasen> I agree with notting that we need to take the next step and make  pkgdb and fedora-community the first point of contact for somebody who wants to explore the fedora package universe
17:01:13 <notting> someone really smart should be able to hack up something that uses a users existing fedora account, their app launch data from the shell, and gives users an option to comment on the apps they use, etc.
17:01:48 <siXy> ok, we are out of time now.  Does anyone have anything they would like to add in closing?
17:02:12 <kylem> Thanks for listening.
17:02:32 <notting> thanks for coming. thanks to siXy for moderating, and inode0 for organizing.
17:02:42 <jforbes> Thanks everyone
17:02:53 <SMParrish> Thanks everyone for coming
17:03:15 <brunowolff> For the listeners: You do need to be on a special committee in Fedora to lead or make things happen.
17:03:21 <mclasen> yeah, thanks
17:03:27 <mclasen> do not, you mean !
17:03:29 <brunowolff> not need!
17:03:44 <siXy> I'd like to thank the candidates and questioners for their time.
17:03:52 <siXy> #endmeeting