From Fedora Project Wiki

fp-wiki>ImportUser
(Imported from MoinMoin)
 
m (1 revision(s))
(No difference)

Revision as of 16:32, 24 May 2008

Board > Meetings > 2006-11-07

Fedora Project Board Meeting (2006-11-07)

Attendance

Present:

  • MaxSpevack
  • SethVidal
  • RexDieter
  • JeremyKatz
  • BillNottingham
  • MattDomsch
  • ElliotLee
  • RahulSundaram
  • GregDeKoenigsberg (special guest)

Not Present:

Notes/Summary

General Business

  • MaxSpevack pointed the Board to some pre-meeting reading (1 ) (2 ).
  • 2006-11-21 meeting is being rescheduled for 2006-11-20 because several people won't be around otherwise.
  • Plan is to have a face to face Board meeting at the next Red Hat Summit and/or at the next FUDCon, which GregDeKoenigsberg is leading the planning on. He'd like for it to be in the March timeframe, and it will include a code sprint component. One of the sessions will involve the wedding of JeremyKatz, broadcast over the internets and for all the Fedora world to see.

The FC6 release

SethVidal gave a summary for everyone of what happened with the FC6 release. A summary follows:

  • Several days before the release, on the urging of MaxSpevack, all traffic to http://fedora.redhat.com/index.html was set to redirect to http://fedoraproject.org -- the reason for this was that we wanted people who were hitting the top page of f.r.c to be sent over to the wiki, because we consider the wiki to be authoritative and f.r.c to be deprecated.
  • On the release day, load on fedoraproject.org quickly jumped to greater than 140, with 300-400 connections per second being tracked. *.redhat.com also experienced massive load, and the IT department was trying to determine whether or not this load was all the result of Fedora demand, potentially a DDOS attack, or some of both.
  • At the urging of SethVidal, MikeMcGrath, and others, several changes were made, including:
  • killing the f.r.c -> fp.o redirect
  • throttling and iptables tricks to relieve the load
  • replacing dynamic content with static content wherever possible.
  • A decision was made to also upgrade the wiki software on fp.o
  • A bug in Red Hat's load balancer code was uncovered by the massive traffic, that was not otherwise being hit. This did not help the situation at all.

RESULT/ACTION ITEMS

  • f.r.c will be rebuilt into a more stable environment prior to the next Fedora release.
  • New hardware is being installed.
  • Networking will be set up in a way such that the Fedora/rest of Red Hat traffic can be separate in the future.
  • SethVidal is already talking with the infrastructure team about various possibilities -- mirroring the website, DNS round robin, etc. This conversation will continue in the infrastructure team.
  • MikeMcGrath and DennisGilmore are looking at ways to make wiki access more robust and cached. If there are hardware requirements here, the Board can help with budget issues.

Fedora Summit

  • The FedoraSummit is next week. We talked briefly about how the non-present Board members (and for that matter the rest of the community) would be able to stay in the loop. All of the interesting stuff is being tracked on the FedoraSummit page. But the general goal is a public roadmap for the next 6-9 months, including the next release of Fedora. Also making the Fedora/RHEL split as easy as it can be, and getting many of the internal Red Hat issues out of the way.

ACTION ITEM

  • MaxSpevack will make sure the FedoraSummit page is up to date, has an agenda, all that managerial-type stuff.

RPM

  • need to fill this part in with info from BillNottingham

Other

  • GregDeKoenigsberg and JeremyKatz are putting together some data on comparative numbers of package contributors in various distributions to understand how well the community in Fedora is doing.
  • MikeMcGrath is doing great work with metrics. MaxSpevack is going to ask him if we can make those numbers public somewhere, rather than having them just be shared in emails to various folks.
  • MaxSpevack will speak with Mark Webbink, such that we can make some stronger statements about NTFS code than we have previously, as well as the implications (though we believe there are none, we want to make sure) of any Mono code as a result of the Novell/Microsoft deal.