From Fedora Project Wiki

Revision as of 23:05, 8 September 2010 by Duffy (talk | contribs)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Board Meeting 08 Sep 2010

Roll Call

  • Present: Jared Smith, Máirín Duffy, Jon Stanley, Matt Domsch, Colin Walters, Tom 'spot' Callaway, Stephen 'Smooge' Smoogen, Chris Aillon
  • Regrets: Chris Tyler
  • MIA: Rex Dieter?
  • Assigned meeting secretary: Stephen Smoogen
  • Actual meeting secretary: Máirín Duffy


Agenda

  • Updates
  • Work on Open Tickets

Updates

  • Any important news to review since Friday?
    • None came up.

Work on open tickets

(List below is from last week -- feel free to modify)

  • Ticket 77: Israeli domain request (https://fedorahosted.org/board/ticket/77)
    • Matt: We made it easier to use fedoracommunity.org, but we aren't prohibiting the use of other TLDs. +1 to granting a trademark license for use in their domain name, fedora.org.il.
    • General: Is it a requirement that trademark license requests have content for review before approval?
      • Matt: they said they'll put up local community forums and local community event schedule
    • Do we have a list of trademark licenses we've given out to check in on?
    • Approved.
  • Ticket 78: Vision statement (https://fedorahosted.org/board/ticket/78)
    • vision statement + 3 mini goals to realize it
    • Proposed minigoals
      • more than a pkg repo, more holistic / cohesive
      • integration work focus
      • Improve usability for new Linux users for all default Fedora desktop applications in partnership with the upstreams (over the next three releases)
    • vision statements
      • world with 100% floss vs healthy / feasible floss ecosystem (mizmo)
      • fedora 100% floss
      • grey area between 100% free and 100% functional (for Fedora)
        • not convinced 100% free in the world is a good goal (mdomsch)
        • we need to show them something that works, not a pile of bits that doesn't work (caillon)
        • free but non functional doesn't help our users (mdomsch)
          • and spins FOSS in a negative light (caillon)
    • jds2001 - try to bring strategic working group back?
      • spot - don't see the same level of frustration as necessitated the group last time
    • #action #fedora-advisory-board IRC discussion for vision statement
      • talk post-meeting today
      • schedule one formally?
    • #action 5-6 mini-goals as a group - each person come up with two (mini-goals are actionable goals to get closer to vision, example one is, focus on floss webapps for next 2-3 releases) by monday 13 sep
      • don't worry about filtering by resource availability / etc just come up with good ideas and we can do course corrections when we take a look at them
      • put in ticket @ https://fedorahosted.org/board/ticket/78
  • Ticket 79: Anthropology Report (https://fedorahosted.org/board/ticket/79)
    • report seems to indicate we need a formal mentoring program (jds2001)
      • common complaint/concern; infrastructure goes thru this, folks want to help but folks are too busy to mentor them (mdomsch)
      • I've seen the same in the Docs project (??mizmo??)
    • a lot of positiveness / positive energy in the report, is there a way we can make the findings more public? (cwalters)
      • a press release kind of thing maybe? (mizmo) not sure (colin)
      • nice to see positive and share with people (jsmith)
    • mizmo to post whiteboard photos from report review session w lmacken (post to advisory-board list and trac ticket)
  • Ticket 81: start.fedoraproject.org (https://fedorahosted.org/board/ticket/81)
    • jsmith brought up at marketing meeting (weren't many ppl in the meeting), so they want to discuss on marketing list
    • #action jsmith will kick off discussion on mailing list
    • requirement: has to be static, otherwise load will be too great (jds2001)
    • what about static page with javascript that pulls in stuff from other places (mdomsch)
      • it's okay just watch the load on our servers (jds2001)
      • smooge: we get 55k hits a day to start.fpo / 29k IPs
    • short-term let websites team work on start.fpo, long-term maybe remove it
      • planet feed, identi.ca feed, announcement-list feed, current release notes, high-level schedule for the next release (mdomsch), tip of the day? (caillon)
  • Ticket 82: Charter for Community Working Group (https://fedorahosted.org/board/ticket/82)
    • Rex has been doing good work here, not on call right now, hopefully can give us an update next phone meeting on Monday (jsmith)
  • Ticket 83: Revisit Updates Vision (https://fedorahosted.org/board/ticket/83)
    • We have to be flexible bc KDE's upstream release policy is kind insane. when they release a major version, the older version becomes unsupported (jds2001)
      • a lot of packages have that issue though, not just kde packages (smooge)
    • a lot of things to consider - abi change? api change? leaf node or core component? (jsmith)
    • With KDE you're guaranteed to have abi/api breakage between minor point releases (jds2001)
    • the reason we dont want folks pushing 4.4 when 4.3 was in there, because we're afraid of breakage that comes in the new release and it will have been significantly less-tested. how many bugs in the old release (4.3) are showstopper? do we have a lot of those to justify the push to 4.4? (mdomsch)
      • in terms of security issues... can't concretely point to anything :-/ don't know if its fair to ask community maintainers to backport for security issues (jds2001)
      • Rex pointed out where in the past this has happened... similar to how linux kernel works - kde will fix a security bug but won't tell you that they fixed it until much later, so you have to assume there are fixes in there (smooge)
        • not convinced.... if we go loosening up the statement, then why should anybody follow it? pushing major enhancements into a release mid-stream really needs a good reason, not just because 'you feel like it'. if you have an exception case that makes sense, come on and bring it forward. but don't dilute the guideline, don't see fesco turning down well-reasoned exception requests (spot)
        • fesco believes it has no authority to grant exceptions (smooge / jds2001)
        • then we need to make it clear to fesco they can drive exceptions (spot)
        • rex talked about asking for exceptions in specific kde situations.... let's go back to rex and ask which specific piece is he uncomfortable with, and what is the problem he is trying to solve by having us revisit it? fesco should have primary responsibility for technical deciions (jsmith)
        • we gave a fesco a vision but not a mission to enable them to know how to do what they have to do. (smooge)
        • We need a way to have updates for some apps (e.g. a new version of Inkscape) - if it's a leaf node package it's not as harmful right? (mizmo). We need a backport mechanism, separate from the updates tree (mdomsch).
        • maintaining a list of which apps can be updated, and which can't, is within FESCo's purvue.
        • maybe opt-in by the user rather than yum excludes - maybe have a checkbox to enable backports? (mdomsch)
        • do personal repos solve the problem? (jsmith)
        • probs with personal repos: (1) have to know where they are (2) dependency tree tough when there's 100s of other repos (mdosmch)
        • backporting, additional burden on packagers (jsmith) don't have to do the backports but is available if they want to (mdomsch)
        • don't want folks to be essentially running rawhide by installing an app thru the backports repo (spot)
        • but firefox is a library too, maybe a unique case (colin)
        • but look at gnome-shell.... if we put that in backports, it might cause issues (spot)
        • too hard to switch to rawhide and then switch back (colin)
        • we have the bits, most of them, some of the fedorapeople repos and koper work going forward will be the foundation, then we can make tools easy enough to expose to users to make an intelligent choice, if they want to use gnome-shell or not, if it doesn't work back out without too much pain.... all the basic parts are there, what we need is just tooling - worried about backport stream making this tooling development more difficult (spot)
        • if you look at the kopers page on the wiki, they use the kde redhat repo as an example and talk about how it'd work better in kopers (jsmith)
        • from my exp doing firefox work - i broke the package accidentally, i haven't been aggressively promoting this, email flooded with complaints.... our users are pretty competent to add a third-party repo, look at how many other folks are. this is in comparison to remy's repo, where it's not just firefox it's other pckgs too that people don't want (spot)
        • we haven't heard from folks like Dan Williams who maintains networkmanager - ties into a lot of other things like the kernel, etc. his maintenance burden is basically pushing the same release into all fedoras. if we make that a lot harder for him, that may mean less nm bug fixes for fedora. I think a lot of discussion has been on high-level apps, but we should think about not mkaing it harder for folks like dan & the kernel people (colin)
        • i have a pretty good insight on the kernel folks, have a structure where they dont push the latest kernel bits, they push from stable branch and if they have a really good reason to push, they do aggressive testing, and ask for exceptions... don't think they would mind that at all (spot)
  • #action board should make it clear that fesco has power to grant exceptions to policy (smooge) agreed: jsmith, spot (as long as this doesn't permit altering mission statement), jds2001 (as long as there is a written policy with criteria for exception acceptance & rejection)
  • #decision we cool with the above / granting fesco exception-granting power
  • keep the ticket open so Rex can give us more details about the specific language that bugged him (spot) agreed
  • Ticket 84: Annual User Survey (https://fedorahosted.org/board/ticket/84)
  • Others?
  • if questions asked / methodology scientifically sound, don't see why we wouldn't agree (jsmith)
  • so what do we do next? come up with questions we'd like? (jsmith)
  • robyn helped me find the opensuse survey from this year, looks like a good starting point (jds2001)
  • opensuse... someone on the suseplanet recently posted somehting about lessons learned from that study. there are certain questions that are leading or not yes/no questions.... (smooge)
      • smooge can't find this now and wonders if he hallucinated.
  • freeform response is okay though (jds2001)
  • yeh but freeform diff than leading question (jsmith)
  • what is the link to the blog post?
  • these cost $40k+ (smooge)
  • look at how opensuse did this, for a number of years (jds2001)
  • #action define what's our scope
  • #action define what's our audience
  • #action define what we want to learn?

Other Board Business

Next meeting

  • Next meeting: Friday, September 10th: public IRC meeting
Retrieved from "https://fedoraproject.org/w/index.php?title=Meeting:Board_meeting_2010-09-08&oldid=196328"