17:02:09 <mdomsch> #startmeeting FESCO Town Hall
17:02:09 <zodbot> Meeting started Wed May 30 17:02:09 2012 UTC.  The chair is mdomsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:22 <zodbot> mdomsch: Error: Can't start another meeting, one is in progress.
17:02:30 <mdomsch> Welcome to the Fedora 18 election cycle.  Today we have eight excellent candidates vying for the five seats open on the Fedora Engineering Steering Committee (FESCo).
17:02:31 <nirik> it started, just didn't change the topic yet. it will on next topic change.
17:02:50 <mdomsch> http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations has candidate descriptions and answers to the questionnaire posed to them.
17:02:59 <mdomsch> We would like to thank the candidates for their time today, and their willingness to serve the Fedora community as a member of FESCo.
17:03:04 <mdomsch> Your candidates are:
17:03:11 <mdomsch> Peter Jones (pjones)
17:03:11 <mdomsch> Stephen Gallagher (sgallagh)
17:03:11 <mdomsch> John Dulaney (j_dulaney)
17:03:11 <mdomsch> Kevin Fenzi (nirik)
17:03:11 <mdomsch> Keiran Smith (Affix)
17:03:12 <mdomsch> Tom� Mr�z (t8m)
17:03:13 <mdomsch> Bill Nottingham (notting)
17:03:15 <mdomsch> Josh Boyer (jwb)
17:03:25 <mdomsch> I'm your moderator, Matt Domsch.  I will take your questions in the #fedora-townhall-public channel, and pose them to the candidates.  Candidates are welcome to pose questions in the -public channel as well.
17:03:38 <mdomsch> The candidates would appreciate your questions being able to help differentiate one from the other.
17:04:26 <mdomsch> I see seven of eight candidates here (John Dulaney currently absent)
17:05:16 <pjones> I say your three cent titanium tax doesn't go too far enough.
17:05:35 <mdomsch> I'll go ahead and start with some questions, while people gather their thoughts and submit their own in #fedora-townhall-public
17:05:36 * j_dulaney apologizes
17:05:41 <mdomsch> welcome j_dulaney.  All present now.
17:06:11 <mdomsch> I'll post the question, and give each a chance to answer in order.
17:06:13 <mdomsch> It seems the majority of FESCo meeting time is spent on the Feature Process, reviewing and approving (in most cases) features for the next Fedora release.  Is that process working?  How would you improve it as a FESCO member? http://fedoraproject.org/wiki/Features/Policy
17:06:47 <mdomsch> pjones?
17:07:03 <pjones> It's not that the process is or isn't working - it's that the goals of the process are unclear (or worse).
17:07:41 <pjones> There are features that are real and simply never submitted, and there are features that are submitted but basically have no reason to be.
17:08:31 <pjones> I think we need to rethink the entire thing from the start, but that's more of a question for the board than for fesco - approving or disapproving is our role as it currently stands.
17:09:10 <mdomsch> sgallagh ?
17:09:30 <sgallagh> My experience has been that Features tend to fall into two categories
17:10:03 <sgallagh> 1) Things that are complete upstream and (usually) already incorporated into Fedora and are looking for a rubber-stamp. These Features are mostly being proposed so they get attention in the release notes
17:10:24 <sgallagh> 2) Things that are incomplete upstream and are disruptive (positively or negatively) to the development of Fedora
17:10:52 <sgallagh> For 1), I think we should really reconsider requiring Feature Pages and instead have a voluntary release-notes/shout-out process
17:11:20 <sgallagh> For 2), I think this is exactly why the Feature Process should exist, and I think that on the whole FESCo is doing a good job of managing it.
17:11:33 <mdomsch> thanks sgallagh
17:11:33 <sgallagh> EOF
17:11:47 <mdomsch> I have 2 follow-up questions each can consider in your answers
17:11:58 <mdomsch> a) What improvements or streamlining of current processes or procedures do you believe you can affect change in this role?
17:12:06 <mdomsch> b) If you could change one things about the current Feature Process, what would it be?
17:12:37 <mdomsch> pjones or sgallagh would you care to elaborate for these?
17:12:42 <mdomsch> if not, we can move on
17:13:05 <sgallagh> I think I basically answered b) with my comments about the release notes
17:13:24 <mdomsch> j_dulaney, you're up
17:13:26 <sgallagh> Which I suppose also answered a), more or less
17:13:38 <j_dulaney> mdomsch:  rgr
17:13:49 <pjones> Well, as I already stated, I think we need to rethink it from scratch.  Asking people to bring things to our attention isn't a very good plan for any chances we don't really want, and rubber stamping things that are done isn't very good either.
17:15:30 <mdomsch> we can speed this up a bit by letting candidates post in parallel
17:15:44 <mdomsch> so, let's do that.
17:15:58 <j_dulaney> rgr
17:15:58 <mdomsch> each candidate, post when you're ready
17:16:07 <t8m> The process is not optimal and there was a general agreement to change it during my previous term. Unfortunately no concrete proposal for changes came up. I'd certainly like to at least have the features split to two groups - intrusive and non-intrusive (mostly needing just advertisement in release notes) ones. It seems that the first group should be watched more carefully and the second group should be approved automatically unless someone explicitly st
17:16:07 <t8m> eps up and has some objections to such feature.
17:17:08 <j_dulaney> For some things, the process works well.  If, for instance, a proposed 'feature' receives nothing positive from the community, then it has been my experience that FESCo has voted against it
17:17:59 <jwb> i mostly agree with pjones, except i don't think we need to go to the Board to redefine the process
17:17:59 <j_dulaney> However, as many things get dumped into Fedora anyway through non-feature processes, it is still possible to get things in that would be unpopular
17:18:10 <notting> Is the process working? More or less, for what it was designed (especially for creating PR notes). It suffers from some tooling issues - the need to boil things down to a percentage, and the fact that status updates often fall to just "FESCo starts pinging maintainers out of band". Some of that can be fixed with better tools, which adds a barrier to entry (although I don't think that's an issue we have now.) (con't)
17:18:15 <j_dulaney> So, yes, the process could use some work
17:18:25 <pjones> jwb: my understanding (and I could be wrong) is that the board agreed on this process?
17:18:42 <nirik> The features process needs a revamp. There are some folks who were going to try and work on that, and I support them in that need. We are using features for a variety of differing things and we should seperate those all out. For example, coordination between maintainers, or version upgrades or something thats completely new/radically changed. See http://fedoraproject.org/wiki/Fixing_features and add to it! :)
17:18:49 <jwb> pjones, sure.  but we can redefine it ourselves to something that makes sense and present it to them as a proposal
17:18:57 <pjones> well, sure.
17:19:12 <jwb> pjones, basically, i'm saying if we wait on the board it'll take to long
17:19:48 <mdomsch> affix: ?
17:20:11 <notting> Where FESCo adds the most value is for those features that have integration concern between multiple groups/packages. There's room for improvement to be had there, but there aren't any quick fixes to that other than maybe getting the non-controversial ones out of the way to avoid feature review fatigue. but there's the chance we'll miss things if we fast-track things we think are non-controversial.
17:20:12 <pjones> jwb: that's certainly /already/ the case, yes.
17:20:32 <jwb> ok, true
17:20:37 <mdomsch> question 2 - related - Fedora has never had a defined role of �Architect� � a person who has responsibility for ensuring the cohesiveness of the product as a whole.  Does Fedora need such a role?
17:21:41 <sgallagh> 2) Well, giving a single person that role is pretty much a guarantee that this role would have a huge burnout-and-turnover rate (see FPL for a similar example). I think this is pretty much the intended purpose of FESCo to serve in this capacity as a group.
17:22:03 <nirik> 2: I don't think Fedora needs such a role off hand. The problem is that Fedora is a collection of things that builds other things (kde, gnome), so mediating things between groups is great, but trying to force groups to some 'master plan' isn't going to work to well. I think FESCo serves as that mediator.
17:22:13 <pjones> 2.  I think we sortof had that, though even then it was a shared responsibility, in the RHL days, and it's something we've lost along the way as we went to core+extras and integrated everything together as one Fedora. (cont)
17:22:36 <j_dulaney> 2 )I do not think so.  Fedora routinely puts out a superb product that works.  FESCo currently covers this role fairly well, getting differing groups within the project to work together fairly well
17:22:37 <notting> 2) Well, hey, if everyone (including all the volunteers) would just do what I told them, then things would be great! Is that what you want?
17:22:46 <jwb> 2) i don't think we need a single person filling that.  Fedora isn't a product, it's a project with a large and somewhat diverging community
17:23:05 <pjones> that being said, it's pretty difficult to establish that sort of position unless you're also expecting that person to do all the work - even as a fesco member I don't have the authority to delegate work.  So if I think something doesn't have fit-and-finish up to muster, who am I going to tell to fix it?
17:23:10 <jwb> 2) and i think a single person doing that role would become one of the most hated people in the project
17:23:12 <sgallagh> 2) (cont) I also think that trying too hard to stick to a single vision of the future would cost us our most valuable advantage: differing ideas.
17:23:25 <pjones> so fedora kindof does part of that - but it's mostly advisory out of necessity
17:23:49 <pjones> or rather fesco kindof does part of it
17:24:01 <mdomsch> question 3 - should be fesco more involved in release process, especially to review release blockers (or force people to fix the bugs) as we saw in f17 (the desktop one) - people were not sure if it's the right place to go, what to do etc.
17:24:40 <jwb> 3) i was under the impression that FESCo, or a delegate of it, attended the bug meetings, etc
17:24:41 <t8m> 2) I think that such "person" could be definitely positive improvement of Fedora, however I am not quite sure that in the current state of Fedora and Linux distributions in general there can be a single person who can take care of such role for the whole distribution. So maybe FESCo could do more as a multi-person body in this role - basically not focusing just on Feature process and resolving conflicts but also picking up topics on itself.
17:24:48 <j_dulaney> 3)  This is largely the role of QA.  If a bug is considered a release blocker by the QA team, then the release does not ship until it is fixed
17:24:52 <sgallagh> 3) I think we could perhaps do a better job of delegating our representative to the blocker bug meetings, but I think we're already pretty decently involved.
17:24:56 <jwb> 3) if that's not the case, that would be one step
17:25:04 <nirik> 3) I think QA does a great job with reviewing blockers (and everyone welcome). We aren't going to be able to force anyone to do anything, but we can help coordinate... and we did there.
17:25:21 <sgallagh> 3) (cont) As pjones mentioned above, FESCo doesn't have any power to command work be done. We're pretty much limited to saying "pull it out if it's broken".
17:25:23 <notting> 2) More seriously, I don't think we can drive the entire bus that way, but I'm on/run for FESCo precisely because I want to be involved in those sorts of issues...
17:25:27 <jwb> 3) as for _forcing_ people, that's impossible.  FESCo could find someone to fix it if the package maintainer can't for some reason, but we can't force anyone to do anything
17:25:40 <t8m> 3) I think that FESCo should be involved in the blocker review process if there is dispute between QE and developers - and that is what FESCo currently does
17:25:46 <pjones> 3) individual fesco members are actually already pretty closely involved in that process, though we could always be more so.  In f17 I've tried to make it to blocker and go/nogo meetings as much as possible to help represent the installer team, for example.  I think it's not so much "fesco should be involved" as that if you're a candidate for fesco, hopefully you've got some strong involvement already.
17:26:38 <mdomsch> question 4 - As to features, what direction do you envision F18 moving in?
17:26:44 <j_dulaney> 3)  Note that blocker bug meetings often last for hours at a time, sometimes taking up half a day.  The record that I'm aware of was seven hours
17:27:21 <jwb> 4) i have no idea.  that depends on the community.  clearly the usual round of updates to new releases, etc.
17:27:40 <notting> 3) FESCo makes sense as a mediation point between devel & QE, and I know that FESCo members attend and offer input (I have from time to time, but not much during F17 due to other commitments. At best, FESCo can influence packagers/engineers only, unless they're going truly rogue (we haven't had that problem.)
17:27:45 <nirik> 4) I'm looking for the new installer re-write to land... I'm looking forward to Xfce 4.10. ;) I'm looking forward to being surprised at the cool and amazing stuff people propose as features. ;)
17:27:46 <notting> 4) Forward, obviously!
17:27:49 <pjones> 4) as sgallagh mentioned, fedora's biggest strength is that the ideas and the direction come from individual contributors, and aren't dictated by fesco.  I don't foresee that changing :)
17:28:03 <j_dulaney> 4) I see a lot of cloud stuff coming down the line, maybe oVirt and possibly btrfs (finally), but otherwise it's whatever the community wants to do
17:28:10 <sgallagh> 4) I agree with pjones agreeing with me :)
17:28:11 <pjones> (but yes the installer UI rewrite should be pretty awesome :)
17:28:30 <t8m> 4) I'd very much like the features in F18 to focus on polishing and stabilizing the distribution as many parts of the system got pretty invasive and destabilizing changes recently so I hope the changes will be more evolutionary than revolutionary and then we can focus on revolutionary changes in future releases
17:28:40 <sgallagh> 4) I can talk about the Features that are already planned, but FESCo as a group doesn't propose them. We facilitate them.
17:29:03 <notting> 4) I strongly suspect Fedora's moving in a direction of a new, easier, less linear installer. But that's cheating. It depends on what the engineers want to do. For example, I could see an initiative to move to python3 in F19 or later, but that would depend on community uptake.
17:29:04 <mdomsch> question 5 - What do you believe that you bring to the table to help make F18 the best it can be?
17:29:11 <t8m> 4) cont. not that we can affect this very much
17:29:21 <pjones> j_dulaney: re: you're #3 answer - how do you foresee the QA team making decisions about blockers without input from the engineering leadership?
17:29:26 <sgallagh> 4) Along with some other Red Hatters, we expect to see advances in our interoperability with Microsoft systems in F18, both in Samba and SSSD.
17:30:06 <sgallagh> 5) A deep, abiding love for Fedora and its core principals
17:30:28 <nirik> 5) I like to think I'm easygoing and fair. :) I want to help out folks getting their things done...
17:30:40 <jwb> 5) i really enjoyed being on FESCo in the past, and then had to step away for quite a while.  i think my enthusiasm and the fact that i actually have time to do the role now will help keep things on point
17:30:43 <j_dulaney> pjones:  We take input from both FESCo and feature owners.  We often lean very heavily upon feature owners for test case writing, etc. and the Fedora engineering leadership can input into our blocker process at any time
17:30:49 <t8m> 5) I'd say my long experience with Fedora, RHEL and RHL as an user, admin, developer
17:30:56 <pjones> 5) a very large amount of experience making a prominent linux distribution :)
17:30:59 <sgallagh> 5) More specifically, I will help to get new features into the release *when they're ready* and will make Fedora better. Even when "better" doesn't match my own views :)
17:31:35 <pjones> j_dulaney: but you don't see having fesco people show up to the meetings as needing to be part of that?
17:31:47 <j_dulaney> 5)  I know how to break things :)  Seriously, though, I feel that a new voice on the steering committee would be very helpful
17:32:17 * nirik has attended almost all the blocker meetings, but sometimes I'm busy with other stuff and only watch for things that may need additional input.
17:32:18 <j_dulaney> pjones:  You're invited.  Actually, most of the release criterion are wrangled out on the mailing list
17:32:37 <notting> 5) Hopefully the same things I've been doing for a while... not much new here. Long-time experience with Fedora, Red Hat Linux, RHEL, etc. and a decent ethic to pull up sleeves and dig into things where necessary
17:33:09 <pjones> j_dulaney: I guess, to me, that sounds contrary to your answer to the question.
17:34:00 <j_dulaney> pjones;  I do not think so.  Are you stating that we ought to vet future release criteria through FESCo?
17:35:04 <pjones> j_dulaney: not at all - in fact I don't think I've said anything like that at all.  The question was about fesco reviewing blockers.
17:35:05 <mdomsch> question 6 - how much time do you spend looking at other environments (Ubuntu, other OSs, ...) for comparison and perhaps inspiration?  Do you think it's important to know what the "competition" is up to?
17:35:19 <pjones> j_dulaney: specifically the people elected to fesco participating, as I took it.
17:35:55 <j_dulaney> pjones:  In that case, just show up to the blocker meetings.  Just be forwarned that they will take up large chunks of your time
17:36:09 <jwb> 6) i don't have much time to do that.  i read reviews when ubuntu or someone else does a release, and occasionally help someone with a non-Fedora machine.  aside from that, i'm up to my neck in kernel bugs as it is :)
17:36:16 <nirik> 6) none at all. ;) 100% Fedora at home and RHEL other places. Fedora meets all my needs... I don't really see much need to look to other distros...
17:36:21 <sgallagh> 6) In my roles in upstream projects, I regularly load up other Linux distributions to compare their behavior.
17:36:26 <notting> 6) Personally? Very little. Not enough time in the day. (Not that this is *good*, but it's the truth.)
17:37:04 <pjones> 6) as one of many anaconda maintainers, we usually re-try several distros and even macos and windows periodically.  I've been focused on UEFI work recently, so I've been looking at what the windows 8 installer does, for example.
17:37:06 <j_dulaney> 6)  Every once in a while, one of my friends from the Ubuntu side will convince me to drop Ubuntu in a VM to check it out.  I also think that competition is a good thing, since it keeps any one project from stagnating  (cont)
17:37:25 <sgallagh> 6) (cont) On the (rare ;-) ) occasions where another OS is doing something better, I generally file an enhancement request in Bugzilla to see if we can do the same for Fedora.
17:37:48 <t8m> 6) I am installing new Linux distributions into a VM from time to time to look at them although I don't spend much time with them. As for proprietary OSes - I don't use them except old Windows XP install for old games.
17:37:56 <j_dulaney> 6) (cont) I have found that other projects ways of doing things can be better, and look to them for potential inspiration
17:38:22 <sgallagh> 6) Ah yes. I suppose I *do* keep a "wintendo" around as well.
17:38:32 <mdomsch> question 7 - Package Maintainers play a huge role in releases. Do you see any improvements that you can influence?
17:38:43 <mdomsch> question 7a) Fedora has relied on mass rebuilds between releases.  In the >10,000 packages in the set, quite often 10-20% of the packages don�t build, requiring manual intervention.  Is this process acceptable to you, or how might you want to see it changed?
17:39:11 <jwb> 7) uh... not sure what to make of that question.
17:39:30 <jwb> 7a) there's nothing easy about a mass rebuild
17:39:37 <nirik> 7) I think getting bodhi 2.0 done will help our maintainers a lot. I'd like to see us open a dialog about features and setup for that soon. Otherwise, perhaps we could poll our maintainers from time to time and ask them what their pain points or issues are. (in a non mailing list format).
17:39:40 <sgallagh> 7) I think the biggest problem with package maintenance is the ever-growing queue of package reviews that no one performs.
17:39:42 <j_dulaney> 7)  The current package process is pretty good.  Every once in a while it needs tweaking as new ideas and technologies emerge/get improved, but otherwise it is a decent system
17:40:04 <sgallagh> 7) I think we took a big step recently with streamlining the sponsor process, so we can at least help get first-time packagers on-board more quickly.
17:40:05 <jwb> the question was about package maintainers, not package process
17:40:08 <notting> 7) Improvements *for* package maintainers, or *to* package maintainers?
17:40:15 <pjones> 7) I think there are places we could work to make maintainers' lives easier, certainly.  but mostly we're dependent on maintainers of tools for that kind of change.
17:40:15 <jwb> notting, exactly...
17:40:35 <sgallagh> mdomsch: Perhaps you could rephrase the question? I think we're all answering different interpretations.
17:40:39 <t8m> 7) We could perhaps improve education of package maintainers - especially some changes in the packaging policy are not incorporated into the packages quickly enough - not sure if that is more problem on the sending or receiving end of the communication though
17:40:39 <nirik> 7a) I'd like to see it happen more often/regularly. And we are in fact hopefully working toward having a setup to do that in infrastructure. ;) I think identifying these things before a mass rebuild/often allowing us to drop them or fix them is good.
17:41:14 <jwb> 7a) there's a guy named mdomsch that used to do continous rebuilds.  dunno what happened to him ;)
17:41:14 <mdomsch> _for_
17:41:19 <sgallagh> 7a) I don't have much to add regarding mass-rebuilds. They're generally done because the build-system has changed, which is practically guaranteed to break something, somewhere.
17:41:21 <j_dulaney> 7a) The mass rebuilds are necessary.  If done more often, then the failure rate should go down
17:41:54 <mdomsch> jwb: -ENOTIME, and no one else (aside from skvidal recently) seemed to notice I stopped
17:42:01 <nirik> 7a) mass rebuilds are only done for a good reason, but I would like to see FTBFS happen every release (at least) and we are not far from that happening. ;)
17:42:36 <t8m> 7a) it would be surely nice if there were mass rebuild done more often - out of process - that is not have them done in the primary koji but outside of it and to have some nice statistics page with the failed packages w. logs etc.
17:42:37 <notting> 7) The biggest wins for package maintainers would be tools improvements, and that requires resources. Rewriting bodhi is not necessarily trivial. Similarly for auto-detecting FTBFS and so on.
17:42:45 <pjones> 7a) we do rebuilds for various reasons, usually involving toolchain upgrades that will effect packages without the package changing.  Obviously sometimes this shows us where packages are already broken, and sometimes where the new toolchain breaks (correctly or not) things that used to work.
17:43:00 <jwb> 7) with the revised question, i think improvements in the bodhi area will be great.  i also happen to like the new community tooling that is in the dev environment still (for some reason), like tagger, etc
17:43:06 <mdomsch> for example, OpenSUSE Build Service does continual rebuilds when any dependent package changes.  Should Fedora look to such a model?
17:43:41 <pjones> 7a) (cont) I think there's probably some tooling we could do to make it more apparent that things are broken earlier, giving maintainers more time.  I'd actually be in favor of exploring other techniques, like (for example) continuous random rebuilds.  But that's really about tools, not about stuff being broken.
17:43:44 <jwb> mdomsch, i think doing something like that in rawhide would be excellent
17:43:44 <j_dulaney> mdomsch:  Is that 7aa?
17:43:53 <j_dulaney> +1
17:43:56 <jwb> mdomsch, doing it in a release ... would be tricky
17:43:56 <pjones> 7aa) see my question to 7a
17:43:56 <sgallagh> 7a) I should note that any sort of continual rebuild plan would basically necessitate a hardware purchase to accomodate the additional build load.
17:44:03 <pjones> 7aa) eer, my answer :)
17:44:22 <notting> 7a) mass rebuilds should be done offline more often , or set up automatic  rebuilds on changes (as mdomsch mentioned).But again, that's tooling, and we don't have a lot of people looking at that right now. Real CI would be nice to have, but given autoqa's slow process (with little resources), it's not going to happen without people stepping up.
17:44:23 <nirik> yes, we could look to that someday.
17:44:53 * nirik notes we hope to use the upcoming fedora infrastructure private cloud for some things like this. FTBFS would work quite nicely there.
17:45:13 <j_dulaney> notting:  There's only a very small handful of folks working on AutoQA
17:45:35 <pjones> j_dulaney: I think that's part of the point he was making, yes.
17:46:01 <j_dulaney> notting:  And then for only a few months out of the year, as they get swamped later in the release process
17:46:36 <mdomsch> so encouraging, providing incentives to, the community to contribute to these "infrastructure" bits, to make everyone's lives easier
17:46:38 <notting> j_dulaney: not making a value judgmenet, other than "expecting it to magically appear" seems ill-advised
17:47:14 <j_dulaney> notting:  Indeed
17:47:32 <notting> nirik: TO THE CLOUD!
17:47:33 <mdomsch> question 7b - should FESCo do something different to encourage participation / development of these infrastructure services for the benefit of package maintainers?  If so, what might you propose?
17:48:14 <pjones> 7a) /Fedora/ should consider doing more to encourage participation.
17:48:18 <pjones> 7b.  gah.
17:48:34 <nirik> 7b) not much that I can think of. We are already open to anyone with the time/energy to help. It's hard to get people to work on things they don't find interesting... some of the slack can be taken up by fesco members themselves, but everyone is busy.
17:48:40 <pjones> 7b) (cont) mostly FESCo leaves the "provide encouragement" side of things to the board and whatnot.
17:48:50 <sgallagh> 7b) Well, this goes back to something I talked about in a previous town-hall. FESCo doesn't have any discretionary funds/prizes/swag to hand out to act as physical encouragement
17:49:01 <t8m> 7b) I don't think this is role of FESCo, but certainly Fedora should do something :)
17:49:01 <jwb> 7b) i'd like to see some FAD/vFADs around some of the tooling but that's outside the scope of FESCo
17:49:11 <j_dulaney> 7b:  If we could find a way to make it shiny, we'd get more participation
17:49:21 <notting> 7b) How do you encourage people to work on something if they don't have a passion for it? Bribery, or even the GSoC ideas, don't seem to lead to the continual engagement that is needed if you want to maintain infrastructure tools
17:49:22 <sgallagh> 7b) I think we do a good job with 'attaboy' comments, but real, true encouragement is difficult.
17:49:29 <pjones> sgallagh: right, that's why we usually leave it to the board.  that and fesco being the engineering steering committee, not the "make fedora be a popular thing to work on" committee.
17:49:42 <sgallagh> pjones: +1
17:50:12 <mdomsch> question 8 - With the change to GNOME3/GNOME-Shell there was kick back from the community, what influence should Fedora have with upstream projects if any?
17:51:04 <pjones> 8) I think if you have strong opinions about how desktop interaction should work, you need to be willing to take direct action, and should become involved with gnome (or whatever desktop you're interested in)
17:51:05 <sgallagh> 8) Well, ultimately Fedora is a consumer of our upstreams. There are a fair number of symbiotic projects whose development is mostly done within Fedora, but for the most part we take what we're given
17:51:36 <sgallagh> 8) The wonderful thing about open-source is that if you see an opportunity to fix things, you can take matters into your own hands
17:51:55 <nirik> 8) not too much really. We can't force them to work on/not work on things as we choose. I think our choices are more in the way of deciding how we package and present upstream projects. If gnome3 is really unpopular and not desired, we could look at promoting another desktop as default for example. That said, I don't see nearly as much pushback now... I think people just needed time to get used to things in that respect.
17:51:56 <jwb> 8) i think Fedora's influence on any upstream is going to be dictated by how many people from Fedora are working on it upstream.  which is true for pretty much any distro/organization
17:52:08 <notting> 8) I think there are people who work in Fedora who have a surprising amount of pull in GNOME upstream. Much like there are people in Fedora who have pull in the upstream kernel, or KDE, or SSSD, or X, or...
17:52:13 <pjones> 8) (cont) if you decide to fork gnome-2 and make it work as a DE on fedora, I don't know any reason we'd stop you from making that your own DE in Fedora either.
17:52:24 <t8m> 8) that's a hard question - I think the upstream such as in case of GNOME3 should care especially about their users but I don't think Fedora and FESCo can force them to do that
17:52:28 <j_dulaney> 8)  How much influence can Fedora have upstream without taking over the project?  There are some things developed mainly within Fedora, but without Fedora folks actively working on upstream projects, there's really not much we can do
17:53:14 <pjones> j_dulaney: it's certainly possible to argue that the developers of gnome-shell are largely working with fedora in mind
17:53:22 <sgallagh> j_dulaney: That said, Fedora folks *do* make up a pretty sizeable percentage of the GNOME upstream.
17:53:24 <pjones> in that many of them run fedora on their desktops.
17:54:02 <j_dulaney> True, but Gnome is one case
17:54:03 <sgallagh> But as nirik said, GNOME upstream has a set of decisions that it has made (love it or hate it) and they've more or less decided to stick with it.
17:54:34 <sgallagh> Sorry, s/as nirik said// (That sentence started out going somewhere else)
17:55:01 <notting> 8) Influence in upstream comes from... influence in upstream. I don't think we can magically sprinkle some Fedora water on people and make them more respected in upstreams, and I certainly don't think that trying to do anything other than gently inflluence upstreams that aren't beholden to Fedora will get anywhere.
17:55:50 <j_dulaney> +1 to notting
17:56:23 <sgallagh> notting has said what I was trying to, but more elegantly :)
17:56:34 <mdomsch> Question 9 - With 4 minutes left, each candidate may make one closing statement if they wish.
17:56:54 <t8m> notting, +1
17:57:43 <sgallagh> 9) Vote for me, or don't. I'll be working hard to see Fedora succeed either way. If you vote for me, I'll have slightly more ability to make it happen. :)
17:58:09 <nirik> 9) I look forward to helping out Fedora in whatever capacity moving forward. If any voters have questions for me, feel free to drop me an email: kevin@fedoraproject.org. I think we have a great slate of candidates to choose from here and I'd urge everyone to vote.
17:58:43 <j_dulaney> 9)  I believe that my biggest strength on the board would be an influx of new ideas (fresh blood).  I've used and loved Fedora for six or seven years now, and wouldn't go with anything else
17:59:03 <jwb> j_dulaney, this is FESCo
17:59:19 <j_dulaney> jwb:  Indeed
17:59:22 <t8m> 9) I think all the candidates are strong each having slightly different preferences in one way or another. And I also think that we need new people in FESCo as well as some continuity.
17:59:40 <jwb> 9) i want people to vote, period.  this has been fun
18:00:31 <pjones> 9) vote for me.  It's the right thing to do.  you know you want to.  search in your heart, you know it to be true.
18:00:57 <notting> 9) Vote early, and vote often. (Well, maybe not that last one.)  Seriously, I encourage that everyone pitch in and work together to make Fedora 18 and beyond better than ever. Whether you're on FESCo or not, that doesn't prevent you from working in Fedora on what interests you, and improving it.
18:01:03 <sgallagh> pjones: I know it to be heartburn. Shouldn't have had that burrito for lunch ;-)
18:01:11 <pjones> sgallagh: I don't think that's your heart.
18:01:24 <j_dulaney> LOL
18:01:38 * j_dulaney eats some bacon wrapped around a Beefy Miracle
18:01:47 <mdomsch> Thank you to all our participants today - questions from Rastlinux, EvilBob, zcat, jreznik, and myself.  And to our candidates for their time today and their willingness to serve the Project in this role.
18:02:04 <j_dulaney> +1
18:02:12 <sgallagh> mdomsch: Thank you for moderating
18:02:21 <mdomsch> Please take the time to read the candidates statements and questionnaire answers here: http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
18:02:29 <mdomsch> and remember to vote!!!
18:02:35 <mdomsch> #endmeeting