15:02:06 <kylem> #startmeeting FESCo Election Town Hall (2010-11-18)
15:02:06 <zodbot> Meeting started Thu Nov 18 15:02:06 2010 UTC.  The chair is kylem. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:15 <kylem> #meetingname fesco-townhall
15:02:15 <zodbot> The meeting name has been set to 'fesco-townhall'
15:02:51 <kylem> #chair mmaslano mjg59 ajax pjones jforbes cwickert sgallagh
15:02:51 <zodbot> Current chairs: ajax cwickert jforbes kylem mjg59 mmaslano pjones sgallagh
15:03:16 <pjones> this sure is a nice town hall we've got here.
15:03:40 <mjg59> Be a shame if something happened to it?
15:03:44 <kylem> Reminder: questions in #fedora-townhall-public, and i'll be acting as your moderator, please ensure your seatback and tray tables are in their upright and locked position.
15:03:56 <kylem> am i missing anyone?
15:04:04 <kylem> dramsey doesn't appear to be around.
15:04:05 <mjg59> kylem: One of the candidates?
15:04:09 <mjg59> But other than that
15:04:22 <kylem> he never replied to my emails about the meeting time and i've not seen him on irc. :<
15:04:44 <pjones> that's unfortunate.
15:06:36 <kylem> i've never done one of these before, so i'll post the questions (if we get some :) and give you all ~5 mins to answer, at which point we can branch off into further discussion, or go to the next question.
15:06:47 <pjones> sounds good.
15:06:50 <ajax> i have a pretty hard stop at 11, apologies in advance if i have to duck out
15:07:00 <kylem> i'd appreciate it if you'd prefix your answers with the question number, i'll sift through the logs to remove any babble as well.
15:07:05 <kylem> okies. let's open the flood gates.
15:07:23 <kylem> all candidates (present) ready?
15:07:28 <pjones> yep
15:07:31 * cwickert is ready
15:07:33 <kylem> ajax, np.
15:07:42 * mmaslano ready
15:08:00 <ajax> (that is to say, in one hour)
15:08:02 <mjg59> Yup
15:08:11 * sgallagh is ready
15:08:47 * jforbes pretends to be ready
15:09:13 <kylem> ok, i've not seen any questions yet, so i'll pose the first one.
15:09:51 <mjg59> Yes, but only on Tuesdays
15:10:05 <pjones> will you now?
15:10:23 <mjg59> (The prosecution rests)
15:10:37 <kylem> Q1: What do you see as the biggest hurdles we faced in the F-14 development cycle, and what can FESCo do to help ensure that we are able to cope with them over the next two cycles?
15:11:48 <pjones> 1: well, we had new the new updates policies being enacted, which put a strain on a lot of things even though it didn't really effect F-14 development directly.
15:11:58 <sgallagh> 1) We attempted to rush systemd into Fedora, despite insufficient testing. Ultimately, we were forced to withdraw it, but it could be argued that this invalidated some of our testing.
15:12:20 <pjones> we're still trying to see how effective that is, and make tweaks to make the new stuff better.
15:12:44 <pjones> sgallagh: that's a pretty good point
15:12:48 <mjg59> 1. From a Fesco point of view, I think the biggest challenge we faced was explaining why we wanted to change the way updates had been handled for years
15:12:49 <mmaslano> 1: we should find more people for testing of all new feature. That's suer
15:12:51 <sgallagh> 1) In the future, major new features as big as a change to init should probably be required to spend a cycle in rawhide.
15:13:17 <sgallagh> From beginning to branch, I mean.
15:14:02 <pjones> mjg59: not just explaining it though - also trying to make sure we got it right.
15:14:04 <cwickert> 1. As always we had not enough testers for all the alternative spins, only the desktop spin got sufficient coverage. the second problem was the updates-policy that slowed down necessary updates in F14-devel. Fesco can help by providing test plans for features and by lowering the requirements for updates in a release under developement (which we recently did)
15:14:09 <mjg59> 1. But Fedora 14 released on schedule, which is a massive achievement. I think that there were probably fewer significant problems than in any previous release
15:14:10 <jforbes> 1: I believe that making sure features are testable in time was really the biggest hurdle, systemd was the biggest example of it.  It was a major change to implement, and then back out at the last minute.
15:14:10 <pjones> which is still (obviously) up for some debate.
15:14:10 <sgallagh> 1) I also agree with mjg59 and pjones that the new updates policies required a lot of adjusting. I'm personally of the opinion that they're a step in the right direction.
15:14:20 <ajax> 1) we also had to back out a fair chunk of the gnome stack since gnome3 slipped
15:14:59 <pjones> ajax: that's something that happened, though I didn't really see it as a big challenge.  that's probably because I don't work in desktop land.
15:15:18 <ajax> 1) i think f14 was a pretty conservative release, technically.
15:15:24 <mjg59> 1. But the updates policy has also given insight into the changes that people do want, and I think a vital part of the next couple of release cycles is going to be ensuring that we can handle those appropriately - including ensuring that security fixes get released in a timely manner (ideally without skimping on testing of them), but also making it possible for people to get updated applications *if* they want them
15:15:26 <mmaslano> not all features are so problematic like systemd. We don't need policy for that
15:15:52 <kylem> OK. Thanks for your responses. Anything further to add or shall we move on?
15:16:03 <sgallagh> I do think we need a policy for non-backwards-compatible updates in a released fedora, however
15:16:49 <mjg59> 1. So from the perspective of ensuring that we don't leave the users who want more bleeding edge applications out in the cold, I think Fesco needs to put work into making that possible. But you can't build an optional bleeding edge repository without a stable base, so I think we're moving in the right direction
15:16:49 <kylem> Q2: What do you think FESCO's #1 priority / goal should be over the next year?
15:16:50 <cwickert> 1. I agree we need something like the updates policy, but we also need exceptions granted by rel-eng. If proven-testers give "proxy feedback to get this through bodhi" wichout testing, the policy must be wrong, at least for unreleased branches
15:17:35 <mjg59> 2. Pretty much as above - we need to fine tune the updates policy to make sure we're not alienating large numbers of users or developers
15:17:37 <pjones> 2. I think there's still a lot of work to be done on the updates front
15:17:38 <sgallagh> 2. Smoothing out the bumps in the stable release vision. Hands-down
15:17:48 <jforbes> 1: The updates policy for branched F14 was a bit of a hurdle because packages could  not be pushed to the tree until enough testers gave karma or 1 week had passed.  I noticed it required some prodding to get people to test and post feedback, which makes the development cycle a bit slower
15:17:51 <ajax> 2: yeah, what they said.
15:18:02 <pjones> (sounds like everybody agrees on #2)
15:18:15 <kylem> indeed. :)
15:18:29 <sgallagh> I think that qualifies as a mandate :)
15:18:31 <mjg59> 2. I think the biggest hurdle we're going to face is ensuring that testing happens. That's not a trivial problem, and we're going to need to work with the entire community to figure out how to handle it.
15:18:34 <jforbes> 2: I agree as well, I think it is the biggest priority
15:18:39 <mmaslano> 2: I believe FESCO should finish update vision, so most of developers will be happy with process. There still lot of troubles, which weren't solved - like testing of older releases, no appropriate testing, giving karma without real test-case...
15:18:49 <cwickert> 2. Make the board adjust the target audience vision, get rid of some of the governance we built up and involve more people in testing. People must empowered to implement their visions without too much red tape
15:19:22 <sgallagh> A nice feature to add to Bodhi would be to add a dedicated text box describing tests that the developer would like to see performed
15:19:26 <pjones> mmaslano: I'm not really convinced that there's any chance of "finishing" it; like anything that effects so much of what we do, there's always going to be some room to make it better.
15:19:29 <sgallagh> 2. ^^
15:19:45 <pjones> sgallagh: oooh, that's a good idea.
15:20:07 <mjg59> 2. Part of this is going to be down to a cultural shift. People are used to just firing updates into the repositories, and instead we need to move to a model where there's a good description of what the change is meant to do in order to allow people to verify that behaviour changes are intended
15:20:08 <ajax> 2: i'd really like to see more stats about estimated consumption of test packages.  right now we just have no idea how many people are using -testing and not reporting it.
15:20:12 <mmaslano> pjones: well it's still discussed and the process is changing
15:20:23 <kylem> OK, let's wrap this one up in the next minute or so.
15:20:26 <sgallagh> 2. Yeah, the idea would be to have a list of requested tests, but a separate entry from the text that would appear in the update errata note
15:20:37 <jforbes> sgallagh: Agreed, a place to post test cases would be a great idea.  It would also be good for the auto bug updates from bodhi to mention testing and karma for updates testing
15:20:47 <kylem> actually, i'll give it another 2, lots of discussion. :)
15:21:02 <ajax> 2: for that matter, even opting into -testing is non-obvious UI.
15:21:30 <sgallagh> ajax: Agreed. We should try to work with the PackageKit developers to improve that
15:21:41 <jforbes> 2: I think one of the problems is a bug gets updated automagically to say the update has pushed to testing, and users expect that magic happens in the back end.  We need the reporters of bugs to be able to easily test and give karma to get their bug fixes pushed
15:21:50 <pjones> sgallagh: I think what you're saying meshes very well with what mjg59 is saying; we need testers not only saying that the change worked as expected, but also having the ability to notice changes that aren't intended.  right now we really don't have that.
15:22:19 <mmaslano> 2: it's needed more work on bodhi. Some test for packages could be there posted always. Like the main use-case.
15:22:21 <sgallagh> Yes, agreed
15:23:15 <kylem> Q3: How would provide better support for various spins? .. like KDE, Moblin, Server etc ..
15:23:42 <mjg59> 3. What resources do other spins want that they don't currently have?
15:23:53 <sgallagh> 3. I think that's a bit of an ambiguous question. I think we'd first need to get a better idea from the spins about what we're failing to do for them.
15:24:02 <cwickert> mjg59, 3. testing testing testing
15:24:43 <cwickert> 3. QA needs to take care of testing the spins and not only the desktop spin. someone needs to make sure the desktop sig must communicates changes that affect others more clearly
15:24:45 <mjg59> 3. The main problem I see with spins is that they're effectively unbounded in quantity and there's an insanely large combinatorial explosion of packaging possibilities
15:24:54 <pjones> 3. obviously there's a testing problem on spins, but that's partly a specific facet of the more generic problem of their visibility.  we tend to focus on the desktop spin and promote it on e.g. fp.o more than other spins
15:25:01 <sgallagh> cwickert: 3. I'm not sure that's a FESCo issue. That might be time better spent with FAmSCo to bring in testers with a vested interest in the spins.
15:25:06 <mmaslano> 3: first, it's still hard to find them on our pages ;-)
15:25:10 <mjg59> 3. Expecting QA to test the spins as well as the main release would inevitably reduce the testing of the main release
15:25:18 <jforbes> 3: I think having them follow the same pre release cycle, as well as doing real test days for the spins can help quite a bit.  I think there are spins users who do not test the regular release because it isnt tailored to their needs, which means bugs they would find get missed until tthe end
15:25:23 <pjones> 3. but to be honest that sounds like a bigger problem for the Board than FESCo.
15:25:39 <ajax> 3: i think "spins" are a little too poorly defined to really answer that question.  it doesn't seem like, for example, the electronics and KDE spins are really the same thing
15:25:57 <jforbes> 3: mjg59 I agree, QA cannot do it all, so hold test days, and leverage the community as a whole.
15:26:01 <kylem> the submitter has clarified the ambiguity with "more visibility, more independence, variety in package versions" as the resources/support he meant.
15:26:06 <pjones> ajax: that's partly because we use spins as a one-size-fits-all solution, and it really isn't great for that.
15:26:24 <cwickert> 3. in every release we had some changes from the desktop SIG that rushed in late. think of the icon set changes in F13 or recently libnotify. we need to have better coordination of the various desktops, but currently one group (thinks that they)  can do what they want whenever they want
15:26:51 <mmaslano> 3: the spins already have their community of members, who works on them. The other spins simply shouln't make them problems like too many useless dependency (for Server).
15:26:52 <mjg59> 3. I don't think it's fesco's responsibility to provide visibility, and independence is really a board issue. Variety in package versions does sound like a fesco issue, but it also sounds like something that I wouldn't want to support in any way whatsoever
15:27:11 <sgallagh> 3. I think, given those requirements, that it might be prudent to treat spins as separate-but-related projects to Fedora. Similar to the way Ubuntu treats Kubuntu, Xubuntu and Edubuntu.
15:27:31 <mjg59> 3. cwickert: The libnotify change was announced in advance and landed early in the rawhide cycle. How would you have preferred it to be handled?
15:27:54 <ajax> 3: in some sense you kind of need to divorce the fedora project from the fedora distribution.  in fact i suspect the "distribution" should be called something else entirely.
15:28:19 <sgallagh> ajax: 3. Perhaps we should consider Fedora the standard desktop distribution as just another Spin
15:28:25 <pjones> we should call it "hat"
15:28:27 <ajax> 3: once you've done that it's a lot easier to have this discussion because we're not fighting about what fedora _is_.
15:28:46 <jforbes> ajax: well said
15:28:47 <cwickert> mjg59, by being announced on devel-announce and by the maintainer fixing the dependent packages ha owns. he broke epiphany and did not rebuild it for more than a week which caused many other packages to be broken too
15:28:52 <kylem> ok, two minutes left on this one.
15:29:05 <mmaslano> 3: ajax: it depends how the split will be done. The situation of non Desktop spins could be the same
15:30:04 <ajax> 3: mmaslano: i think once you do that split you have to reflect it in package git too.  if you want to derive a spin you get to branch from rawhide at some point.
15:30:11 <sgallagh> mmaslano: I think "Fedora the project" is the complete set of available packages, and we treat any rollup of those packages "Desktop", "KDE spin" "Electronics spin" as a sub-project
15:30:13 <mjg59> cwickert: You're right that it should have gone to devel-announce, but that sounds like an error rather than a process issue. The GTK 3 transition is inherently leaving a lot of transient breakage, and while I'd love to have a less bumpy rawhide I'm not sure how this could have been made significantly better
15:30:21 <ajax> 3: and then it's all about inheritance trees
15:30:24 <cwickert> 3.. one more thing we can do for the spins is reduce the dependency hell. people/spin maintainers must not be foreced to install software they don't want in their spin. we've made some orpgress in the past year hiwever
15:30:39 <kylem> Q4: What are some policy/bureaucratic/etc changes you'd like to see (primarily for the purpose "getting stuff done", but feel free to come up with your own justifications as well)?
15:31:09 <mjg59> 3. I think the reality is that the desktop "spin" is pretty much our flagship project and failing to recognise that would lead to a reduction in the quality of the thing most of our users download
15:31:19 * cwickert wonders what his finger do with that keyboard
15:31:29 <pjones> 4. well, we really need to do more fesco voting in the tickets instead of in the meeting.  We could have skipped almost all of the feature discussion yesterday, for example.
15:31:45 <pjones> 4. but also we really need to be much stricter about the agenda, to enable fesco members to actually come to the meeting prepared.
15:31:58 <mjg59> 4. I'd like to see us providing the mechanism to provide updated applications in order to make it easier to implement the policy that -updates is for bugfixes and security
15:32:01 <pjones> 4. (this bugs me constantly...)
15:32:44 <mjg59> 4. I'm still pretty unconvinced by the feature process in general.
15:32:45 <pjones> 4. taken in a different way, we need to get some form of update repos for projects that want to be more aggressive about making new versions available to users.
15:32:46 <jforbes> 4: I would like to see the updates policy stabalized.
15:32:47 <sgallagh> 4. I'd like to see the Board grant FESCo a stipend to create a bounty board to hire contractors to accomplish certain stated goals that FESCo feels would be beneficial to the upcoming release.
15:32:51 <ajax> 4: i'd like to know what the formal relationship between fesco and fpc actually is.  we've delegated power back and forth a few times.
15:32:57 <pjones> mjg59: the feature process is still pretty much a joke, yes.
15:33:27 <mmaslano> 4: I'd like to see less tickets on FESCO, developers should think for themselves. FESCO should solve only problematic cases.
15:33:30 <mjg59> 4. The feature process is effectively a glorified release note review process. Significant features land in Fedora without going through the process, simply because we assume that developers can be trusted
15:33:50 <sgallagh> 4. Right now, FESCo's power is largely limited to veto capability. We can deny that an upstream change gets in, but we have no power to encourage (beyond asking nicely) that certain enhancements be made or certain bugs fixed.
15:33:53 <pjones> 4. there's nothing inherently wrong with projects like KDE wanting to provide new versions, but that doesn't belong in the updates repo, which should primarily be for fixing bugs in existing versions
15:33:58 <cwickert> 4. the current updates policy is to strict, at least for the branches unter development. the feature process should be lighter. people should be able to do stuff without having to justify to FESCo or the board for ages. generally speaking we should trust common sense rather than enforce more governance
15:34:11 <ajax> 4: related to the feature process, i think we need some forum where people talk about the future directions early enough that we can start planning interactions.
15:34:18 <mjg59> 4. If the only reason people have to write long wiki pages is so they can get two lines in the release notes, and if fesco has to spend time handling those, I think everyone loses
15:34:20 <ajax> 4: (i know, we could call it fedora-devel!)
15:34:35 <kylem> ajax, *cough wayland cough*
15:34:46 <pjones> sgallagh: part of that is the nature of free software and the fact that we rely largely on people we don't direct to do the work; so in a sense the tail does wag the dog there
15:34:54 <kylem> two minutes warning.
15:34:55 <mjg59> 4. Either the feature process needs to be stricter (ie, nothing significant happens between releases without it going through fesco) or we just need to devolve it to a group who can provide technical sanity checking of release notes
15:35:11 <mmaslano> 4: maintainers should be deciding about updates of package themselves. There is needed only some guideline, when it's not good idea.
15:35:13 <jforbes> 4: Certainly clarification/reworking of the feature process would be nice.  It does seem that right now it is a marketing tool more than an engineering tool
15:35:29 <sgallagh> pjones: Oh, I'm well aware of that. But I think that there's a certain benefit to being able to offer, say, $100 to someone to knock off a really annoying bug that no one has bothered to fix yet.
15:35:51 <pjones> jforbes: to be honest, inside RH the feature process is largely a way of advertising what you're working on to your management chain.
15:35:56 <mjg59> sgallagh: Bounty systems haven't been a resounding success
15:35:58 <mmaslano> 4: stricter process doesn't make sense, when we still don't haveenough testers and when they are giving karma even to pacakges with regressions
15:36:18 <cwickert> +1 mmaslano
15:36:56 <kylem> Q5: How does FESCo think it can best improve the experience for technical users who are new to Linux without alienating technical users who are already fluent in Linux?
15:37:21 <ajax> 5: i'm not really sure that's fesco's bailiwick
15:37:25 <pjones> 5. I'm not sure that's fesco's job
15:37:28 <pjones> ajax: jynx
15:38:12 <jforbes> 5: I am not sure how to answer that, since at this time FESCo isn't really setting direction/release goals
15:38:15 <sgallagh> 5. I agree. There's an education component that would be best handled by Doc or FAmSCo, but I don't think there's much that FESCo can do directly
15:38:18 <mmaslano> 5: it's not about fesco, but more about community on fedora-devel, where they are posting questions. We can't force anyone to be nice to newbies.
15:38:19 <mjg59> 5. While I don't think it's inherently fesco's job, I think that's something fesco has to keep in mind when setting policy
15:38:58 <ajax> 5: devel isn't a newbie list.
15:39:20 <mjg59> 5. I mean, we can relate this to the update policy - the existing technical users are perhaps better able to handle breakage in updates, but an unstable distribution isn't a good way for people to learn to work with Linux
15:39:24 <sgallagh> ajax: 5. There certainly are newbie developers
15:39:41 <sgallagh> 5. That includes old developers having trouble with the move to git
15:39:48 <mmaslano> 5. it's not all about updates
15:40:10 <ajax> 5: sgallagh: sure, but that's not what the question asked.  the question asked about consumers, not developers.
15:40:15 <mmaslano> 5. maybe some start for newbies, something else than packaging guidelines will be helpfull
15:40:26 <sgallagh> ajax: 5. Actually, that could use some clarification, I gues.
15:40:33 <cwickert> 5. I don't think that technical users are our problem, eve if they are new to Linux but willing to learn. The problems are more that we are trying to server non-technical users. It's not that I don't like usability, but for me technical excellence is more important. If Fedora wants to target Noobs, I'm afraid we don't reach the target audience we want. We want active users, we want users who are willing to learn, willing to help and who become c
15:40:33 <cwickert> ontributors in long term
15:40:40 <kylem> Since I think it might tie into the "it's not really FESCo's job" -> Q6: What do you think about the Hall Monitor Policy? https://fedoraproject.org/wiki/Hall_Monitor_Policy?
15:40:40 <pjones> 5. sgallagh: yeah, I read that as technical /users/, not new contributors.
15:40:49 <sgallagh> 5. Are we really discussing only consumers, or contributors, or consumers that we want to become contributors?
15:40:56 <pjones> 6. I think the hall monitor policy is utterly indefensible.
15:41:01 <mjg59> 5. Our existing developers and technical users are an important part of the distribution. They're probably the people we get the best bug reports from, and alienating them isn't to our advantage. But beyond ensuring that we consider them when deciding anything, I don't think there's a great deal fesco can do.
15:41:46 <mmaslano> 6: I was surprised that we have something like that. That's censorship in my opinion. It should be used only on spam. Nothing else. We can't remove opinions, which we don't like
15:42:06 <jforbes> 6: The hall monitor policy is really something for the board to discuss, and not really related to FESCo
15:42:09 <mjg59> 6. I think something has to be done about behaviour on mailing lists. I'm not convinced that the hall monitor policy was the right thing, especially when it appeared to be enforced arbitrarily and without conviction
15:42:35 <pjones> 6 jforbes: true, but he's asking our opinion on it, which many of us certainly have
15:42:57 <ajax> 6: the entire hall monitor policy you need is "don't be a jerk" and "if you find yourself explaining why you're not being a jerk, you are"
15:42:59 <mjg59> 6. People need to be able to express technical disagreements in a constructive manner. We don't need the constant petty belittling of people's contributions or motivations that are present throughout the community.
15:43:05 <mmaslano> 6: mjg59 you can't force people to be polite and discuss only technical questions.
15:43:05 <sgallagh> 6. I agree, I don't like censoring genuine opinions, but at the same time, I think it's right to have a policy in place to deal with e.g. hate speech, off-topic conversations (like how to get patented/copyrighted material, etc)
15:43:16 <cwickert> 6. Fedora is a large project of many people with many different interests. Therefor it is normal that there are conflicts. We must be able to stand them and have a fruitful and open discussion about the problems. I don't think that a Hall Monitor policy will help us. I don't think we need it or should have it
15:43:26 <pjones> 6. mjg59: yeah, there's certainly some bad behavior, but anointing certain people to wipe out discussions they don't like is really, really not a good answer.
15:43:31 <mjg59> 6. Oh, we certainly can. That doesn't mean it's a good idea.
15:44:18 <mjg59> 6. pjones: I don't inherently see a problem with certain people being able to do so, but I think it being a group of volunteers with their own positions on issues is a recipe for disaster
15:44:19 <pjones> 6. mjg59: for some reason we have an inability to tell people when they're behaving badly.  Usually actually just mailing somebody and telling them they're misbehaving is enough.
15:44:22 <sgallagh> 6. The problem with trying to set a distinction on what is or is not okay to censor is that every moderator may have a different view on where that distinction lies
15:44:29 <kylem> ok, i'll move onto the next question in a minute.
15:45:11 <mjg59> 6. But practically, I agree that occasionally saying "Please consider whether this was constructive" is likely to be more effective than just dropping conversations
15:45:17 <sgallagh> 6. But there ARE certain cases that are clear-cut. E.g. direct insults against a particular group (e.g. racial, cultural or similar) or patently illegal requests.
15:45:30 <sgallagh> 6. In those cases, I think it's acceptable to moderate an individual
15:45:41 <mmaslano> 6. don't feed trolls. There's nothing else what could be done about it.
15:45:44 <jforbes> 6: Indeed, everyone has opinions... Frankly I understand why the policy was created, but I don't believe the enforecement is meeting goals, and I don't think it is a spectacularly great idea the way it is set up
15:46:02 <kylem> Q7: Does FESCO see a need for a Mentor program to help new people who want to learn how to maintain/create packages for Fedora?
15:46:04 <mmaslano> 6. sgallagh I didn't notice anything like that
15:46:05 <ajax> jforbes: "was" meeting goals.  it's not been an active policy for a while.
15:46:15 <pjones> 6. sgallagh: we've not really had a big problem with that
15:46:31 <mjg59> 7. Sounds kind of like a board issue? I'd love to see it, though.
15:46:45 <sgallagh> 6. I didn't say it HAS happened. I'm trying to define my personal impression of the only cases where I think the hall monitor policy is absolutely valid.
15:46:49 <mjg59> 7. Anything that lowers the barriers to entry without reducing the quality of contributions is a good thing
15:47:11 <mmaslano> 7: sponsor should take care about his maintainers at least at the start.
15:47:11 <sgallagh> 7. A mentor program is a must-have
15:47:24 <pjones> 7. that sounds nice (though not a fesco issue); something similar for reviewers would be good as well.  We've seen a fair number of cases where contributors were clearly driven away by overly picky or harsh reviewers.
15:47:33 <sgallagh> mmaslano: 7. The problem is that a sponsor is generally only found after initially creating the first package
15:47:39 <cwickert> 7. We already have a mentoring program, at least for the ambassadors and the sponsorship for the packagers is not much different. I consider sponsirship not a singular event, it's not only sponsoring somebody in FAS. I take care of all people I sponsor. I watch their commits and come up with suggestions. I'm already mentoring them if you will
15:47:47 <sgallagh> mmaslano: 7. We should have a mentoring program from soup-to-nuts
15:48:01 <ajax> 7: that'd be lovely, although i think the real issue is that packaging is the accident you have to do on the way to doing interesting things.
15:48:09 <sgallagh> cwickert: That's admirable, but not every sponsor behaves thusly.
15:48:18 <mmaslano> 7. sgallagh easy, give more people sponsorship. They will have less people and they can look on them
15:48:39 <jforbes> 7. I like the idea, FESCo should have a strong interest in getting people involved, and making it easy for them to do so
15:48:44 <cwickert> sgallagh, indeed, i only sponsor ~20 people, while others sponsor 200. This means we need more sponsors to do it right
15:48:56 <sgallagh> mmaslano: 7. Right, but we need a clear view of where sponsors responsibilities start, too.
15:49:13 <sgallagh> 7. Right now, the policy only REALLY implies that sponsors are required to sign off on your first package.
15:49:24 <kylem> OK, two minutes and we'll move on.
15:49:30 <sgallagh> 7. There's no mandate that they have to help you put that first package together right from the start.
15:50:04 <sgallagh> cwickert: 7. We need to make it easier for packagers to gain sponsorship as well
15:50:04 <pjones> 7. sgallagh: yeah, the sponsorship bar as currently stated is "are you tall enough to get on the ride"; there's no real acknowledgement of different skill levels required for various things.
15:50:29 <pjones> 7. sgallagh: but that's hard to do - we'd have to really think about packaging vs interaction with other packages in a way we've not codified before.
15:51:29 <mmaslano> 7. if sponsor will be forced to mentoring, it will be even harder to be sponsored.
15:51:32 <jforbes> 7: the theory is that the review process helps with getting it right, but yes I think some sort of mentoring could really help guide people through the process, and go beyond getting your first package in
15:51:32 <kylem> Q8: Chain builds are pain, especially after adopting new update policy. Currently you need to wait and wait for stable repository or to ask rel-eng for dedicated buildroot that inserts delays too. How would you solve it? Would you give more freedom to packagers to create dedicated buildroots on-the-fly and then merge packages into main buildroot back without involving rel-engs?
15:51:35 <sgallagh> pjones: 7. I still think it's worth the effort in the long-term
15:52:13 <mjg59> 8. I'd ask rel-eng for their opinions on the matter
15:52:22 <pjones> 8. well, I think giving developers carte blanche to created dedicated buildroots might create some problems for rel-eng, at least in the short term, so we need their input there
15:52:44 <sgallagh> 8. I only have a limited understanding of the internals of Koji, but I'm under the impression that this is not something that (at present) can be scripted.
15:53:03 <pjones> 8. the situation does need some focus; it's definitely not as good as it could be.
15:53:04 <ajax> 8: when this came up for (iirc) a kde feature repo for f12, we got a little resistance from releng on the grounds that koji storage is not infinite
15:53:08 <mjg59> 8. More seriously - I don't want fesco to do things like mandate that developers be able to do something if that creates more work for other people. If the existing chain build situation causes problems, that's something that has to be handled by discussion between the people who want functionality and the people who can provide it
15:53:46 <cwickert> 8. Chaninbuilds were a pain regardless of the updates policy. rel-eng is the only way to go, you cannot wait for the updates-system. One solution I could think of is a separate chainbuild repo like the 'local' repo, where packages show up immediately. Or get a tag from rel-eng (still slow)
15:53:47 <mjg59> 8. Code's going to have to be written, storage is going to have to be provided. If fesco can help get the process started then wonderful, but I think beyond that it's not something that fesco can force.
15:54:05 <pjones> 8. also buildroot inheritance rules are not for the feint of heart, and exposing packagers to their intricacies seems like not the best thing
15:54:06 <jforbes> 8: I ran into this in the F14 cycle. I really think it would be best to be able to ask koji for a number of package builds.  buildreqs determine the build order, and it is all coming from committed sources, so there shouldnt be issue there.  Unfortunately you then have to implement policy to either push all or none, and there is a SMOP involved
15:55:09 <sgallagh> jforbes: 8. Perhaps we could work on a better koji/bodhi interaction where we could require that if any one package in a cluster-build like you're talking about became an update request, they would all be brought in together. Thus ensuring that they land together
15:55:22 <ajax> 8: and yeah, not a trivial programming challenge to get koji to do for you.
15:55:26 <kylem> OK, we'll move onto the final question in a minute. Feel free to prefix with '8' and I'll collect the responses afterwards if they interleave.
15:55:37 <mmaslano> 8: I'd like to see better infrastructure scripts which can do chain builds, create a list of pacakges for rebuild dependent on ther buildrequires and many other things. Looks like we don't have enough relengs for that
15:55:52 <kylem> Q9: What would you like to see or hear from the board, that would best help FESCo fullfil it's mission?
15:56:19 <pjones> 8. it might be interesting to talk to rel-eng about doing what jforbes was just saying with a sortof transient repo.  hard to say what the best approach is without having rel-eng in the loop though.
15:56:25 <mjg59> 9. I'd love to have more feedback on whether what we've implemented meets their expectations, but really I guess that that's something we should be more proactive about getting
15:56:49 <sgallagh> 9. "Hey guys, have a bag of money". Only partially kidding. I think FESCo needs a limited budget of its own to try to influence upstream developments to further our goals.
15:57:14 <mjg59> 9. It's been a touch disheartening to have so much of the anger at the updates policy directed at fesco, when as far as I can tell we've implemented what the board wanted. Some more public support would be good.
15:57:31 <pjones> 9. I'd like conversation to be a lot more two-way between fesco and the board.  right now it's pretty much "the board says we should do $handwavy" and then we make policies we think may solve whatever handwavy is.
15:57:58 <pjones> sgallagh: I think that'd be a very interesting experiment to start small with
15:58:21 <kylem> (Seemed like a good final question) I'll call a hard-stop at 11am so we don't overrun our scheduled time slot. If anyone would like to add anything to their previous responses or clarify, I'll give you to 5-past the hour. Please (obviously) prefix with the question number you're revising.
15:58:31 <mjg59> 9. If the board would like to give fesco a budget for mind-altering substances of any description, that'd make some fesco meetings a lot easier
15:58:57 <mjg59> Also, a fesco beach house
15:58:59 <pjones> mjg59: tbf, budget isn't required for that.  If they'd like to just ship us the goods...
15:59:09 <jforbes> 9: Perhaps a semi regular meeting between FESCo and the board would help keep the communications open.  As for the influence of upstream developments, I am not sure about budget, but it would make sense to work together with some very general release goals and try to move them forward
15:59:11 <cwickert> 9. First of all the board should listen and *then* talk. ATM it is having visions every now and then and we are to implement it, no matter if we like their 'visions' or not. Think of the "Fedora vision & more specific goals" thread two days ago. I cannot recal that a single of these items was discussed by the community before
15:59:40 <cwickert> 9. This being said I'd like the board to first listen and then hear from them
15:59:52 <mmaslano> 9: board is giving the direction, fesco is solving technical issues. I don't know how much communication is between fesco and board now.
15:59:52 <pjones> 9. cwickert: I think a lot of the time their job is to raise issues that aren't being discussed, though
16:00:17 <pjones> 9. jforbes: I think that's a really good idea
16:00:46 <cwickert> pjones, raising issues is fine, but not telling eerybody to implement their "visions"
16:00:48 <pjones> 9. jforbes: (the regular meeting idea, that is)
16:01:02 <ajax> 9: yeah, what jforbes said (i'm typing slow today)
16:01:04 <mjg59> 9. Yes, more regular communication would be good. I know the new FPL wanted to set one up, and then everyone kind of dropped the ball
16:01:07 <kylem> OK. Thanks for your time, candidates, and thanks to all who submitted questions or just came to watch.
16:01:14 <sgallagh> 9. Well, a specific example would be for sponsoring an enhancement to Koji to allow developer chain-builds, as discussed above
16:01:18 <pjones> 9. cwickert: but it *is* their job to set non-technical direction, so they're going to do some of that no matter what.
16:01:24 <ajax> gotta run.  hasta luego.
16:01:28 <jforbes> 9: pjones yeah, I know no one wants to add a bunch of meetings to their calendar, but perhaps every 2-3 weeks woudl be decent
16:01:34 <sgallagh> 9. That was an example for the use of a budget, I meant.
16:01:41 <mjg59> 9. Requesting technical feedback as part of their policy making process would be nice
16:01:51 <cwickert> pjones, 9. but based on input from the community please, otherwise people no longer want to engage
16:01:52 <pjones> 9 jforbes: once a month might be a good start and we can evaluate how that's worked from there.
16:02:01 <pjones> 9. cwickert: indeed.
16:02:19 <sgallagh> pjones: +1 on a monthly meeting
16:02:22 <jforbes> 9: pjones once a month would be a great start.
16:02:55 <cwickert> how about rotating meetings of the board? one time with FESCo, once with FAmSCo and so on?
16:02:56 <pjones> 9. jforbes: it'd be a lot better than where we are now, which is basically no 2-way discussion.
16:03:44 <kylem> okie doke. to be fair to the people who had to run at 11, i'll call time now
16:04:01 <kylem> thanks to everyone for coming.
16:04:02 <cwickert> thanks kylem for hosting us
16:04:10 <kylem> np. happy to help.
16:04:12 <pjones> yeah, thank's for the great hosting job.
16:04:15 <pjones> thanks.
16:04:15 <jforbes> Thanks for getting this together
16:04:16 <sgallagh> kylem: Thank you for moderating
16:04:17 <cwickert> and thanks for all the questions
16:04:20 <pjones> no bad apostrophe.
16:04:51 <kylem> if anyone wants to revise a statement, just prefix it with the question # (in case you were unclear or something, i don't mean to continue discussion) and i'll sort it out in the minutes.
16:05:01 <kylem> i'll give you a few minutes before i close the logs.
16:05:05 <mjg59> kylem: Thanks!
16:05:14 <mjg59> And thanks to everone who asked questions
16:05:40 <cwickert> kylem, I'd like somebody to fix all the typos in my statements ;)
16:05:47 <mjg59> If any questioners are unclear with anyone's responses, I guess they can follow up individually?
16:06:21 <kylem> sure. i'm not sure what the best forum would be.
16:06:23 <cwickert> most of us are still around, people can always come up to us in another channel
16:06:31 <pjones> mjg59: or on f-d-l?  just so the answers are public?
16:06:44 <mjg59> That's true
16:06:47 <pjones> (and it may be the most productive discussion to happen there in months...)
16:07:06 <mjg59> So, yeah, if you have followups just start a thread on devel-list
16:07:31 * jforbes will be around less today... still sick
16:07:41 <kylem> just a reminder to everyone still here that the voting period is the 20th through the 28th.
16:08:05 <kylem> ok, if there's no corrections. let's hope this works. :)
16:08:07 <kylem> #endmeeting