18:07:25 <MooDoo> #startmeeting FESCo-Town-Hall-2009-12-03
18:07:25 <zodbot> Meeting started Thu Dec  3 18:07:25 2009 UTC.  The chair is MooDoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:07:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:07:33 <MooDoo> #meetingname FESCo-Town-Hall-2009-12-03
18:07:33 <zodbot> The meeting name has been set to 'fesco-town-hall-2009-12-03'
18:07:40 <MooDoo> Welcome to the second FESCo townhall everyone.
18:08:03 <MooDoo> If you have questions, as before can you post them in #fedora-townhall-public and I'll queue them up and paste them here
18:08:59 <MooDoo> Can we do a brief intro just for those not here for the last town hall, if that's ok.
18:09:31 <MooDoo> Who wants to go first....
18:09:43 <mjg59> I'm Matthew Garrett, and I work on mobile and power management stuff from the kernel upwards
18:09:50 <jforbes> I am Justin Forbes, currently working on Virtualization in Fedora, previously worked on the port to x86_64 in the FC1/2 timeframe
18:10:24 <rjune> My name is Richard June, I'm a generalist. I currently do bugzappers and maintain a dhcp config utility. In the past I maintained an extra repo for Fedora Core
18:10:57 <cwickert> Hi, I'm Christoph Wickert, a long time contributor from Germany. I'm packager, packager sponsor, ambassador, artist, ... I did a lot of stuff, please look at my wiki page for details
18:14:08 <MooDoo> ok moving on to the questions.
18:14:29 <MooDoo> if you could put the number of the question next to your answer that would be great
18:14:35 <MooDoo> 1. < EvilBob> Should we look at perhaps skipping a release in the future just to  clean things up? I know there was a thread topic like this on the  -devel list I did not read the thread however. We keep pushing the 6  month release schedule, could the extra time once in a while allow us  to meet that 6 month timed release regularly?
18:15:19 <mjg59> [1] I think that's difficult to answer without a solid idea of what "clean things up" means.
18:15:45 <rjune> 1. I don't think skipping a release is a great idea, but I would be more in line with a release focusing on cleaning things up.
18:15:54 <pjones> I'm Peter Jones, I work in the installer group at RH, and I'm also in another meeting right now.
18:16:21 <mjg59> [1] In terms of hitting our release schedule, I don't think most of the issues that generally cause us to miss it would be helped by skipping a single release
18:16:49 <ajax> i'm ajax, and i have an X problem.
18:16:55 <jforbes> 1. I don't think skipping a release is the answer.  More focus on QA, and tools like autoqa should help us identify issues earlier and that should help with cleanup.  And I am certainly not opposed to a release with less focus on features and more on stability, but skipping a release wouldnt be of much value in my opinion
18:16:59 <pjones> 1. I think "skipping" a release is a pretty good recipe for making the N+1 release even /more/ painful.  I don't really see how that's better than a) always striving for a really solid release, combined with b) high quality updates.
18:17:15 <cwickert> I think a regular schedule is important to have a solid base to build upon. We don't want to end up like Debian did in the past and now even they switched to a timebased schedule instead of "it's done when it's done". We are not Duke Nukem Forever! ;)
18:17:55 <mjg59> [1] So, really, any proposal along these lines would have to come along with a detailed description of the problems it would fix and how skipping a release would achieve them. I'd be surprised if it were possible to make a convincing proposal along those lines.
18:18:01 <MooDoo> < EvilBob> mjg59, our processes, our docs, our infrastructure needs. We do this
18:18:04 <MooDoo> every release but can more time, less stressed to get things done
18:18:07 <MooDoo> before a release help?
18:18:12 <ajax> 1: i think there's a fallacy here.  "cancel f13 and fix f12" implies that people think f13 is something other than improvements to f12.
18:18:50 <pjones> ajax: yeah, that's pretty accurate
18:19:13 <rjune> ajax, but where is the focus, more whizz bang, or making the current whizz bang work better.
18:19:26 <rjune> EvilBob, wants some focus on infrastructure and docs.
18:19:27 <mjg59> [1.a] Skipping a single release wouldn't seem to help that problem. If we have too much work to do in the process, docs and infrastructure areas then won't that just build up again?
18:19:36 <pjones> rjune: I don't honestly think we're "focused" on either of those
18:19:48 <ajax> 1: i don't think schedule changes would help.  i think process improvements would help.
18:20:06 <mjg59> I think "We can't finish everything in time" is a valid issue. I don't think "Let's cancel a release" is a good way of resolving that issue
18:20:11 <pjones> ajax: I think schedule changes could help with some things; I don't think /this/ suggestion for a schedule change is on the right path.
18:20:24 <ajax> pjones: that's closer to what i meant, yeah.
18:20:25 <jforbes> Historically there have been releases which went longer than the standard 6mo release cycle.  I am not sure that there was much value to that from a clean up perspective.  It meant more features added, and stabalized in the same manner as a regular release cycle
18:21:04 <mjg59> I think there'd be a much more solid argument for a longer release cycle, coupled with a greater absolute amount of time in that cycle being spent on stabalisation
18:21:13 <cwickert> 1. I don't think that skipping a release will help us with docs or infrastructure. Instead we need to improve our workflows to get more things done easier in the same time. A release wil help us to do this, not prevent us from doing so
18:21:15 <pjones> jforbes: yeah; that helps more from a 'feature enablement' perspective than from a 'make it more solid' POV.
18:22:35 <jforbes> I think if we were to try to extend the release cycle for the purpose of stabalization we would basicaly be keeping feature freeze and such the same, and perhaps add another test release.  Again, I am dubious as to the value because I am not sure it will increase the number of testers we have.  Use patterns are different and quantity of testers will help more than the duration of testing
18:23:21 <mjg59> Just to emphasise my feelings here - if the current release process doesn't give us enough time to, for example, document everything, that's a genuine problem with either our release process or our documentation process, and that should be fixed. Skipping a release wouldn't fix the underlying issues.
18:23:34 <jforbes> Well, quantity + quality... The feedback has to be good for it to be meaninful, a hit and run "this package doesnt work" with little follow up is rarely useful
18:24:20 <mjg59> Would the purpose be to get more testing? Or would the purpose be to let us do more useful work in response to that testing?
18:24:41 <MooDoo> < EvilBob> Yeah I don't think it would help stabilization, and I would hope it
18:24:45 <MooDoo> is not the focus, we can't fix the release, we can fix or improve
18:24:53 <cwickert> 1 I think what mjg59 is right. A longer release will not help is, it does not fix the root of problems, but on the other hand we loos a lot. we might even loose our leading position in linux development
18:25:58 <jforbes> mjg59: I think they go hand in hand.  When critical issues are reported in test releases, they can delay the final release if they are not fixed.  but a lot of new issues get reported just before or just after release.  Issues that were there all along, but no one noticed because they didnt fall into the use patterns of our regular test base
18:26:08 <MooDoo> <notting> actually as a sort of folloup, where do you think the current development schedule need to change, if anywhere?
18:26:48 <pjones> I think that the current development window is, in general, too small for any project /tightly/ coupled with fedora.  there are two ways to address that problem, and maybe we should do both ;)
18:26:54 <mjg59> I think it's unfortunate that our developer base is sufficiently small that implementation and stabalisation have to be done by the same people
18:26:57 <pjones> (those being: decouple them and lengthen the window)
18:27:24 <ajax> i don't think our schedule is actually a problem, in general. i think culturally we don't have the cojones to tell people "no" when they try to merge crap at the last minute.
18:27:34 <mjg59> In theory our release process allows development to occur from feature freeze in one release until feature freeze in the next release
18:28:01 <rjune> notting, Off the cuff, without really examing it? I'm not sure the schedule needs to change. Instead, spend a release focusing on resolving some of the infrastructure issues. That will lead to a release with a small delta vs the previous, but make life simpler in the next release
18:28:04 <mjg59> In reality, post feature-freeze nobody has time to do any development because they're too busy stablising code that was previously untested
18:28:19 <jforbes> I think, if I were to change the development schedule I would probably mangle the feature process as it is a bit, and possibly make a "beta" release a bit earlier, because the beta tag draws more testers than "alpha" or "preview"
18:28:42 <cwickert> I think we need to stabilize sooner in the development cycle. The alpha release should *really*be feature complete so we can focus on fixing bugs
18:29:12 <rsc> cwickert: +1
18:29:16 <mjg59> cwickert: Note that doing so would massively reduce the amount of development that occurs (not just in Fedora, but in Linux as a whole)
18:29:19 <rsc> sorry folks for being late.
18:29:39 <MooDoo> rsc: not a problem.
18:29:41 <mjg59> When we say "Stabalisation" here, it's easy to forget that there's a cost. The cost is that more stabalisation means less development
18:30:15 <mjg59> Ubuntu have much more leeway here, because they do so much less development in the first place - they can spend time on stabalisation
18:30:26 <cwickert> right mjg59, this is always a fine balance between innovation and stabilization. By "feature complete" I didn't mean each and every feature must be  100% done, but it must be basically working
18:30:36 <MooDoo> QUESTION 2. < Viking-Ice> If you were given then chance to write new "Arecibo message" which would be beamed into space in attempt to enter into a conversation with extraterrestrials, what would that message say?
18:30:36 <pjones> cwickert: that's a fairly fatalistic plan though :/
18:30:44 <mjg59> But the main areas where we see people complaining about a lack of stability are drivers and core infrastructure
18:31:02 <pjones> MooDoo: "we come in pieces".
18:31:23 <cwickert> when I think of the changes to the desktop that happened quite late in the release cycle and nearly without communication, I think this a good example of what should have been different
18:31:28 <mjg59> And spending more time stabalising that would mean that Linux, as a platform, would develop much more slowly
18:31:28 <rjune> 2. Beware video broadcasts. they will rot your brain.
18:31:53 <mjg59> [2] "Don't turn up unless you're going to fix our problems and not bring any of your own"
18:32:51 <ajax> man, this is a tough one.
18:33:27 <cwickert> 2. "We come in peace and with good software"
18:33:38 <ajax> 2: we're trying, but as a species, we're still infants.
18:33:40 <mjg59> [1] I don't think that there's a fundamentally good answer for this issue. The correct balance between stabilising and feature development depends heavily on what we want the distribution to be and who we want to use it. I'm hopeful that things like the no frozen rawhide proposal will make it possible to let people carry on development without being blocked on other people's stabalisation
18:33:59 <rjune> mjg59, we're all missing the boat on that question.
18:34:01 <mjg59> [1] But really, we need more developers to help with the difficult problems
18:34:06 <jforbes> 2. Something of a puzzle to figure out would probably be the most entertaining conversation starter with a culture you know nothing about...
18:35:06 <pjones> cwickert: I think there's a problem with just moving the freeze date sooner - one of the big problems we (the anaconda group) has is that many of the things we need to do to modernize the install environment take longer than the window /already/.
18:35:18 <pjones> cwickert: I'm sure other groups have similar timing problems
18:35:26 <ajax> jforbes: something like "have you solved the riemann hypothesis"
18:35:46 <pjones> ajax: or "is P = NP?"
18:35:52 <ajax> damn you, i was just typing that
18:36:00 <pjones> ajax: something to distract them for a good long while
18:36:08 <MooDoo> ok moving on all.
18:36:15 <MooDoo> QUESTION 3 < EvilBob> DiscordianUK: Q: The PackageKit episode demonstrated that some parts of the Bugzilla for various bugs were Redhat only? How would the candidates address that to ensure that Fedora is a Community OS?
18:36:32 <ajax> "demonstrated", eh.
18:36:51 <cwickert> pjones: I didn't say we should move the freeze day sooner, I said we should look at being more complete at that point. I think many people think: "Hey, I can still do this later". Look at the desktop changes, they were even after the freeze because they were not fundamental from a technical POV. but from a users POV they were
18:36:52 <pjones> I am widely in favor of a separate fedora bugzilla.  There are some significant downsides to doing that, though
18:37:04 <mjg59> [3] What this question basically boils down to is "How can we prevent people talking to each other anywhere other than in public"
18:37:04 <pjones> cwickert: that's effectively the same thing, though
18:37:28 <ajax> 3: that's been true since, oh my, rhl4 or so?  i'm a bit surprised that people could be not aware of it.
18:37:35 <pjones> cwickert: you're talking about making the hard freeze date the same as the soft freeze date.
18:37:52 <mjg59> [3] If I use privmsg with a Fedora community member, am I damaging Fedora as a community OS? What about if I use privmsg with a fellow RH employee?
18:37:52 <jforbes> 3. As it stands, we try to ensure that Fedora bugs are completely open, without even private comments.  That said, some issues that get fixed in Fedora were identified in other channels and not filed publicly.  Perhaps the best solution there is to create another bug with the important info and without any confidential information
18:38:05 <ajax> 3: that said, i have _many_ issues with the redhat bugzilla, but the general problem of federated bugzillae is basically unsolved.
18:38:10 <pjones> ajax: rhbz isn't that old ;)
18:38:20 <pjones> ajax: rhel5 or so
18:38:24 <pjones> rhl5 rather
18:38:30 <pjones> my fingers don't know how to type rhl any more.
18:38:54 <ajax> 3: as a start, i think it's probably legitimate to disable private comments on fedora bugs.
18:39:07 <rsc> 3. I don't see a problem with having the same bugzilla for Red Hat and Fedora. Each distribution has its parts?
18:39:13 <ajax> although that's messy if you move a bug across products?  whatever.
18:39:14 <rjune> 3. I'm with mjg59  on this, the basic question is how do we keep public discussion public. And realistically, this is not really possible.
18:39:21 <pjones> ajax: but what about private bugs, for e.g. embargoed security fixes?
18:39:23 <rsc> ajax: private comments are useful for security reports or confidential data.
18:39:28 <mjg59> [3] So, yeah, I think it's unfortunate that bugzilla gets used as a private backchannel. But at the same time, the logical extension of this would be that I can't go downstairs and talk to ajax about power management policy in the X server
18:39:54 <ajax> pjones: that's a private bug, not a private comment.  but sure.
18:39:56 <pjones> rsc: to rephrase my question to ajax - private comments or private bugs?  why does any part of an embargoed bug need to be public?
18:40:06 <jforbes> ajax: good idea, the problem is bugs that were not filed as fedora bugs, but fixed in fedora as well and reference a non public bz.  Perhaps cloning the bug as a separate Fedora bug without confidential info is the answer to that though
18:40:14 <mjg59> [3] And really, I think a more interesting question is "Why do people feel the need to use private backchannels"
18:40:21 <rsc> pjones: both.
18:40:25 <cwickert> 3: I have to admint that I don't understand the question. What parts of bugzilla are private and how do RH bugs affect Fedora?
18:40:47 <pjones> mjg59: oh, that's easy.  the public channels result in a lot of armchair quarterbacking
18:41:02 <mjg59> cwickert: bugzilla.redhat.com allows users who have @redhat.com accounts to flag comments as "private", which can then only be seen by other @redhat.com accounts
18:41:10 <mjg59> cwickert: This is true even in Fedora bugs
18:41:32 <cwickert> mjg59: but AFAIK this was not the case with the PK bug report, was it?
18:41:38 <mjg59> cwickert: It was
18:41:44 <mjg59> Some of the commentary was in private comments
18:42:06 <jforbes> cwickert: a customer can file a bug, which might include information that they dont want made public, and those bugs are not visible to everyone.  As for private comments, for virt bugs at least we try to remind people not to do that when it is done, and it is fairly rare these days
18:42:20 <cwickert> I don't have a rh.com address, but I could see them all (at least I think so)
18:42:36 <mjg59> cwickert: You don't see "This is a private comment", you just see a gap in the comment numbering
18:42:45 <ajax> cwickert: check the comment numbers carefully.  if you see comment 1 and then comment 3, there's a private comment 2.
18:42:50 <mjg59> Unless you look closely, there's nothing to tell you
18:43:17 <pjones> mjg59: also there's a social problem here - rh employees who contribute to rhel have a fairly strong /habit/ of marking comments private
18:43:29 <pjones> mjg59: which means it bleeds into fedora bugs by accident
18:43:35 <cwickert> 3. ok, maybe I didn't notice. This is something that must change ASAP, at least for Fedora, not for RH bugs
18:43:51 <pjones> it might be able to fix this in the bugzilla code, of course
18:43:58 <jforbes> I know that adamw tried to remind people not to use private comments in Fedora bugs over that one as well.  It is a matter of changing some internal RH culture though, and it takes time and multiple reminders sometimes
18:44:24 <pjones> make private /comments/ a per-product option
18:44:25 <mjg59> Anyway. My answer to [3] ends up being something like: We should work to improve the Fedora social atmosphere to the point where public discussions are always productive and technical, which isn't the case now
18:44:26 <rjune> Private comments are fine, even required sometimes.
18:44:40 <pjones> rjune: I'm not sure that's true
18:44:52 <mjg59> Simply removing the private comments functionality wouldn't change the culture
18:44:56 <jforbes> rjune: not for Fedora bugs in my opinion
18:44:57 <ajax> mjg59: you mean have fedora-devel-list be a pleasant read?  yes, that would be lovely.
18:45:03 <pjones> rjune: certainly some things need to be private, but I'm not sure the granularity needs to be that small.
18:45:49 <pjones> rjune: is there a use case /other/ than embargoed updates?
18:45:51 <cwickert> 3. I don't think that we can address social problems on a technical level. Of course we can forbid private comments for Fedora bugs, but this does not fix the underlying problem that the developers seem to have with the open nature of Fedora. I said it before and I say it again: the attitude of some people @rh needs to change
18:46:04 <rjune> to use a private comment in bugzilla?
18:46:18 <pjones> cwickert: I don't think many people have the attitude you're projecting here
18:46:53 <MooDoo> ok all we could spend hours on this one....so
18:47:02 <mjg59> cwickert: To clarify - do you believe that it should not be possible for me to discuss Fedora issues directly with ajax (who, uh, lives in the same house as me)?
18:47:07 <MooDoo> QUESTION 4. <@inode0> <Question> Speaking of workflow, how is the FESCo workflow?
18:47:25 <ajax> 4: i have no idea how the workflow is.  i'm not on it yet.
18:47:42 <cwickert> 3. pjones: but some have and even some are too much. If the desktop sig makes decisions without public discussion because they are sitting in the same room, something it utterly going wrong
18:47:45 <pjones> I don't have any idea; I haven't historically often participated in FESCo's workings, and when I have it's been as a non-member.
18:47:45 <jforbes> pjones: even for embargoed, keep a bug private until embargo is lifted, then make it public.  Though I suppose you might want reproducers private.
18:47:50 <mjg59> [4] The FESCo workflow currently seems to be "Spend 20 minutes arguing about a feature that isn't understood by several of the FESCo members"
18:47:51 <rjune> 4. I'm not sure what the workflow is, I'm not involved in FESCo yet. is there a specific issue you have?
18:48:01 <mjg59> I think the multiple failures there should be obvious
18:48:15 <pjones> jforbes: that's a good case for "clone it to a public bug, and edit while you do so"
18:48:22 <jforbes> pjones: agreed
18:48:42 <ajax> i think we've been asked to move on from question three. (not that you're wrong)
18:49:00 <cwickert> 4. I don't think there is such a thing like "the FESCo workflow". different problems require different workflows
18:49:56 <mjg59> I think the current feature process involves FESCo in unhelpful ways, where their only real recourse is to fail to vote in favour of a feature - which then *lands in the distribution anyway*, we just don't talk about it as much
18:49:56 <pjones> ajax: yeah, that's why I answered the new question and moved back to the more interesting one ;)
18:50:10 <cwickert> mjg59: +1
18:50:12 <jforbes> 4. I have only seen the workflow from watching the meetings, and not as a FESCo member, so it is hard to answer
18:50:17 <mjg59> What's the point in spending so long arguing when there's no real power?
18:50:18 <pjones> mjg59: the alternate recourse is to agree to features that never make it in ;)
18:51:04 <mjg59> Either FESCo's role should be expanded to the point where they can force rollbacks of packages (which I disagree with), or their involvement with the feature process should basically be removed
18:51:32 <ajax> again, i think there's a tension here between fedora-project and fedora-product.  which one is fesco supposed to be steering the engineering of?
18:51:46 <mjg59> The rest of FESCo's responsibilities seem to be sensible and handled well
18:52:20 <ajax> if it's the product then the feature process is merely ineffectual.  if it's the project then the feature process is actively out of scope.
18:52:24 <pjones> As a potential FESCo member, I find the idea of fesco reverting package changes terrifying ;)
18:52:48 <jforbes> mjg59: The Feature process perhaps needs some tuning, but there is value in reviewing features because it puts someone other than the developer/packagers perspective on it, or might be a good reminder of things that need to be done and weren't
18:52:49 <mjg59> Yeah. Like I said, it shouldn't be FESCO's role to attempt to stop people contributing to Fedora.
18:52:50 <pjones> ajax: I would think that the product falls under the umbrella of the project, so it's in scope, but possibly micro-managing.
18:53:11 <MooDoo> as we don't currently have anymore questions, i've been asked to reask number one which has been corrected for clarity
18:53:32 <MooDoo> QUESTION 1 < EvilBob> <Question 1 corrected for clarity> Should we look at perhaps skipping a release in the future just to clean things up in the release process not the software? I know there was a thread topic like this on the -devel list I did not read the thread however, I assume it was about fixing the Fedora Product, software and "Stabilization." We keep pushing the 6 month release schedule, could the extra time
18:54:20 <ajax> 1: to be clear, the idea is "skip a release to fix the process"?  i don't think that'll work at all unless you disable builds to rawhide.
18:54:30 <jforbes> I don't think that skipping a release will clean up the release process... If you want to improve the process, you have to do it by doing a release, and keeping what worked well, tuning what did not for the next cycle
18:54:31 <pjones> I'm not sure that's more clear.
18:54:32 <MooDoo> sorry missed this part at the end --- 6 month timed release regularly from that point on?
18:54:36 <pjones> see ajax's question
18:54:40 <rjune> 1. I'm not in favor of skipping a release.
18:55:16 <cwickert> 1. me ether
18:55:28 <rjune> 1. However, making those goals part of the release goals would be something I would be amenable to. I acknowledge that drops the delta in releases, but helps resolve some of the problems you have.
18:55:37 <pjones> MooDoo: you missed " could the extra time once in a while allow us to meet that" between the two statements.
18:56:25 <pjones> personally, I think we're too religious about the 6 month schedule.  We don't want to be debian and have no defined schedule at all, but I think treating 6 months as a holy cow has served us pretty poorly.
18:56:25 <mjg59> I'll repeat that if our process doesn't currently give us enough time to do everything we want, skipping a release (ie, basically saying "This release cycle goes to 12 months") doesn't fix that
18:56:31 <jforbes> It should just be a part of the release process to review the previos release, and adjust based on those results
18:56:35 <ajax> 1: i don't think skipping a timed solves a problem fedora is having.  it can solve problems, but i don't think they're problems we're experiencing.
18:56:43 <ajax> s/timed/& release/
18:57:02 <cwickert> pjones: even Debian switches to a defined schedule of 2 years now
18:57:19 <mjg59> cwickert: We'll see how that works out for them
18:57:42 <pjones> cwickert: fair enough
18:58:06 <mjg59> Debian's "2 year schedule" isn't a "We will release 730 days after our previous release" schedule
18:58:24 <mjg59> Whereas our 6 month schedule does aim for as close to 6 months as possible
18:58:32 <mjg59> The two aren't really comparable
18:58:33 <cwickert> 1. right. For Fedora, I don't mind one or two weeks extra, but we should try to keep the 6 months cycle
18:58:58 <pjones> right.  I think that's putting the cart before the horse
18:59:13 <pjones> the old debian schedule, which we tried to avoid when we came up with the 6-month schedule in the first place, was "go until it's done"
18:59:37 <pjones> the 6 month schedule is "screw it, we've got to do releases sometimes or we'll have all of their problems, so do it every 6 months whether it's really ready or not"
18:59:53 <rjune> Which would work ok if there were clear, defined goals in the first place.
18:59:58 <pjones> an ideal process would have us figuring out what's going in beforehand, and making a schedule that seems halfway reasonable.
19:00:08 <pjones> (plausibly using 6-months as a guideline)
19:00:23 <rjune> Or deciding what can be implemented in 6 months.
19:00:54 <pjones> yes
19:01:29 <rjune> which really is how things should be done. We ship in 183 days. what can we do in that timeframe
19:01:44 <ajax> 1: i think slip is inevitable. but: that we need the six month signposts; that we need more and better postmortems about what went wrong in each release from a process perspective; and a development workflow that makes it feasible to defer features to the next release if they're going to miss.
19:01:46 <cwickert> the question is: can we decide what can't be done within this 6 months? we should always try, but when a feature fails, we must have a better continuity plan
19:02:03 <jforbes> There is wiggle room in the release cycle to fix blocker bugs, so we are not too strict in the policy for our own good.
19:02:25 <ajax> 1: NFR, for example, makes deferral easier.
19:02:34 <rjune> cwickert, must have goals, would like to have goals, and not in this release. each tagged so we know what can be cut if needed, or added if we have extra time.
19:03:00 <cwickert> right, taggs might help us with long term goals
19:03:54 <rjune> Unfortunately, as brought up last meeting, things like docs don't bother the people that can really write them, and the people that can't really need them.
19:04:11 <MooDoo> As were coming up for the hour and there are no more questions, I'd like to wrap up this townhall by asking all of you to give a final reason why you should be elected.
19:04:16 * inode0 would like to take a minute before we end to thank the candidates in this town hall as well as the earlier town halls for giving us their time and answering our questions - a big thanks to MooDoo for his excellent job moderating today as well
19:04:38 <mjg59> Because I can dislocate my thumb at will
19:05:33 <jforbes> I should be elected because I am genuinely interested in working with the community to improve the development of Fedora as a distribution that developers can be proud of, and users can trust.
19:05:44 <rjune> I can beat aliens at mario kart.
19:06:08 <pjones> jforbes: we're not too strict in enforcement; we may still be too strict in the policy
19:06:13 <MooDoo> I would also like to thank all the candidates :) And good luck for the vote. #fedora-townhall-public for any follow on discussion.
19:06:17 <mjg59> More seriously: Because FESCo should be made up of people who can make sound technical judgements on a wide range of subjects, and I can do that
19:06:22 <jforbes> pjones: I can agree there
19:06:24 <ajax> elect me because i'm charming and handsome.  and because i've dealt with enough bad process to have some good ideas on how to fix it.
19:06:46 <pjones> I should be elected because all the cool kids are electing me?
19:07:08 <pjones> more seriously, you all know me and know that I work hard on fedora, and I'm often even pointing in the right direction ;)
19:07:19 <cwickert> Voting me is a vote for the alternative desktops and for making Fedora more modular. Let's cut the dependency bloat so all desktops can become first class citizens
19:07:42 <rjune> I will work on smoothing out some of the traditionally, left over bits.
19:08:24 <rjune> I have not used only one OS, and can bring ideas and experience from a wide variety of sources
19:08:50 <MooDoo> ok thanks once again all.
19:08:53 <jforbes> rjune: just don't bring the code unless you know where it came from :)
19:09:03 <MooDoo> #endmeeting