FedoraSummit

From FedoraProject

Jump to: navigation, search

Contents

Fedora Summit

What/When

A group of Fedora folks are getting together at the Red Hat office in Westford, MA to discuss a public roadmap for the next version of Fedora, as well as some of the RHAT-specific issues surrounding the merger of Core and Extras - repository, source code management system, build system and policies. The merge will enable more community participation, secondary architectures, and simplify creation of derivative distributions out of a single repository.

Sunday 2006-11-12 - Wednesday 2006-11-15.

Starting at 10:00 AM on Monday, Tuesday, and Wednesday, in the Mugshot offices on the second floor.

Who

  • MaxSpevack
  • GregDeKoenigsberg
  • BillNottingham
  • ChristopherBlizzard
  • JesseKeating
  • RexDieter
  • WarrenTogami
  • JeremyKatz
  • DaveJones
  • JackAboutboul
  • various Red Hat folks in Westford/Raleigh (as needed)
  • various Fedora folks on the phone (as needed)

What we actually discussed

Complete IRC Log from #fedora-summit in HTML (all three days)

Complete IRC Log from #fedora-summit (all three days)

Sunday 2006-11-12:

  • Conversation was informal, over dinner, since most people arrived in the afternoon/evening.
  • Lowering barriers to entry for Fedora contributions.
  • What does Sun's Java under GPL mean for Fedora and Red Hat?
  • Fedora Standard Base and the merging of Core and Extras.
  • General overview of some of our major discussion topics.

Monday 2006-11-13:

  • Big picture discussion. Make sure we all agree on the overall goal for Fedora 7.
  • Platform discussion. What is the Standard Fedora Platform, and Why Does It Matter?
  • Build Infrastructure. How do we build packages? How do we build distros?
  • Source Management Infrastructure. What's the new mechanism for source control, and how will we build it?
  • I feel like I'm forgetting a bullet point. The IRC logs will fix that.
  • Multiple Architectures. TomCallaway presented his plan, discussion.
  • IRC Log for Fedora Summit Day 1 - Summit IRC Log Day 1
  • Summit White Board Pictures - SummitWBDay1
  • Forthcoming -- more pictures if anyone has them
  • Summary: Opening Fedora Core
  • Summary: New Build System
  • Summary: Secondary Architecture Policy

Tuesday 2006-11-14:

  • This is our planned agenda, as of Monday night
  • A dial-in has been set up, active starting at 10:00 AM
  • OpenID. What potential is there? What do we think? Worth exploring? etc.
  • IS/IT and Fedora Infrastructure priorities, including discussing single sign on and potential project hosting, and website.
  • Subset of folks have lunch with Tim Burke to discuss hiring for a Fedora Infrastructure job req.
  • Release Methodology. Freezes, Updates, Lifecycle, Legacy, Branding, Planning.
  • QA/Testing
  • Subset of folks talk with Brian Stevens (Red Hat CTO) in the afternoon about much of the last 2 days.
  • IRC Log for Fedora Summit Day 2
  • Summary: Live CD Proposal
  • Summary: OpenID Discussion
  • Summary: Release Process Proposal
  • Summary: Summit results and their effect toward FESCo

Wednesday 2006-11-15:

TBD


Historical

All the topics that were mentioned during planning/brainstorming.

  • Infrastructural and project goals related to the merger of core+extras for the next release - all
  • Fedora Legacy and how it fits into a world where there is no core and everything is external - JesseKeating
  • Roadmap for new public build system for Fedora, including risk assessment for RHEL - dcbw, skvidal(?), JesseKeating
  • Handling secondary arches (read: everything except x86 and x86_64) - dgilmore, pjones, spot, prarit
  • Strategy regarding supporting big 'not upstream' features *cough* xen *cough* now that RHEL5 has forked.
  • Other Non-upstream software
  • Shall we still try and maintain support for ancient hardware that we can't realistically debug/test ?
  • Do we try and solicit for hardware donations for a test lab
  • set up a new Fedora Bugzilla instance, with single-sign on hooks into Fedora Infrastructure (wiki, cvs, etc.) and ability to clone bugs into RH bugzilla / other upstream projects. Discuss merits of this, question of maintainership and ownership.
  • Forming a steering committee to oversee either Core or the newly merged package set; this is the body who needs to handle many of the technical and process problems that we are needlessly escalating to the board to deal with.
  • Decide on how we are doing releases in the future. What would be the new name and branding for Fedora releases? What set of packages should be available in media?
  • Fedora as the Platform for Innovation JackAboutboul
  • Live CD progress update - davidz (?), chitlesh (?)
  • Discuss idea of a Fedora Standard Base (minimal bootstrap), contents of which to be decided in more public fashion
  • What variants will there be of a F7 (Fedora Universe 7?) Who decides what goes in what, and how will we set that up? - jrb (desktop), server, kde, embedded?
  • Argue the merits/drawbacks of inclusion of links to "non-free" stuff: MP3, Flash in particular.
  • What sort of Fedora job reqs do we need?
  • Fedora QA roadmap and stability (WillWoods)
  • How do we improve the quality of test, general releases, and updates in Fedora?
  • How can we strengthen new development projects within Fedora and make them more successful?
  • How is the relationship/process/exchange between Fedora and the various engineering departments within Red Hat?
  • How can we improve the workflow between Fedora derivatives and Fedora?
  • How do we make Fedora self sustaining?
  • Artwork/Branding concerns - how can we make it less painful for artwork contributors to get access to the logo, how can we make sure the FC6 artwork situation doesn't happen again (a lot of last-minute work because there was no defined process to get things in)
  • What is the right approach to take for Fedora IT infrastructure?
  • Stability v. agility
  • Sustainability v. modernity
  • Hosting support v. full freedom
  • Staffing and other resources
  • Package maintaining and respect for translation -- how are we going to avoid mistakes made with translation team as the number of packages that can be translated increases? (Core+Extras merge discussion point)
  • Can we make sure that releases will contain translations up to a certain translation freeze date?