02:00:22 <rbergeron> #startmeeting
02:00:22 <zodbot> Meeting started Wed May 19 02:00:22 2010 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
02:00:36 <rbergeron> #meetingname FESCo Candidates townhall #2
02:00:36 <zodbot> The meeting name has been set to 'fesco_candidates_townhall_#2'
02:01:00 <rbergeron> Hi everyone, welcome to the second FESCo townhall meeting.
02:01:43 <rbergeron> It looks like we're missing notting and smparrish, at least for the moment.
02:02:13 <rbergeron> Question #1: what do you think is fesco's biggest  challenge over the coming term?
02:03:15 <rbergeron> notting: Question #1: what do you think is fesco's biggest  challenge over the coming term?
02:03:44 <notting> hm
02:03:48 <brunowolff> I think it is working on guidelines / policy for what kinds of updates maintainers should be doing under various circumstances.
02:03:59 <jforbes> I think the biggest challenge will be coming up with a solid update strategy which balances the needs of the packagers and the end users. Certainly you cannot make everyone happy, but a balance has to be reached.
02:04:06 <kylem> I think the biggest challenge is going to be trying to define what the goal of the project is. I'd like to see Fedora be a more cohesive competitor with Ubuntu, instead of just being a fragmented collection of packages that it feels like sometimes.
02:05:58 <notting> there's a bit of a malaise about fesco recently; meetings that drag, lots of complaints. i think the biggest challenge is getting everyone excited (or at least, not angry and sniping) and working together. having some common goals would help with that. i think progressing the updates work is a big challenge as well.
02:06:42 <mclasen> I'm not sure that there is a single biggest challenge, but making people excited and energized again about what we are building is one
02:07:15 <rbergeron> Q wrt kylem's comment: please expand upon that thought.  What  role do you see FESCO playing in the larger discussion of  Fedora direction?
02:07:38 <rbergeron> (everyone can answer - not just kylem.)
02:07:56 <kylem> FESCo should be providing technical leadership to the project as a whole, as well as setting best practices. Obviously, it's for the project as a whole to decide what its direction is, not just FESCo's.
02:09:23 <brunowolff> I think one area FESCO can help is facilitating communication between groups. If the gnome people want to add a new
02:09:27 <mclasen> I think fescos role is to define the concrete policies and changes that let us move in one direction
02:09:33 <notting> once a direction is chosen, it's going to fall to fesco to organize development towards that direction
02:09:59 <brunowolff> feature, it may be important for other desktop teams, such as KDE to know what's coming in time to prepare or
02:10:21 <brunowolff> to raise issues that may require the gnome team to modify their plan.
02:11:03 <jforbes> The key in FESCo is "steering" and I think we can help steer the distribution to a more cohesive one, but it will certainly take working with the community and getting people excited about the idea.
02:11:17 <rbergeron> Q wrt current question: How do you want to solve technical conflicts between various groups in Fedora, such as when one group wants to remove something another group depends on?
02:11:19 <brunowolff> FESCO is a central place for these groups to communicate.
02:12:44 <brunowolff> We need to talk to interested parties and find out why the groups are having a conflict. Depending on the details
02:12:57 <kylem> I think FESCo needs to help the parties look at the big picture, either finding someone to take over the component, or find an equitable transition strategy. Anything else would be tantamount to dictating what people should work on, which I don't believe is FESCo's mandate.
02:12:59 <brunowolff> there are many possible routes to a solution.
02:13:26 <notting> repeating from an earlier townhall... "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"
02:14:37 <mclasen> most of the time, features are about adding things, not removing things. in the cases where we've removed things, 'removal' usually means relegating to a subpackage until all users have been ported away
02:14:56 <jforbes> I think we brought his up in the last town hall.  I think the best solution is a sort of deprecation system to make sure that there is transition time, and no one gets left in the lurch.  But we cannot impede progress, we can only make sure that it is managed in such a way that the transition is smooth
02:15:07 <rbergeron> Q: Do you believe in the Board's stated Stable Release Updates Vision Statement, and will you work to implement it? If not, why not?
02:15:32 <brunowolff> I have a disagreement I believe I commented on in another forum.
02:16:02 * nirik arrives late. ;(
02:16:04 <brunowolff> I think the bug fix and security updates only policy needs to have a way to make exceptions.
02:16:15 <rbergeron> < mizmo> where is that brunowolff i didnt see it
02:16:52 <rbergeron> nirik: current question is: Q: Do you believe in the Board's stated Stable Release  Updates Vision Statement, and will you work to implement it?  If not, why not?
02:16:56 <brunowolff> There are some niche packages that need to interoperate with other things and to provide that an update to
02:16:59 <mclasen> I agree with the boards vision and want to work towards making our releases more stable, and rawhide usable as a place to try cool new stuff
02:17:02 <brunowolff> a new release may be needed.
02:17:05 <nirik> 1. Balancing the needs/desires of maintainers, qa folks, and end users, so everyone can find fedora fun and enjoy using it.
02:17:41 <brunowolff> Some games for instance need to match versions with central servers or other players not using Fedora.
02:17:54 <brunowolff> So I think there should be an exception process.
02:18:06 <brunowolff> In general I like the policy.
02:18:37 <kylem> i'm definitely in favour of more sane stable updates; we have no frozen rawhide now to allow things to gel. there's more to maintaining software than just shoving new versions in and typing rpmbuild. if people object to putting more effort into it than the bare minimum, then i think we need to re-think our standards for such things.
02:18:40 <brunowolff> But if the board says no exceptions, while the policy is in effect, I'll follow it.
02:19:01 <nirik> A: I do mostly agree with it... I think stable releases need to be more stable. We have seen a LOT of end users unhappy with updates breaking things or causing issues. I think we can do a lot more to test and get users involved in making sure updates are ready to push to everyone.
02:19:20 <jforbes> I believe in the vision statement as it was posted, and it seems to provide some latitude.  I would work to implement it.  Note that it does not simply state "no new features" It says that updates should provide a consistent user experience and be used for bug fixes and security fixes.
02:19:27 <notting> i believe in the updates policy, and would work to implement it. while i understand there are those who would like a faster flow of software, there are also many that don't. given that, we have to start with the stable stream, and perhaps find a way for those users who want something more adventurous to build on top of it
02:19:37 * nirik notes the link is https://fedoraproject.org/wiki/Stable_release_updates_vision
02:19:57 <rbergeron> Q: 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?
02:20:20 <mclasen> I also hope that kopers will open a new way to bring new stuff to users without making things unstable for everybody
02:20:40 <brunowolff> I think we should support low bandwidth users as part of our outreach.
02:21:29 <notting> 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.  so ideas like deltas can help in that case for lower-bandwidth users.
02:21:31 <brunowolff> This may involve creative solutions in getting data to people other than by network as providing smaller iso images
02:21:39 <nirik> A: I think we shouldn't focus at least at first on size or number of updates. I think we should focus on quality. Doing more testing and making sure things are ready to be pushed as an update may well slow the flow of updates. If the number is still seen as a problem after the quality issue is under control we can revisit that as a seperate issue.
02:21:44 <brunowolff> and some way to select some updates.
02:22:13 <jforbes> I would like to see solutions to facilitate low bandwidth users, but I think the size of updates is an issue regardless of bandwidth.   I would like to see a reduction in the number of updates, with more focus on QA of updates we do push
02:22:44 <mclasen> Delta updates can help somewhat for low-bandwidth situations. For 0-day updates, I think we should be agressive in reducing them because they just give a bad experience to everybody, independent of the available bandwidth.
02:23:08 <kylem> i'm in agreement with nirik, i think the focus should be on up front quality.
02:23:28 <rbergeron> on the current question: are updates alone the concern for  low-bandwidth users?  Or are there other concerns to be  addressed somehow?
02:23:49 <notting> there's a bit of a tug-of-war between zero-day and not slipping, but for things not directly affecting the core release, avoiding zero-day should be preferred.
02:24:38 <brunowolff> There are other issues. Increasing the size of the livecd image to target 1GB USB devices is a concern.
02:24:39 <nirik> well, updates are a big one, but there are other issues... media sizes and offerings for one.
02:25:21 <nirik> in some places dvd's are not common, so the cd's still being offered is a good thing.
02:25:26 <notting> once they're installed, updates are the big issue. we're not deploying online services, so it's not like general access would be worse with us than with other linux options.
02:25:27 <mclasen> another concern for low-bandwidth users is the amount of software that comes in the image vs what needs to be installed afterwards
02:26:11 <brunowolff> It can be hard to just get security updates because of dependencies on other updates.
02:26:43 <jforbes> brunowolff: that shouldn't be a problem with stable updates.  we shouldn't be changing sonames or abis in an update stream
02:26:59 <mclasen> if we can't include openoffice in the image for size reasons, a low-bandwidth user in need of office is in a bad spot....
02:27:09 <brunowolff> I agree we shouldn't. But currently it does happen.
02:27:24 <notting> some people with low bandwidth want a smaller download that contains just what they want. others want a larger download that contains everything they might possibly need at some point in the future. hard to go both ways at once there.
02:27:53 <nirik> also, that gets us to locallized spins... ;)
02:28:02 <jforbes> brunowolff: back to the the updates policy, and trying to get it into place.  People can wait 6 months for major changes like that, no frozen rawhide makes it even easier.
02:28:59 <rbergeron> Q: What do you see as the challenges, technical, social, political, that prevent Fedora's wider adoption (increase the size of the user base)?  Is that a worthwhile goal in your opinion?  What will you do as a FESCo member to address these?
02:29:12 <jforbes> notting: We can go both ways at once... spins can make things smaller, and the distro can offer a larger download containing most of what people might want
02:29:24 <brunowolff> mizmo: http://lists.fedoraproject.org/pipermail/advisory-board/2010-March/008236.html
02:29:47 <nirik> I think stability will help a good deal. I think that we shouldn't blindly go for popularity at the cost of our values.
02:30:12 <kylem> the main challenge i see is that ubuntu has been doing a better job providing what a broad swath of the public wants. i think trying to regain some of that lost ground should be a worthwhile goal, in my opinion.
02:30:45 <notting> nirik: i don't think that going for more users necessarily contradicts any of our values.  going for *all* users would lead to compromises, sure
02:31:17 <brunowolff> I think we should work at improving, stability, ease of use and video support.
02:31:21 <nirik> sure, but sacrificing things like shipping mp3 support, libdvdcss, etc would get a lot of users unconcerend with issues happy.
02:31:27 <jforbes> While I don't focus too much on marketing, I think the best thing we as FESCo can do, is make sure that we are putting out the best quality distribution possible.  We follow a balance of being current and stable that has the potential to attract a large number of users
02:31:29 <nirik> But I don't think we can or should do so.
02:31:58 <brunowolff> We aren't going to be able to satisfy the needs of a lot of users because of software patents.
02:32:01 <notting> given that the other options to increasing the user base are 1) staying static 2) shrinking, i'm obviously for increasing the userbase. i think it's easier to work on converting 10% of a larger user base into contributors, rather than trying to convert 50% of a smaller one.
02:32:25 <mclasen> I think we want to try and find a somewhat different angle than ubuntu, focussing more on gaining users that also want to contribute, but regardless which segment of the userbase we aim for, things need to be stable and work
02:32:53 <mclasen> It pains me that I cannot in good conscience recommend Fedora to friends or family members
02:33:17 <rbergeron> Q: Do you think the feature process is a good one? Might wrapping features in more abstract terms help focus effort  around improving certain "user experiences?
02:33:24 <notting> but to pick an example... there are lots of upstreams that make their software available only on ubuntu. or do their development on ubuntu. why shouldn't we work to make fedora their weapon of choice? (admittedly, they're likely following the market)
02:34:45 <nirik> A: The feature process isn't perfect for sure, but I think it's a powerfull marketing/documentation tool. I think it's also useful for coordination amoung teams. I would like to see features get more feedback from end users/maintainers rather than just fesco.
02:35:22 <brunowolff> The feature process is good for marketing and also for telling other people in the project what's going on for
02:35:32 <brunowolff> the next release fairly early in the process.
02:35:34 <notting> i think the feature process is certainly better than what we had before the feature process... it gives marketing talking points, it gives our collateral a focus, it can generate excitement, and it can be a source of collaboration
02:35:58 <jforbes> I think the feature process needs a bit of tweaking.  While it has several benefits, I think we can do more to get the community involved in the process.
02:36:30 <notting> it's certainly possible to try wrapping the feature process as is suggested. would be an interesting experience.
02:36:30 <mclasen> The feature process is working ok for ensuring a certain baseline of quality and documentation, but it really falls flat when it comes to coordinating an overall direction
02:36:59 <notting> to go along with mclasen... it's good for showing what we did, not as much for planning what we will do.
02:37:21 * nirik nods. Agreed.
02:37:36 <nirik> what we did, or what we are doing now, not what we are planning.
02:37:47 <brunowolff> It's OK for some projects to get a sanity check when they aren't going to need a lot of outside work done.
02:37:59 <kylem> i'm in agreement with notting and mclasen, i think we need to be a bit more hard lined about freezing too, given we have a 6 month release schedule, slipping is not the end of the word.
02:38:15 <brunowolff> For something sweeping affecting multiple areas, we probably should be doing real project management.
02:38:34 <brunowolff> However we seem to have only one project manager for all of Fedora.
02:38:53 <mclasen> kylem: but we have no beyond-6-month horizon for the feature work...there are no F14 features lined up yet.
02:38:57 <notting> brunowolff: i could be wrong, but i don't see a lot of volunteer project manager resources
02:38:59 <nirik> given that development takes place mostly upstream, I don't think it would be easy for Fedora to dictate what an upstream does...
02:39:01 <brunowolff> I tried to recruit some a couple of months ago, but didn't succeed.
02:39:03 <jforbes> mclasen: I think we should
02:39:12 <kylem> mclasen, we definitely should, heh
02:39:23 <rbergeron> Q: Do you think Spins were a good idea for Fedora? If so, where  do you see them going in the future? If not, what do you think  we should do with them?
02:39:41 <brunowolff> I found some, but they volunteer differently. There was some interest but no follow through to Fedora.
02:40:17 <notting> well, that's a fun question
02:40:30 <brunowolff> I have a feature waiting for lzma squash FS to get into the upstream kernel.
02:40:55 <nirik> A: I think spins were a good idea at the time. I'm not sure they are always going to be good. In the hand wavy future I would like to see more ways to install fedora that let you choose what you want, instead of a live media. Boot.fedoraproject.org may take over some of this. It should also be stressed that you should be able to install say Xfce after the fact on any fedora install and get the same experence that you would from the live media.
02:41:33 <nirik> Another possibility would be some kind of 'foobar-pack' rpm or group that would set things ideally for that 'spin' or group...
02:41:52 <notting> i like the idea of spins as an idea reactor for people to try new ideas for new areas, or markets, or use cases.
02:41:57 <brunowolff> I think they are a good idea. They provide a way to market Fedora. Some of the really specialized ones are usable as appliances.
02:43:12 <brunowolff> But we should probably be emphasizing building your iso's more and deemphasizing producing iso's as part of the release for live images.
02:43:26 <jforbes> I think Spins is a great idea for Fedora, there are several places where Fedora is great, but a one-size-fits all distribution just isn't the answer. I think as cloud and virtualization becomes more common, spins will have even more place out there
02:43:28 <mclasen> The idea of being able to quickly spin a livecd to try something out, or do a special-purpose thing is pretty cool, and has led to some good things being developed. But spins as they currently operate have a negative impact on Fedora as a whole, they have increased the 'tribalisation'
02:43:28 <notting> i'm not exactly thrilled that a lot of the spins end up as just 5 or 6 different desktop variations; i'd prefer to join forces to  have one kickass one. but if that's what people want to do, we shouldn't stop them.
02:45:00 * rbergeron waits a moment for kylem
02:45:01 <brunowolff> This is especially true with USB drives. With those you can actually run off of them. Running off a DVD with it's large seek time is no fun.
02:45:37 <kylem> i think everyone has made good points for their pros and cons. i don't really have anything to add.
02:45:44 <rbergeron> okay :)
02:45:49 <rbergeron> Q: AutoQA has been suggested as that Holy Grail, to automate our lives and make our releases of higher quality.  What is  your perception of the state of AutoQA, where would you like to see it go, and how (if?) will you participate to see that   come to fruition?
02:45:54 <kylem> i don't work on them, nor am i rel-eng, so i don't really know. :)
02:46:51 <kylem> i think the biggest annoyance i see, which i hope autoqa can help solve, is broken deps in the coming release, and rawhide, which look pretty bad in yum update.
02:46:56 <brunowolff> I think we should have as much auto QA as is practical. It will save on people time and catch things that people
02:47:12 <jforbes> I don't think that AutoQA is the Holy Grail, but it does offer a good bit of standardized testing, freeing up a bit more time for testing which can only be done manually
02:47:15 <kylem> catching that before a push, and waiting for a catch up, would certainly be nice.
02:47:16 <nirik> A: I think it's a very good step, it's not the end all, but it's very much a good framework to get up and running. I would love to see it go to allowing per package tests, lots of base testing, etc. I haven't personally been too involved in it, but as soon as the framework is more up and running I would be happy to contibute.
02:47:28 <notting> automated QA tests are a good thing. i obviously want it yesterday. however, that's a bit hypocritical as i honestly don't have spare time to commit to it now.
02:47:34 <brunowolff> would miss. We can use the time saved to have people do other tests that aren't easily automatable.
02:48:03 <mclasen> automate my live ? no, thank you. But I hope autoqa will make rawhide a safe place to stay in day-to-day.
02:48:37 <rbergeron> Q: FUDCons are not the Fedora N+1 planning process they could be.  Do we need a F2F method to help drive better planning?  Do we need better planning for N+1, or is the current method sufficient?  What would you see your role in any such future planning activities be?
02:49:01 <mclasen> F2F ?
02:49:07 <kylem> mclasen, face to face
02:49:08 <mclasen> ah, face-to-face, got it
02:49:08 <rbergeron> face to face.
02:49:18 <brunowolff> I would think that significant projects would be better off using FADs.
02:49:18 <notting> i think we need a focus or a vision before we start having large-scale planning
02:49:56 <nirik> A: It's hard to plan for all of fedora. I think targeted FAD's like the one where no frozen rawhide came out of are the way to go.
02:50:13 <kylem> i think the fudcon 'community' day is really quite good, i've enjoyed seeing the 'status update' sort of sessions there. i think better use could be made of the hackfest days to do project planning for the coming release, but it's hard to integrate both people present, and people online into a single discussion.
02:50:14 <brunowolff> At FUDCons you might brain storm some things to look at and form some loose teams to continue working after the fudcon.
02:51:02 <mclasen> I think we need smaller, focused hackfests ie FADs. But at the same time, fudcons could be much more effective in gaining mindshare for  fedora. Ubuntu is very successful with inviting upstream developers to their uds's
02:51:23 <notting> assuming we have a plan, larger scale planning implies committed resources. not sure we have those right now either
02:51:54 <jforbes> I think FUDCons could be slightly more useful for N+1 planning, but we could also use the feature process a bit more productive for that as well...
02:52:17 <mclasen> I'll point out that we could also learn from ubuntu wrt to enabling online participation
02:52:34 <notting> one issue, of course, with using fudcons for more large-scale planning is that getting everyone in one place doesn't scale :/
02:52:57 <brunowolff> I have participated in FADs remotely with a combination of IRC, gobby and Fedora Talk. It works pretty well.
02:53:01 * mclasen hasn't been to the last few fudcons :-(
02:53:09 <brunowolff> At the FADs I felt connected.
02:53:25 <nirik> it's easier there because there is a focus/track...
02:53:41 <brunowolff> I tried this at the last FUDcon and it was very difficult to particpate meaningfully remotely.
02:53:43 <nirik> so many things go on at a fudcon it's hard to keep track of everything remotely.
02:54:19 <notting> it's obviously hard to be in multiple talks at once
02:54:21 <brunowolff> To make it work I think you need a lot of upfront planning and FUDcons seem more adhoc.
02:54:47 <rbergeron> Q: what role do you think fesco has to play in fedora  infrastructure?
02:55:23 <rbergeron> Q: for example folks are talking about enabling remote  participation in fudcons... sounds like something an  infrastructure app or two might help with
02:55:47 <nirik> A: I think fesco can/should ask for resources from infrastructure when needed... or work with them to get things implemented that are decided on.
02:56:37 <nirik> fedora talk could/may help some, but even then, it's difficult to participate with 8 talks going on in 8 rooms. ;)
02:56:54 <brunowolff> And Infrastructure also might ask FESCO to help them find help getting apps written such as using Fedora Engineering Services.
02:56:56 <kylem> i think fesco can act as an technical interface between sides, if possible, but other than that, i'm not sure.
02:57:15 <notting> fesco certainly can ask infrastructure for resources... but there are still resources that need to be rounded up. for example, infrastructure might run fedoratalk, but they still need people willing to run the conference rooms
02:58:09 <jforbes> I think FESCo is a user of Fedora Infrastructure, and can possibly be of assistance to Fedora Infrastructure, but I don't know that there is any more formal of a relationship than that
02:58:11 <nirik> Fedora Engineering Services may be able to help getting things implemented that fesco thinks need to be implemented. Otherwise the only power fesco has to implement things is it's members... ;)
03:00:06 <mclasen> I don't really know enough about how fedora infrastructure is run to answer that; but I could see a role for fesco in making sure that important features have the infrastructure resources they need
03:00:12 <rbergeron> Okay, folks, it's the end of our hour.
03:00:40 <rbergeron> If it's okay, I'd like to post the questions nirik missed to him, so that we can get that in the logs.
03:00:50 <rbergeron> Otherwise, we are out of questions.
03:00:51 <jforbes> Thanks for putting this together
03:00:54 * inode0 thanks rbergeron and our other moderators for helping with town halls this election, the candidates for sharing their time and ideas, and the audience for caring enough about Fedora to come and participate
03:00:56 <nirik> thanks rbergeron
03:01:02 <notting> thanks rbergeron
03:01:04 <kylem> thanks.
03:01:12 <jforbes> rbergeron: sure, niriks answers would be good in the logs
03:01:26 <rbergeron> Question #1: what do you think is fesco's biggest   challenge  over the coming term?
03:01:27 <nirik> I'd like to add that if anyone have further questions for me, feel free to email me or catch me on irc. I'm happy to talk to any folks about their questions.
03:01:37 <nirik> 1: Balancing the needs/desires of maintainers, qa folks, and end users, so everyone can find fedora fun and enjoy using it.
03:01:59 <rbergeron> question 2 was - Q wrt kylem's comment: please expand upon  that thought.   What  role do you see FESCO playing in the  larger discussion  of  Fedora direction?
03:02:04 <rbergeron> kylem's comment was,
03:02:14 <nirik> 2: Well, we are the techincal side. So, if the Board gives us a vision we should work
03:02:15 <nirik> to implement it. However, I would like to see us step up and implement things
03:02:15 <nirik> that need doing via Fedora engineering services, or fesco members stepping up to make
03:02:15 <nirik> things happen.
03:02:21 <rbergeron> I think the biggest challenge is going to be trying to define  what the goal of the project is. I'd like to see Fedora be a   more cohesive competitor with Ubuntu, instead of just being a  fragmented collection of packages that it feels like  sometimes.
03:02:25 * rbergeron grins
03:02:46 <rbergeron> question 3: question 3 - Q wrt current question: How do you want to solve  technical  conflicts between various groups in Fedora, such  as when one  group wants to remove something another group  depends on?
03:02:56 <nirik> Case by case. I think most of those issues in the past have been able to be
03:02:56 <nirik> solved by just compromising. For example, the group that wants to remove something
03:02:56 <nirik> could just allow someone from the other group to take over maintaining it.
03:03:21 <rbergeron> Awesome. I think that's it.
03:03:35 <nirik> thanks again. Sorry I was late. ;(
03:03:46 * rbergeron thanks everyone for their participation and reminds everyone to vote, vote, vote!
03:04:12 <rbergeron> #endmeeting