From Fedora Project Wiki

Revision as of 08:31, 18 September 2016 by Jibecfed (talk | contribs) (internal link cleaning)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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 / Board (today?)
  • 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 Jared

Remaining issues for approval of the multi desktop DVD (ticket #88)

  • 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 for F14?
  • (Jon) seems awful late to do it. Perhaps one of the criteria should be timing?
  • (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: http://meetbot.fedoraproject.org/fedora-board-meeting/2010-10-18/fedora-board.2010-10-18-18.16.html
  • User:Rdieter/Draft_Fedora_Community_Working_Group
    • 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 the policy.
  • (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 addresses.
      • (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 resolving problems.
      • (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 it's final
Retrieved from "https://fedoraproject.org/w/index.php?title=Meeting:Board_meeting_2010-10-25&oldid=472202"