22:00:37 <delhage> #startmeeting FESCo-Town-Hall-2009-12-01
22:00:37 <zodbot> Meeting started Tue Dec  1 22:00:37 2009 UTC.  The chair is delhage. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
22:00:58 <delhage> #meetingname FESCo-Town-Hall-2009-12-01
22:00:58 <zodbot> The meeting name has been set to 'fesco-town-hall-2009-12-01'
22:01:36 <delhage> Welcome to the first townhall meeting for FESCo candidates
22:01:57 <delhage> it looks like most candidates are here
22:02:30 <delhage> a clarification: this meeting is for FESCo candidates, not Fedora Project Board
22:03:32 <delhage> I'd like to point everyone to http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations and also ask each candidate to make a short introduction of themselves
22:04:28 <delhage> As always folks are free to ask questions over in #fedora-townhall-public and I will queue them up and ask them
22:04:48 <delhage> who would like to start?
22:04:56 <jforbes> I can start
22:05:07 <ajax> hi, i'm ajax, and i work on X despite my better judgement.
22:05:18 <delhage> go ahead
22:05:51 <jforbes> I am Justin Forbes, currently working on Virtualization in Fedora, previously worked on the port to x86_64 in the FC1/2 timeframe
22:06:07 <pjones> Hi, I'm Peter, and I'm an addict.
22:06:11 <pjones> Oh wait, wrong meeting.
22:06:16 <mjg59> I'm Matthew Garrett, and I make laptops work
22:06:34 * cwickert is the nick of Christoph Wickert and he is a long time fedora contributor that works as packager, packager sponsor, ambassador, artist, translator, ....  but I focus on the desktops such as Xfce and LXDE
22:06:48 <pjones> I'm Peter Jones, I do many things.
22:07:30 <rsc> I'm Robert Scheck (robert), Fedora Packager since June 2006, in the meantime I got provenpackager to assist other contributors with their packages and to help where packaging help is needed. Beside of the technical work, I'm Fedora Ambassador and Fedora Mentor.
22:07:36 <rjune> My name is Richard June, I have maintained a number of packages back around fc2 - fc4, I wrote a DHCP configuration tool, and am a bugzapper
22:08:25 <delhage> thank you, it looks like all candidates are present and accounted for
22:08:41 <mjg59> ajax and I probably have to leave pretty much at 6 sharp
22:08:41 <delhage> so lets start with the first question:
22:09:02 <mjg59> (23:00 UTC)
22:09:22 <delhage> 1. randomuser: I have had problems with video drivers recently, and discovered that graphics accelerator drivers and functionality are a common issue on both the forums and irc
22:09:29 <delhage> chats. What measures will you, as a candidate, take to encourage driver development in the fedora project and move towards out of the box functionality?
22:09:34 <delhage> oops
22:09:40 <delhage> is that readable?
22:09:42 <rjune> yes
22:10:01 <ajax> well, i work on that for my day job, so... i guess i'll keep doing that?
22:10:02 <delhage> also: "How would you rate this issue as a priority?"
22:10:42 <mjg59> I'm not clear on how the question relates to FESCo?
22:11:38 <mjg59> It's obviously important that our graphics work, but that's already a high priority for the project
22:12:14 <jforbes> It is.  I think there are 2 issues there.  First the feature set for some drivers does not match the closed source drivers.  Features are being added quickly, and that is a good thing, but until documentation is available for some of the cards, this is going to be a long haul.  The second part is more interesting, particularly to FESCo.  I think the majority of the discussion in forums and IRC has been around stability of what i
22:12:16 <pjones> I'm with mjg59 /and/ ajax here - this isn't really an issue for FESCo.  It is an issue for ajax.
22:12:34 <rjune> heh
22:12:37 <cwickert> the user who asked that claims that nouveau is "an unacceptable solution". I cannot subscribe to this POV, I love the nouveau driver. I worked out of the box on my machine and does things that not even the proprietary driver manages to do. this shows that we are doing pretty well actually in development of FOSS drivers
22:12:37 <rsc> I'm not seeing myself really able to help there - with or without being part of FESCo. Driver development is IMHO kernel or Xorg related and there are many chipsets and graphics cards out there to get them all perfect supported. And if I need to think about proprietary hardware, it's a nearly unsolvable task.
22:13:03 <mjg59> The only thing that I could really see FESCo doing here is adopting a policy on whether we ship multiple drivers for a given piece of hardware or not
22:13:23 <pjones> mjg59: right, but I'd much rather leave that up to subject matter experts
22:13:25 <mjg59> There are some people who don't test radeon or KMS because radeonhd works for them, for example
22:13:43 <ajax> i want to note that it's sort of a advance-2-retreat-1 thing.  we have made real advances in out-of-the-box support, but we're also exploding the world to do so. some things will regress.
22:14:00 <pjones> the only reason FESCo need get involved is if, for some reason, the people whose responsibility that is are doing something /blatently/ harmful.
22:14:04 <cwickert> Fedora needs to works with upstream and follow their paths. this is one of the reasins why I think we must encourage and help upstream developers to maintain their code in Fedora. co-maintainance must be easier for them
22:14:07 <mjg59> But any FESCo policy there should (as pjones says) be guided by the experts on the subject
22:14:09 <jforbes> mjg59: I think we can put a bit more emphasis on QA in general, and that will help address a lot fo the issues we are seeing on forums and IRC.
22:14:12 <ajax> i think there's some work we could do to make test fixes easier, since there's more kernel interdependency these days, but that's about it.
22:14:39 <pjones> jforbes: sure, I'm just not sure how that actually relates to the question ;)
22:15:00 <mjg59> jforbes: /win 24
22:15:03 <mjg59> Oops.
22:15:20 <ajax> and that's really just adding a dist-f12-graphics-candidate tag.  which has its own problems since repos are expensive, but.  that's where i'd start.
22:15:50 <mjg59> (next question?)
22:17:29 <delhage> 2. EvilBob: "How can the Fedora project work with upstream differently to be sure we have information about changes to the user experience. The PackageKit or Policykit change being the example."
22:18:10 <pjones> I think the question here is sortof the cart pulling the horse.
22:18:10 <mjg59> I think this specific example is a poor one
22:18:29 <mjg59> Fedora is (to all intents and purposes) upstream for PackageKit and PolicyKit
22:18:29 <rsc> Well, at PackageKit or PolicyKit, Fedora (or a Fedora contributor) is the upstream...
22:18:33 <pjones> The question really is: what could FESCo (and presumably the Board as well) do to avoid the problem we had with PK and PK.
22:18:57 <ajax> i think that example is overblown. that change was in rawhide for months without anyone noticing. this sort of implies that the people who cared, were not running rawhide, or were not paying attention.
22:19:07 <pjones> making sure "the fedora project" has the information isn't really the solution, since obviously all of the upstream developers involved were also fedora contributors
22:19:21 <pjones> Which is to say, the fedora project had plenty of information.  But that's not the issue.
22:19:27 <mjg59> ajax: Well, it still asked for passwords for unsigned packages
22:19:38 <mjg59> ajax: Which meant that the change wasn't visible for the vast majority of rawhide
22:19:52 <pjones> mjg59: yeah, getting the change in fairly late isn't the best
22:19:57 <ajax> mjg59: yeah, fair.  still, i'll point to another example of gnome-window-properties moving to control-center-extras
22:20:19 <mjg59> At some point we need to trust package maintainers
22:20:28 <cwickert> I think in the case of packagekit we simply failed. the developer claims that "he has discussed this in public 9 months ago", but unfortunately the discussion happened on a non-fedora mailing lost and involved only two people and 9 email. the other one disagreed, so this should have been clear that this is a no-go. obviously developer thinks different, but I found this articular developer very stressful and ignorant.
22:20:32 <pjones> but a bigger issue is that we don't really have any guidelines for what is and is not acceptable in terms of users being in roles that allow them privileges, and which of those require what passwords.
22:20:42 <cwickert> mjg59: what if $developer is maintainer?
22:20:53 <pjones> so in a way we're waiting for upstream to decide how that should work and then having a flamewar if they pick wrong.
22:20:56 <ajax> pjones: more than that, we don't have guidelines for the user experience, period.
22:20:56 <mjg59> cwickert: Then we're clearly trusting them all the more
22:21:03 <rjune> What we did at my last employer was write scripts to validate behaviour. but that only tests for known things, not against surprises.
22:21:05 <pjones> what we can do to mitigate this problem is to make more clear guidelines.
22:21:07 <pjones> ajax: indeed.
22:21:18 <mjg59> Right. This is a procedural rather than technical issue
22:21:20 <delhage> EvilBob like to point out that the PK/PK was only an example and really the question is how to prevent anything from being undocumented in our main (default) packages?
22:21:32 <cwickert> mjg59: but this case has proven us wrong, one more reasons for co-maintainers for every (!) package
22:21:33 <mjg59> And I'd argue that it's actually more of a *cultural* thing than a procedural one
22:21:46 <cwickert> mjg59: +1
22:22:07 <pjones> delhage: again, not the real problem - there's a lot of PolicyKit documentation.  You can't actually expect developers to write documentation for every decision they make -- there are *far* too many decisions.
22:22:21 <mjg59> Part of that is that any discussion of changing away from the status quo tends to result in flamewars
22:22:24 <ajax> i hate to be glib, but the way to keep things from going undocumented or unnoticed is to have someone who writes the doc.
22:22:25 <pjones> You can, however, (not to be too subtle) make guidelines to help them make those decisions ;)
22:22:29 <jforbes> I think we need to be a bit more active in making rawhide look like a release once we start releasing ISOs, but otherwise we need to encourage more sanity in packaging.  Big changes in default behavior should be testable and at least mentioned to the community so people know what to test and can look at the impacts
22:22:33 <rjune> As in fedora has a culture of broad sweeping changes without telling anyone?
22:23:06 <mjg59> One of the strengths of Fedora is that the people with the ability to do things are allowed to just do them
22:23:12 <rsc> jforbes: that means our alpha/beta should be more usable and less broken than in the past? But how to achieve that?
22:23:13 <ajax> jforbes: i'd take that further and say that rawhide needs to be more like a consumable release all the time.
22:23:20 <mjg59> That has obvious costs as well
22:23:30 <rjune> mjg59, I don't think that's a strength for a release though.
22:23:38 <pjones> Part of the problem is also the structure of our schedule.  For various reasons, many packagers really are encouraged to get things in as late as they possibly can, even though we don't say that out loud.
22:23:50 <pjones> that results in the most important changes getting the least amount of testing.
22:24:03 <rsc> ajax: if Rawhide needs to be more like a consumable release, where is then the place to break things?
22:24:21 <mjg59> rsc: On your own machine
22:24:24 <pjones> rsc: in theory, "upstream", although that's obviously not entirely practical.
22:24:25 <ajax> rsc: i think you're constructing a false dichotomy?
22:24:32 <cwickert> not really mjg59
22:24:41 <mjg59> Hypothetical:
22:24:42 <rjune> ajax, I thought rawhide was an "alpha" to get some basic testing of packagefs before going into release mode
22:24:52 <jforbes> rsc: We can achieve it in maintaining the infrastructure similar to a release, signed packages, etc.  Sure things might be broken, that is why we have test releases.  Though realistically a packager shouldn't build something in koji that they haven't at least tested somewhat
22:24:55 <mjg59> You upload a package. The next day you're hit by a bus and can't use a keyboard until after the release.
22:24:59 <rjune> gah, packages.
22:25:01 <pjones> ajax has a good point; there's a difference between /structuring/ it as a consumable release earlier and saying "oh, you can't break anything, this has to always be usable"
22:25:03 <mjg59> Would you be happy with that package ending up in the release?
22:25:16 <pjones> rjune: no, it's not an alpha - it's a working tree.  there's a big difference.
22:25:17 <mjg59> If yes: Upload the package
22:25:17 <delhage> I think we might not get much further in this debate, shall we move on to another question?
22:25:22 <mjg59> If no: Don't upload the package
22:25:46 <cwickert> if I'm afraid of the all the time, I won't make it thgough the feature process
22:26:04 <ajax> parting shot: many of the mechanical reasons for rawhide to not be consumable (broken deps for one) are addressable through improvements to the RCM tools.
22:26:08 <mjg59> (I think the question of "What should rawhide be" is an interesting one, and someone should bring that up)
22:26:21 <cwickert> we need to upload a beta of foo in order to be in time for feature freeze, but we don't want that beta in the release
22:26:24 <ajax> the less of those mechanical problems we have the more time we have to notice the subtle behavioural things.
22:26:27 <ajax> (done now)
22:26:29 <pjones> mjg59: yes.
22:26:35 <pjones> delhage: sure, go ahead.
22:27:06 <jforbes> cwickert: I think the feature process itself is a little odd in that regard
22:27:10 <delhage> 3. tcpip4000 asks: "What are important points to stress toward F13?"
22:27:56 <mjg59> A lack of awkward surprises?
22:28:01 <rjune> LOL
22:28:05 <delhage> hehe
22:28:08 <jforbes> I think QA and testing are some of the most important points to stress, it needs to be a part of the community culture.
22:28:26 <mjg59> But seriously. By and large I think F12 has ended up being an excellent release
22:28:35 <rjune> I would like to see more seamlessness among the components.
22:28:43 <mjg59> The majority of our user-visible bugs are *upstream* bugs
22:29:01 <rjune> It would be nice to help fix some of those bugs.
22:29:08 <mjg59> That's not something we can rectify without magically finding more developers
22:29:15 <rjune> this, is true.
22:29:17 <mjg59> And then getting those develoeprs up to speed
22:29:34 <rsc> We could try to stress the testing of anaconda more to help to get rid of bugs before the release.
22:29:37 <rjune> though I don't think finding developers is a magical thing
22:29:46 <jforbes> mjg59: sure, but we can do more to make sure those bugs are exposed early, and either well documented, worked around, or fixed.
22:29:49 <rjune> rsc, actually, that was part of the bugzapper meeting earlier.
22:29:52 <pjones> This is the pie-in-the-sky question, right?  I think it'd be good to get f-d-l to be more participatory and less flamy.
22:29:56 <ajax> from an engineering process perspective: autoqa and all it implies.  testable consumable images every day.  automated tests for as much baseline functionality as we can get.  performance improvements to koji and the rest of the toolchain to make building new bits faster and easier.
22:29:58 <mjg59> jforbes: You make it sound like people ignore bugs
22:30:29 <pjones> which means that a) fedora developers who are also upstream developers should feel more free - and more responsible - to bring things up there.
22:30:40 <pjones> don't really have a "b)" there, actually.
22:30:49 <rjune> mjg59, I think that some bugs probably get... put on the back burner because they're not considered important
22:30:53 <jforbes> mjg59: they are easy to ignore when no one has reported them.  I don't think we ignore bugs that people have reported as a rule (I spent all morning on triage for virt), but we need to emphasize testing so that bugs are found and reported
22:31:05 <pjones> definitely a strong focus on QA would also be very helpful, and a focus on getting things testable earlier in our release cycle.
22:31:21 <rsc> rjune: that's possible, but it could or should be part of the FESCo tasks, too. It's an essential tool for Fedora.
22:31:26 <mjg59> But I agree with ajax. autoqa is important because it helps avoid a number of the stupid bugs that consume people's time
22:31:50 <mjg59> Hm. Let me try to phrase this as I want to.
22:32:04 <rjune> rsc, yes, and I may wind up triager for it. have to see if anybody responds to the job posting
22:32:08 <pjones> a large number of our gigantic pile of 0-day updates are the result of insufficient eyes, be they human or mechanical, resulting from a) insufficient automation and b) changes coming in late.
22:32:23 <ajax> in terms of culture: i'd like the tone of discussion to be more like one of cooperation than one of confrontation.
22:32:24 <mjg59> The most important thing for F13 is to do everything we can to avoid introducing bugs that aren't upstream, in order to give us more time and resources to fix bugs that *are* upstream
22:32:34 <pjones> another thing which will help with some things (but hurt some others) is to try and decouple our release from upstream releases as much as possible.
22:32:43 <pjones> (yes, I'm advocating for the opposite of what shuttleworth is arguing ;)
22:33:42 <pjones> that reduces the pressure to slip things in at the last minute, which results an both a more smooth progression of features, but more importantly more isolation, so they can be tested independently.
22:33:44 <cwickert> pjones: really? I think many of our 0day updates are sign of the rapid progress. I did ~30 updates during the freeze and the ony 0day update that was left was a security fix that came in after F12 was gold
22:34:06 <mjg59> Is rapid progress a good thing during a freeze?
22:34:07 <ajax> part of that cooperation culture would be both: developers better articulating their visions for the future; and consumers better articulating _how_ they consume fedora so we know where in the middle we're trying to meet.
22:34:15 <delhage> ok, thanks for your answers, next question coming up...
22:34:20 <pjones> cwickert: I think that's also true, but we've both used ambiguous terms - "many" and "a large number".  There's not necessarily mutual exclusion ;)
22:34:21 <rjune> cwickert, rapid progress or bugs that should have been caught?
22:34:33 <cwickert> mjg59: no it's not, but you cannot stop upstream
22:34:36 <jforbes> pjones: that is an interesting point.. Certainly in kernel I think F12 had a benefit in going with .31 which was released early in the development cycle.  A lot more time was spent eyeballing bugs with .31 vs. trying to stabalize a moving target
22:35:10 <cwickert> rjune: I managed to fix all bug in my packages, the only remaining ones were new versions from upstream
22:35:26 <delhage> 4. EvilBob: "should Developers in general be the Package owner for their product."
22:35:29 <rjune> cwickert, congrats.
22:35:32 <rjune> I don't think so.
22:35:47 <cwickert> they should have at least one comaintainer
22:35:59 <mjg59> comaintainers aren't a magic bullet
22:36:00 <cwickert> packagekit is the reason why I think so
22:36:01 <rjune> I would advocate having a second person doing the packaging.
22:36:10 <ajax> as a developer: exactly zero people have ever offered to comaintain any X package.  i would be _thrilled_ if they did.
22:36:11 <cwickert> +1
22:36:13 <rjune> mjg59, no, but it does help keep stupid mistakes.
22:36:23 <rsc> cwickert: +1
22:36:31 <mjg59> So, I'll admit that this is a corner case, but:
22:36:34 <ajax> but in the meantime, someone has to own it...
22:36:40 <mjg59> Would you want non-kernel develoeprs packaging the kernel?
22:36:54 <cwickert> and glibc of course ;)
22:37:05 <pjones> I think comaintainers would be nice, but they're no panacea
22:37:08 <mjg59> A lot of the code we ship is complicated
22:37:20 <mjg59> In some cases the upstream developer may be the only person who understands it properly
22:37:23 <jforbes> The advantage to having someone else package your work is that another set of eyes is looking at everything. The disadvantage is that a packager may be slower to react to issues than the developers.
22:37:35 <delhage> I suspect many of the questions tonight are a reaction to the packagekit debacle
22:37:39 <mjg59> An extra set of eyes wouldn't have helped the Packagekit case
22:37:39 <rjune> I would rather see a kernel dev packaging X and an X dev packaging the kernel than the other way around.
22:37:53 <cwickert> mjg59: why not?
22:37:58 <rjune> mjg59, if only one person understands the code, then it's too complex.
22:38:05 <ajax> back when we had a cvsextras bit, instead of a provenpackager bit, i had cvsextras+ on _every_ X package.  i could probably count the number of non-maintainer uploads during that period on one hand.
22:38:06 <pjones> as an anaconda developer, I don't like the idea of somebody who's a comaintainer but /not/ an anaconda developer adding patches to fix something - likely it'd just mean an intermediate version with a patch that's unlike the next version, which has /negative/ implications for testing.
22:38:10 <mjg59> Because the only other person with the skillset to handle PackageKit is davidz
22:38:12 <rsc> Ideally it should be a good mixture of maintainer and comaintainer where one of those can be the developer of course.
22:38:30 <mjg59> Who is the one who made the change in Policykit that required that Packagekit change its policy
22:38:35 <cwickert> mjg59: but ven david disagreed to the no password thing
22:38:39 <pjones> whereas with a package that's not as closely in lock-step with Fedora, that's not as much a concern.
22:39:11 <jforbes> Ideally it would be nice if we had more eyes on everything, but realistically we cannot enfore such a policy and have any sort of desireable outcome.
22:39:14 <delhage> EvilBob would like to make a followup comment: "my thinking on this is someone else being the owner would be a buffer of sorts, and someone else putting their neck on the line to look at major changes, good or bad"
22:39:33 <pjones> rjune: yes, if only one person understands the code it's too complex (or simply very large and without enough developers), but in general I don't think we can expect that a comaintainer necessarily understands the code.
22:39:43 <mjg59> An extra set of eyes is helpful in some cases, but most of the cases where it's likely to add useful extra coverage are ones where an error doesn't harm us badly
22:39:44 <rjune> I don't think that's a requirement either.
22:39:50 <pjones> rjune: that'd be a nice world to live in where all comaintainers are experts on all code they package, but I don't think it's the one we live in.
22:40:08 <ajax> i think in the PK case, the "extra neck on the line" would just mean we'd be blaming two people.
22:40:09 <rjune> any patches to the package should be documented well enough that the packager can understand it.
22:40:11 <mjg59> In a nutshell, if we're relying on comaintainers to protect us then we're already lost
22:40:21 <pjones> (I'm reasonably sure I don't understand all the code I'm a package maintainer for, by virtue of not having read it all, and having forgotten some of it - even parts that I've written.)
22:40:27 <rjune> and if the package has to patch it, then they can go back to the developer and say, hey, I have this problem.
22:40:29 <ajax> i'm not sure blaming more people would be an improvement.
22:40:34 <rjune> ajax, +1 on that
22:40:55 <ajax> like i said, if someone wants to help me out with active ownership of X stuff, please, please, please, i will buy you so much beer.
22:41:03 <cwickert> ajax: I don't think we would blame more people. it was a one-man-decision, so even the other maintainer would have disagreed
22:41:04 <rjune> LOL
22:41:06 <pjones> rjune: that doesn't really help with some packages though - glibc, gcc, kernel, anaconda, Xorg, etc., where we're basically shipping upstream releases.
22:41:19 <mjg59> Other than the PK case, does anyone have an example of a real issue that they think a comaintainer would have helped with?
22:41:25 <pjones> cwickert: the assumption that a comaintainer would have /noticed/ is a bad one.
22:41:25 <ajax> but i've had no volunteers in four years.  i am left to assume maintainers are a scarce resource.
22:41:31 <jforbes> pjones: I agree, you wouldn't want someone who doesnt understand the code or work on it as a packager, but for many packages we do have multiple developers maintaining the package
22:41:36 <rjune> pjones, if those are basically untouched upstream releases, then the package has to know even less coding.
22:41:42 <pjones> jforbes: sure.
22:41:58 <pjones> rjune: right, but your example is one of these cases
22:42:13 <ajax> cwickert: yeah, i'm gonna say a pk comaintainer would probably not have noticed that change.
22:42:18 <pjones> rjune: you're saying a comaintainer would have helped, but it's unlikely a comaintainer would /ever/ see the change unless she's also an upstream developer.
22:42:24 <mjg59> rjune: Cases where a package doesn't need a coder as a maintainer are generally the packages that don't cause nasty surprises late in the release
22:42:26 <cwickert> pjones: agreed, but I live in a perfect world where there is actually communication between the two maintainers. works pretty well for what I do with nirik or others
22:42:31 <delhage> I hate to be the sour puss but could you focus more on addressing the people asking the questions than discussing among yourselves? We simply haven't got the time in this forum for long discussions
22:42:40 <delhage> next question coming up
22:42:41 <ajax> but this is all in the subjunctive, so we may as well be discussing the weather on the moon.
22:42:49 <pjones> at best a comaintainer would be likely to have fixed the problem earlier - by say 18 hours, max.
22:42:59 <cwickert> right
22:42:59 <pjones> ajax: I hear it's cold there.
22:43:08 <delhage> 5. tcpip4000: "Where should FESco put more effort to attract community members and involve the actual registered ones in a more practical manner?"
22:43:30 <pjones> delhage: that sounds like a question for the Board, not the Engineering Steering Committee.
22:43:34 <cwickert> making the feature process easier
22:43:57 <pjones> I do have to agree with cwickert though; I think the feature process is /terrible/.
22:43:58 <rjune> is attracting members a marketing question?
22:43:58 <delhage> is that everyones thought on the subject?
22:44:01 <ajax> pjones: kinda?  i think we're doing a poor job of turning packagers into developers, or attracting new developers period.
22:44:13 <ajax> but that's sort of true for every upstream project ever too.
22:44:13 <jforbes> I think the best way to attract more community members is to put out the best release possible, and make sure we are responsive to our community
22:44:27 <mjg59> I don't think FESCo should do anything to attract community members. But I think FESCo does have a role in ensuring that community members aren't discouraged.
22:44:44 <pjones> mjg59: that's a good way to put it.
22:44:46 <ajax> the best i've been able to do in X to attract and keep developers is put out a list of projects and make sure to talk to the people who want to work on them.
22:45:06 <delhage> ok, lets leave it at that and take the next question:
22:45:11 <cwickert> I found the feature process very hard, we had to fight for 3 extra days because the parrot release we needed for packaging rakudo was just released 3 days before the freeze. I actually found fesco members voting on features while they didn't bother to read the feature page
22:45:22 <mjg59> tcpip4000: So, like the others, I think the feature process in its current form doesn't do a great job of avoiding discouragement
22:45:32 <delhage> 6. quaid: "Would you support as a FESCo member making it mandatory that package maintainers either contribute to the release notes or justify why they haven't? In particular, Feature owners, but the will-document-in-release-notes % from our contributors is abysmal"
22:45:43 <mjg59> If a FESCo meeting can frustrate people who are paid to work on things, how can we expect volunteers to enjoy it?
22:45:46 <pjones> cwickert: I find that the idea of FESCo "voting on features" mostly is one of many incentives for people to ignore the feature process.
22:46:06 <cwickert> right pjones
22:46:09 <ajax> to quaid's question: we sure do have a lot of package maintainers...
22:46:21 <pjones> quaid, I think that's an interesting question, but not entirely practicable.  We'd have release notes so big nobody would read them.
22:46:36 <pjones> (of course, I'm suspicious of current claims that people read them ;)
22:46:36 <rjune> Yes, the release notes should be updated to properly reflect what's in the package
22:46:45 <ajax> not sure what the consequence of not participating in a "mandatory" process would be.
22:46:54 <jforbes> I don't think we want contributers adding to the release notes if they don't have anything important to say.  Release notes for the distribution should be concise and relevant
22:47:00 <rjune> ajax, a finger wagging probably.
22:47:11 <mjg59> I think mandating that people who don't have English as a first language write a user-readable description of the changes in their package would be an *excellent* way for FESCo to discourage contributors
22:47:24 <ajax> rjune: so it's not actually mandatory then, is my point.
22:47:25 <cwickert> I think whatever is a $feature, should be documented by $feature-owner in the release notes. he knows best
22:47:29 <pjones> so on the one hand, the "or justify" part sounds nice, but what's the recourse?  If you don't tell us why you didn't change the release notes to mention the fact that your package got rebuilt twice for gcc updates, we make you stand in the corner?
22:47:52 <pjones> quaid: I think the idea there is good, but in terms of a public policy, a little more thought needs to be put into it.
22:47:53 <mjg59> So, no. I think making this kind of thing mandatory is not the best way to encourage our developers to actually develop things.
22:48:00 <quaid> .w 31
22:48:14 <ajax> i think the question there is "how do we get things documented" and again... it's gotta be someone _doing_ it. broadly speaking, documentation does not scratch anyone's itch, so no one does it.
22:48:30 <ajax> (yes i know quaid does it)
22:48:41 * quaid doesn't do it, fwiw
22:48:42 <rjune> documentation scratches the users' itch. unfortunately, they're the worst ones to do it in many cases, as they need it.
22:48:44 <mjg59> Right. People already view the feature process as a box-ticking exercise. Adding extra boxes doesn't improve that.
22:48:49 <pjones> ajax: well, it scratches the itch of the people who don't know $FOO.  unfortunately they're the people docs are written /for/.
22:48:54 <ajax> oh, i thought you did?  whoops.
22:49:08 <pjones> OTOH more than one person has written documentation just to learn how to use something.
22:49:25 <pjones> more of that wouldn't hurt, but it can't be the only solution, either.
22:49:35 <mjg59> Offering some sort of carrot for documentation writing sounds like a better plan
22:50:16 <delhage> are you ready for the next question?
22:50:16 <mjg59> I don't have a well-formed idea on what that carrot would be, but...
22:50:18 <jforbes> major changes in functionality *should* be documented, but I would bet a large percentage of our packages have few changes worth documenting in distro Release Notes during a given cycle
22:50:18 <ajax> yep
22:50:25 <rjune> mjg59, I can ship a bottle of wine.
22:50:29 <delhage> question from inode0:
22:50:30 <rjune> delhage, yes.
22:50:42 <delhage> Does the developer community feel a need for a declaration of "What is Fedora?" and "Who is Fedora's target audience?" Would such declarations help developers?  Would they help FESCo?
22:50:54 <mjg59> Yes
22:51:02 <mjg59> (to everything)
22:51:24 <mjg59> If Fedora is a testbed for software development, it doesn't matter if everything's horribly broken on release day
22:51:29 <ajax> what he said.
22:51:30 <jforbes> Certainly knowing the target audience is of great help in developing
22:51:33 <mjg59> If Fedora is a distribution for end-users, it matters a great deal
22:51:45 <mjg59> And knowing that has a huge impact on how you treat your uploads
22:51:47 <cwickert> I think the developer community knows what Fedora is, but we fail to tell the users sometimes
22:51:59 <rjune> Yes, but this is a marketing question to a large degree.
22:52:01 <pjones> "Who is Fedora's target audience" would help in the short term, but in the longer term we need to figure out how to make a more diverse system - which includes things like spins that broadly target disparate groups.
22:52:24 <mjg59> And as pjones implies, it's true even at the more fine-grained level
22:52:28 <pjones> having to decide (or even discuss) "who is fedora for" is one of the problems.
22:52:58 <mjg59> Whether we aim at sysadmins or home users makes a difference in what we ship
22:53:10 <rjune> and how things are designed.
22:53:19 <pjones> the solution, realized in an example, is to make it so that if you happen to hate gnome, we can ship gnome and still make fedora be "For you".
22:53:48 <mjg59> Personally? I think the idea of Fedora as showcasing the latest and greatest of free software is a great statement to make, and one that backfires horribly if when we release it nobody can even install the OS
22:54:04 <ajax> as i said in the questionnaire, the tension here is that there's a fedora project and a fedora product and they're both called fedora.  we need lots of fedora products.
22:54:05 <pjones> we can do this by improving tools and processes to make combining various package sets - or having alternatives for them - a much less painful process.  Part of that must include working with upstreams, though.
22:54:31 <mjg59> The most important thing to remember is that without users, we don't gain new developers
22:54:37 <pjones> mjg59: I'd like to think we generally do better than /that/ ;)
22:54:44 <mjg59> Without mindshare, nobody wants to work on a project
22:55:10 <pjones> sounds like time for the next question.
22:55:23 <mjg59> I have to leave in 5 minutes, btw
22:55:30 <cwickert> think of polkit. I mean, polkit 1.0 is great, but many users were disappointed be the missing graphical interface to configure authorizations. we need to communicate changes like this in oder to not disappoint our userbase
22:55:55 <delhage> we have a followup comment from quaid on the release notes question:
22:56:14 <delhage> "the people in the discussion showed an appalling lack of understanding of the release notes process"
22:56:40 <delhage> there seems to be no more questions in the queue
22:56:48 <ajax> it's true, i don't know much about it.
22:56:58 <rjune> I don't think most of us do.
22:57:08 <mjg59> The question specifically asked whether contributing to the release notes should be mandatory
22:57:08 <pjones> 1) that's not a question, 2) the people in which discussion?  do you mean #f-t's replies?  I think most of us will admit to not knowing enough about the release notes process.
22:57:14 <cwickert> I already worked on the release notes them a while back, so I know the process (if it hasn't changed in the last 2 releases)
22:57:22 <ajax> i'm... slightly skeptical that release notes get read, but that's mostly me being a cynic
22:57:29 <rjune> https://fedoraproject.org/wiki/How_to_be_a_release_notes_beat_writer and https://fedoraproject.org/wiki/Category:Documentation_beats
22:57:33 <mjg59> And I think that's not so much a question about the release notes policy, but about how volunteers work
22:57:44 <pjones> without more feedback than that, I'm not really sure how to respond.
22:57:56 <pjones> mjg59: indeed.
22:58:16 <rjune> I don't believe a response was being looked for.
22:58:17 <jforbes> I am somewhat familiar with the process, but mandatory contribution for every packager can do just as much harm.  Too much noise to weed down to meaningful release notes.
22:58:26 <mjg59> I can't really say much other than to reiterate that if we already have a number of developers who feel that the feature process is too difficult, we're not going to get more people contributing to the feature process by making them do even more
22:58:35 <delhage> there is no more questions so I'd like to wrap up by asking all of you to tell us in one sentence why you sould be elected to FESCo?
22:59:22 <mjg59> Because I understand both the distribution and the developers
22:59:54 <cwickert> because I want to make Fedora work for users *and* developers, for *everybody*, not only for Gnome and KDE users
23:00:26 <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.
23:00:44 <ajax> because i believe in engineering as a process and a discipline, and fedora could use that.
23:00:45 <pjones> Well, I think I should be elected because I've got a very long and productive history with Fedora, I have a fairly thorough understanding of what we're doing, and because of those I'm in a good position to help other developers make Fedora even better.
23:01:16 <ajax> i have a bus to catch.  thanks all.
23:01:22 * inode0 would like to thank the candidates very much for their discussion, the public for their questions, and delhage for moderating today's town hall. thanks everyone.
23:01:40 <mjg59> Thanks!
23:01:45 <rjune> I should be elected because I have been involved with fedora since release one, barring a two year hiatus using ubuntu and suse, and brought a number of packages to fedora.
23:01:48 <rjune> gah,
23:01:51 <delhage> I would also like to thank all the candidates, and it was good to see a 100% attendance, thank you all
23:01:56 <mjg59> We'll see you all again on Thursday
23:02:29 <delhage> yes, for information on the elections and upcoming townhalls, see http://fedoraproject.org/wiki/Elections
23:02:33 <delhage> thanks again
23:02:40 <delhage> #endmeeting