|| ||Rex Dieter <rdieter-AT-math.unl.edu> |
|| ||Fedora community advisory board <advisory-board-AT-lists.fedoraproject.org> |
|| ||Fedora Board Recap 2010-10-25 |
|| ||Mon, 25 Oct 2010 15:10:54 -0500|
|| ||Article, Thread
= Board Meeting 25 Oct 2010 =
== Roll Call ==
=== Present ===
* Rex Dieter
* Tom "spot" Callaway
* Jon Stanley
* Stephen Smoogen
* Máirín Duffy :)
* Chris Tyler
* Jared Smith
=== Regrets ===
* Matt Domsch
* Chris Aillon
== Agenda ==
=== Planning for F14 release next Tuesday ===
* Let's encourage people to keep an eye on the blocker list to keep
from having a last-minute slip
* on track for Tuesday
=== F15 release names ===
* We got the F15 release names back from RH legal. Announcement going
out today, voting opens tomorrow.
* Asturias, Blarney, Sturgis, Lovelock (Frozen monkey), Pushcart
* Election for names starts ...?
* Jared will announce names shortly after meeting
=== Fedora Elections, next steps? ===
* nominations open
* Jared will be posting call for nominations for F15 FAMSCo / FESCo /
* Will make another call for election questionnaire coordinators / town
hall coordinators / election coordinator, which Jared will do unless
someone else steps up to the plate?
* (Spot) if nobody steps up consider me a backup
* (Mizmo) will paste notes on election coordination in wiki and send to
=== Remaining issues for approval of the multi desktop DVD (ticket #88) ===
* https://fedoraproject.org/wiki/Media_Handout_Requirements (kudos to Matt)
* If $SOMEBODY in RELENG hypothetically willing take responsibility for
rel-engineering of this, and if requirements are met, are we approving
* (Jon) seems awful late to do it. Perhaps one of the criteria should be
* (Smooge) how about putting timing after this... if it's not done by
Alpha... it shouldn't happen
* (Spot) should be a schedule milestone?
* (Jon) we're past feature freeze, this is a feature
* (Mizmo) - example of changing things past alpha, makes it more
difficult for supporting materials on the website, docs, etc.
* (Spot) (1) should there be a timing requirement in these guidelines?
... yes from my POV (Rex agrees) (2) Do we give an exception in this
specific case as there were no guidelines in place when it was put together?
* (Jared) If it's built on our infrastructure, if $STRAWMAN is okay
helping getting it built & hosted on our infrastructure.... in this
specific case if they meet all requirements outside of schedule/timing,
then yes they can move forward.
* (Mizmo) added a requirement to the doc for Fedora Design Team produced
artwork & explicitly adding schedule requirement that will be waived for
this particular request.
* Conclusion - Jared will talk to Christoph about our decision.
=== Board blog ===
* just need an official name, is "Fedora Board Blog" okay?
* Mizmo will send this to infrastructure team
=== charter for a Community Working Group ===
* (ticket #82), time permitting
* discussion from last meeting:
** Main diffs:
*** accountable to board
*** Suggests more specific task examples for group to do
* Rex amended draft based on discussion last week
* Any comments on the latest draft?
** lifetime for group? charter for a year
* Next steps
** If everybody is okay with draft, then approve & announce
*** Mizmo brought up one nit - mission statement needs improvement - so
we agreed to copy the first sentence of Goal & Strategy section to use
as mission statement as well. (Rex will fix in wiki)
*** Board Approved, no one opposes
*** Rex will announce approved charter
*** Rex will move charter to a better wiki home if necessary
** Identify some candidates to staff the group
*** Send generic message widely to get interest in applications? (Spot)
+1 (Jon, Rex) (This is similar to how package committee is appointed)
*** Definitely don't want this to be a cabal
*** When should we put out call?
** How many should we have?
*** Good to have an odd number - Rex proposes 5-7
*** Jon, Smooge - 5 good, 7 too many
** Not elected, appointed by Board
=== revisit updates vision (ticket #83) ===
* (Spot) word of caution that FESCo is already working on this and
making progress, if we significantly change the vision they won't be
terribly pleased with us at this point. His inclination is to let it sit
as-is for a while... then revisit vision & implementation - post-mortem
to see if it made things better or worse. It will apply retroactively to
previous releases... Fedora 14 will be the first release to start with
* (Jared) What are the issues, Rex?
** Beef with second bullet point... "only fix bugs & security issues."
Don't agree with that language. (Rex)
** What else would you want to do reasonable? Feature introduction...
no. Feature re-work, maybe. (Jon)
** Adding new features is the exception rather than the norm. FESCo can
deal with exceptions, voting on things. Already examples listed on the
wiki for handling this. (Jared)
** Isn't that the heart of the policy? (Colin)
*** Core vision of the statement is providing a consistent user
experience. So that phrase in contention doesn't seem to add or take
away to that core. (Rex)
*** (Spot) I think I wrote that specific clause in the document. I
wanted to make sure we added very specific language in our guidance to
FESCo to ensure there's no ambiguity. Because "consistent experience"
can be interpreted in 10 different ways... in the past we've seen Board
guidance be spun in ways it wasn't meant to be read. So I wanted to be
clear here that the approach should be to fix only bugs & security
issues. There is the understanding that it won't always be possible and
occasional exceptions will need to come in - but all of the guidelines
for FESCo worked that way. Didn't want a pre-built loophole for people
to say feature updates are okay. The number of legitimate exceptions
shouldn't be too much for FESCo to deal with on a one-off basis.
*** (Rex) I just feel that this is going a bit too far -
overcompensating a bit too far. In IRC with gregdek & smooge a month ago
in IRC.... getting Bodhi updates, testing, qa processes improved...
thought that alone would help the same problem the "hard core" language
*** (Spot) We have a lot of things that are altered pre this policy and
post. Liked or unliked, it's understood by the vast majority of folks at
this point. Let's give it a shot, quit tinkering, and revisit in 6 mos -
1 year to see if it's been successful or not. Could we point to specific
cases at that time, where the policy made peoples' lives more difficult,
then would be open to revisiting.
*** (Jared) Tend to agree with Spot, we've tweaked so many knobs... let
things have a chance and come back and revisit if needed. Need to give
it a chance to see how it works and go from there.
*** (Rex) On mailing list thread.... do we need to mention users in the
consistent experience statement? What about the developer experience?
Expand the list or take out "user" altogether?
*** (Spot) We don't want to break the developer experience at will...
just want to make sure we're focusing on the users. It's hard to find a
developer who isn't also a user. If we want to amend to say users and
developers... that would be okay. Don't want to take "user" out.
***(Jared) Gets feedback, 2-3 months after a release, so many things
have changed, developer can't do what they want to do or too frustrated
and can't apply updates so they have something stable to work with.
Shouldn't have to make a decision between security and stability.
*** (Spot) Intent of document is to provide guidance to FESCo. The
document itself is not policy. If we are proposing making changes to
this document at this point in time, will it affect FESCo policy in any
meaningful way? In this wording change, I see the point it may have been
more appropriate to say users & developers - I don't think FESCo wrote a
policy biased against developers in anyway. So changing the wording now
probably won't be a benefit in any way.
*** (Rex) My second reservation is that a lot of times new releases of
software are the things that fix bugs, and they include features. Oh my
gosh, we could fix these bugs, but I can't because this vision blocks it
because the bug fix is wrapped into feature update
*** (Spot) Rebuttal is several groups have petitioned for exceptions in
this scenario, and FESCo has reviewed them and approved exceptions in
relevant cases, and I haven't been disappointed in the process of these
examples. Let's watch and review these cases in the next 6 mos - 1 year
and make sure that continues.
*** (Jared) Point is not zero-tolerance, point is that there's some
FESCo review / judgment going on. It's not to say we don't want any
exception, just that we need to deal with them one-on-one basis.
*** (Rex) Case studies on what went wrong? I hear that statement made a
lot.... but then when pressed for details, none come out. (??)
*** (Smooge) Pulse audio, kernel, mozilla, KDE (Spot).... we're not
going to fix those...
*** (Spot) To be fair, I don't think KDE is always founded.... there are
a lot of long memories in that space. Very much the same way ppl in
Linux community complaining about GCC 2.6... people bring it up today
still even though ancient history. People see... once it breaks for them
once, they have a long memory about it. Rex has a valid point, there's
room for us to try to capture that data in a more meaningful way,
whenever we come across these sorts of cases (bad experiences with
Fedora regarding updates) - to document them well. Experiences with
quantifiable details. Does our policy capture/resolve these in anyway?
Policy for the sake of policy no good, rather policy for the sake of
*** (Smooge) How many ppl from FESCo will be at FUDcon? Board?
*** (Spot) prolly most
*** (Smooge) Big issue is that we need everybody on the two sides of the
room together to make sure everybody knows face-to-face not just over
emails what's going on.... vs FESCo thinking one thing, us thinking another
*** (Spot) Originally we did a back-and-forth with Kevin (FESCo chair at
the time) and we had confirmed with them we were on the same page.
*** (Jared) Propose take a look after F15 ships and then take a look,
gather some info
*** (Spot) Volunteers to collate, quantification with details situations
where people complain about X update did something bad, send to Spot and
he will keep records on that. Spot will keep them in the wiki as soon as
we get one. Will make it easier for others to add on to as well.
* Let's put to a vote - to reivsit after F15 ships (jsmith)
** (Smooge) +1 (the seconding +1 :) )
** Spot +1
** jstanley +1
** Mizmo +1
** Colin +1
** rdieter +1
** Jsmith +1
** Smooge +1
* Jared will add as F15 milestone
=== Ticket #87 - Finalize the TLA ===
* Jared spoke to RH Legal this morning.... they said they are fine from
their side. Paul might have something on his side but...
* (Spot) AFAIK that document should have been finalized a while ago
* (Jared) I'll double-check with legal that it's final, double-check
with Paul that nothing is waiting on it - Paul says as long as text
hasn't changed from ODT Paul mailed him, it's no issue.
* (Spot) will do the move to Legal namespace once hears from Jared that
to post comments)