committers/list-of-infra-requests-8-Dec-2005.php - www.eclipse.org/projects - Git at Google

 <?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'

 $pageTitle 		= "Committer Infrastructure Requests";
 $pageKeywords	= "committers";
 $pageAuthor		= "Bjorn Freeman-Benson Nov 20/05";

 ob_start();
 ?>
     <div id="maincontent">
 	<div id="midcolumn">
         <h1><?= $pageTitle ?></h1>

 <p>This list of Eclipse.org infrastructure requests was  collected from the
 committer community by Committer Board Representatives John Wiegand and Bjorn
 Freeman-Benson. Weighted votes were tallied and <a href="slides.pdf">presented at the Dec 8th Board
 Meeting</a>. (For your reference, the "item#"s are the original numbers given to the
 list items for voting reference.)</p>
 <ul>
   <li>1. (item# 1) <b>Project Dashboard/Statistics.</b> Number of bugs, number of new bugs, number
   of fixed bugs, downloads, page views, mailing list messages, et.</li>
   <li>2. (item #19) <b>Bugzilla.</b> The current bug tracking mechanism/tool imposes lots of
   work on the committers doing the bug triage. Given that most of us spent a
   noticeable amount of time in Bugzilla there should be improvements to make
   committer's live easier.
   <ul>
     <li>Bugs are often incomplete or duplicates of existing bugs. Other projects
     for example have mandatory fields (e.g. the build id) and show a list of
     possible related bugs which the bug reporter can check for duplicates before
     reporting a new one. </li>
     <li>Searching is also a problem since stack traces are often in attachments
     which aren't searched. Stack traces are good means to find duplicates.
     However stack traces are often attached. So search in attachments must be
     supported as well.</li>
     <li>Better UI so that bug reporters don't forget to report essential
     information (build number, log entries, reproducible steps, ....)</li>
     <li>In general Bugzilla should find duplicate candidates and should present
     them to the bug reporter before the bug gets committed.</li>
   </ul>
   </li>
   <li>3. (item #16) <b>Newer Faster Hardware.</b> Implement new, faster hardware with a
   scalable architecture and redundancy for core services. The current
   eclipse.org hardware is not sufficient for the for current services provided.
   In addition, it is not scalable for increases in traffic. Nor is it highly
   available in the in the event of hardware failure. This new hardware needs to
   be implemented before additional services can be implemented. This will
   improve the performance of several core eclipse.org services such as Bugzilla
   and cvs.
   <ul>
     <li>And more bandwidth. Lags of a minute or more on bugzilla and CVS are
     hurting productivity and changing the very nature of the interactions that
     have been so successful in creating Eclipse so far.</li>
   </ul>
   </li>
   <li>4. (item #20) <b>Committer Control Over Web Content</b>. Whatever form: blogs, wikis, or
   other web content flavour of the month. We just want to be able to create a
   page for some current issue or plan item, and be able to create a reasonably
   short URL for it. This current issue list is a good example. I had to stick
   that list into the webtools project space even though it is unrelated to web
   tools. Similarly, the &quot;RCP&quot; home page is in the platform UI team's web site
   viewable only through viewcvs. There are many cross-component, and sometimes
   cross-project, issues that need web space. These currently have to be hosted
   within a single component's web space and only that team will have commit
   rights to it.</li>
   <li>5. (item #11) <b>Subversion.</b> In addition to CVS</li>
   <li>6. (item #7) <b>Short URLs</b>. Direct (short) URLs to project sections, a.k.a., no
   frames. Definitely no frames.</li>
   <li>7. (item #18) <b>Additional Sysadmin/Webdev.</b> Acquire additional system administration
   resources. Currently, the Eclipse Foundation currently has only one system
   administrator to manage all the servers, respond to all user requests and
   implement changes. This is a tremendous amount of work for one person. In the
   event of illness, vacation or other issues, there isn't anyone to back him up.
   Given the importance of these servers to eclipse.org community, this is not a
   sufficient allocation of resources. This would also improve response time to
   committer requests. (see also 25)<ul>
     <li>To quote one of the many committers who voiced this opinion &quot;I've always
     found our website to be an embarrassment -- but I've accepted its current
     state since I value a kick-ass platform more than a nice website! But it is
     time this changes, we don't have a choice. The community is getting too
     large and our tooling is getting in the way of our productivity.&quot;</li>
   </ul>
   </li>
   <li>8. (item# 2) <b>Wikis</b>. Per-project would probably be best. (also see 20)</li>
   <li>9. (item #8) <b>Per-project navigation bars.</b> Managed by the project.</li>
   <li>10. (item #15) <b>
   Self Management</b>. Creating new components, managing mailing
   lists, adding/removing committers, ..., more sourceforge-like Use workflow management for IP crucial tasks like
   adding new committers (requires EMO
   interaction, but parts can be self-managed)<ul>
     <li>It sure would be nice if whatever system we use/produce could be
     packaged like <a href="http://www.gforge.org">GForge</a>, the software that
     ObjectWeb uses, and made available for others who want a collaboration
     system like we have built.</li>
     <li>Or maybe just work with GForge to build whatever enhancements we need
     into their system. We would benefit by having something to start from. They
     would benefit from whatever enhancements we build for them...</li>
   </ul>
   </li>
   <li>11. (item #21) <b>Moderated Mailing Lists</b>. A small set of mailing lists (eclipse-dev,
   platform-ui-dev, possibly swt-dev) could benefit from a moderator. High
   density of traffic on the newsgroup means that many people have trouble
   getting their questions answered there. They have begun to turn to the mailing
   lists as an alternative to newsgroups for getting answers. This is not
   surprising - questions on the mailing list are often answered within minutes.
   However, if the larger volume of traffic catches on to the idea of using the
   mailing lists for user questions, then we will lose a valuable communication
   tool for commiters. Perhaps a visible user mailing list would help, but I
   think having the ability to switch to moderated lists (starting with
   eclipse-dev) is the easiest solution. This moderation would not have to be
   stringent - just turn away obvious user questions and point them to the
   appropriate newsgroup. There are many committers who would be happy to
   participate in a rotating moderator position for eclipse-dev. Better one
   committer dealing with the spam than wasting the time of hundreds of people by
   letting these messages through.</li>
   <li>12. (item# 3) <b>Blogs</b>. Per-project or per-component or per-individual? (also see
   20)</li>
   <li>13. (item #6) <b>Reputation System</b>. No community can function without a reputation
   system. Online communities with large growth rates are especially vulnerable
   because the new members do not have the history that helps them filter the
   good from the bad. A reputation system (like E-bay's seller ratings) is
   necessary. (also see 21)<ul>
     <li>The idea here is to capture the communities trust in specific
     individuals in a formal way so that other people can view that trust.
     Obviously, committers would have to be in a high trust/high reputation space
     in order to be committers. So this is more applicable to non-committers on
     the newsgroups and mailing lists.</li>
     <li>There have been at least three (one very recently) disruptive individual
     on the newsgroups. To a newbie, there is no way to tell whether this vocal
     person is knowledgeable or just noisy; whether I, the newbie, should trust
     them or ignore them.</li>
     <li>The EMF system has a
     <a href="http://download.eclipse.org/tools/emf/scripts/models.php">trivial
     version of this</a>.</li>
   </ul>
   </li>
   <li>14. (item #9) <b>Proposals Section</b>. A proposals section (Eclipse Labs?) to nurture
   new proposals instead of hosting them at other companies or at sourceforge.</li>

   <li>15. (item #12) <b>Servlets and JSP</b>. For active, rather than static, project web pages.<ul>
     <li>Which quite naturally also means MySQL and read/write file-system space
     for configuration and/or data files in case a servlet isn't complicated
     enough to justify using a database.</li>
   </ul>
   <li>16. (item #14) <b>Central Password Authentication System.</b> Implement a central
   password authentication scheme such as ldap for as many services as possible
   (download server, Bugzilla, cvs etc). Currently, each user authenticates
   against separate password files on each server. </li>
   <li>17. (item #17) <b>Leverage Mirrors.</b> Leverage the mirrors to reduce bandwidth. (see
     also 26)
   <ul>
     <li>One idea Bjorn had was to limit the bandwidth available to each person
     per time unit (suggestions available) and then to charge a nominal fee ($1?)
     for an extra download.&nbsp; Use Paypal to clear payments. Structure this to
     hit only those who download three copies of the SDK in a single day.</li>
     <li>Give the mirrors higher QoS than straight downloads and then encourage
     high use clients (companies such as IBM and HP) to have internal mirrors.
     IBM already does this.</li>
     <li>Automatically redirect users to a geographically close mirror based on
     the locale setting in their browser. They can only download from the main
     apache site as a last resort. This is what the Apache project
     <a href="http://httpd.apache.org/download.cgi">does</a>.</li>
     <li>Mirroring of <i>all</i> projects, not just the platform.</li>
   </ul>
   </li>
   <li>18. (item #10) <b>RSS and Atom.</b> For all blogs, wikis, and web pages.</li>
   <li>19. (item #13) <b>PHP/MySQL.</b> Some projects would prefer to use PHP rather than
   servlets and JSP.</li>
   <li>20. (item #24) <b>QoS Bandwidth Throttling</b>. Allow certain people/machines higher
   bandwidth. For example, mirrors and build machines should have higher priority
   access to the bandwidth than an average download. (see also 26)</li>
   <li>21. (item #26) <b>BitTorrent.</b> Eclipse's Update Manager should support BitTorrent
     protocol. Eclipse's download servers ideally should too.<br>
     It doesn't matter how many mirrors we have because if we are successful
     getting people to use Update Manager, UM is hard-coded to go to the main
     Eclipse.org download site. This obviously won't scale. But enabling a
     peer-to-peer protocol like BitTorrent within Update Manager would alleviate
     this, since BitTorrent causes the clients to also serve the content while
     they are downloading. So, your main download server sees roughly constant
     bandwidth utilization as as the number of downloads increases rather than
     linear or geometric utilization...</li>
   <li>22. (item #25) <b>Distributed Infrastructure Monitoring and Trouble Tickets</b>. During
   the most recent milestone, we had problems with both Bugzilla and CVS going
   down. Redundancy would be nice, but ultimately, committers need to be able to
   bring these services back up if things go wrong. Right now, we feel like we
   don't have the tools we need to communicate with the infrastructure team. We
   don't know what to do if we notice a service has gone down, and we never hear
   whether the infra team is aware of a problem or when it is fixed. It also
   might be nice to distribute some system administrator accounts to non-eclipse.org
   people.</li>
   <li>23. (item #23) <b>CVS Mirroring</b>. Mirror the CVS tree as well as the downloads tree.</li>
   <li>24. (item #22) <b>CVS Proxy Support</b>. Support for proxy support for accessing CVS from
   inside a firewall. SourceForge already supports this and is very useful for
   helping committers/contributors from other companies to work with us. </li>
   <li>25. (item# 4) <b>Hierarchical Blogs.</b> The blogs should be linked hierarchically so
   that big news items can bubble up like they do on the SourceForge news system.
   The idea is that when someone in, say, VEP publishes a blog entry, John D
   (over in Tools) would be notified, and with the click of a button, could
   promote the entry to be visible on the Tools project's weblog. And if John D
   promotes it, it would then be forwarded to an Eclipse.org content manager who
   could then click a button to make it visible as an Eclipse front-page news
   item. (also see 20)<ul>
     <li>This would subsume an event repository for project-specific Whats new. Can be tagged
   and queued for the home page.</li>
   </ul>
   </li>
   <li>26. (item #5) <b>EMO Web Content. </b>In particular, presence (website, wikis, blogs,
   mailing lists, cvs, ...) for processes, councils, etc.</li>
 </ul>

 <p>If you are a committer or contributor, we encourage you to
 let us know what your
 infrastructure requests are so that we can lobby for them at the Board meetings.
 What are your additional requests that are not on the list?</p>

 <p>P.S. The <a href="/emf">EMF</a> project seems to have a
 few of these features. For example:</p>

 <ul>
   <li>Our site's What's New is an XML file which is written to automagically
   with every new build promoted to Eclipse. Code for this automagic process is
   in CVS in /home/tools/, emf-home/emf-builds/scripts/. See promoteToEclipse.sh</li>
   <li>We also have a What's New, CVS? application that takes one-week snapshots
   of deltas in CVS, generates those snaps as XML, and then styles that with
   PHP+XSL in order to make it searchable/sortable/filterable.</li>
 </ul>

 <?php
 	# Paste your HTML content between the EOHTML markers!
 	$html = ob_get_contents();
 	ob_end_clean();

 	# Generate the web page
 	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
 ?>
	<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop'

	$pageTitle = "Committer Infrastructure Requests";
	$pageKeywords = "committers";
	$pageAuthor = "Bjorn Freeman-Benson Nov 20/05";

	ob_start();
	?>
	<div id="maincontent">
	<div id="midcolumn">
	<h1><?= $pageTitle ?></h1>

	<p>This list of Eclipse.org infrastructure requests was collected from the
	committer community by Committer Board Representatives John Wiegand and Bjorn
	Freeman-Benson. Weighted votes were tallied and <a href="slides.pdf">presented at the Dec 8th Board
	Meeting</a>. (For your reference, the "item#"s are the original numbers given to the
	list items for voting reference.)</p>
	<ul>
	<li>1. (item# 1) <b>Project Dashboard/Statistics.</b> Number of bugs, number of new bugs, number
	of fixed bugs, downloads, page views, mailing list messages, et.</li>
	<li>2. (item #19) <b>Bugzilla.</b> The current bug tracking mechanism/tool imposes lots of
	work on the committers doing the bug triage. Given that most of us spent a
	noticeable amount of time in Bugzilla there should be improvements to make
	committer's live easier.
	<ul>
	<li>Bugs are often incomplete or duplicates of existing bugs. Other projects
	for example have mandatory fields (e.g. the build id) and show a list of
	possible related bugs which the bug reporter can check for duplicates before
	reporting a new one. </li>
	<li>Searching is also a problem since stack traces are often in attachments
	which aren't searched. Stack traces are good means to find duplicates.
	However stack traces are often attached. So search in attachments must be
	supported as well.</li>
	<li>Better UI so that bug reporters don't forget to report essential
	information (build number, log entries, reproducible steps, ....)</li>
	<li>In general Bugzilla should find duplicate candidates and should present
	them to the bug reporter before the bug gets committed.</li>
	</ul>
	</li>
	<li>3. (item #16) <b>Newer Faster Hardware.</b> Implement new, faster hardware with a
	scalable architecture and redundancy for core services. The current
	eclipse.org hardware is not sufficient for the for current services provided.
	In addition, it is not scalable for increases in traffic. Nor is it highly
	available in the in the event of hardware failure. This new hardware needs to
	be implemented before additional services can be implemented. This will
	improve the performance of several core eclipse.org services such as Bugzilla
	and cvs.
	<ul>
	<li>And more bandwidth. Lags of a minute or more on bugzilla and CVS are
	hurting productivity and changing the very nature of the interactions that
	have been so successful in creating Eclipse so far.</li>
	</ul>
	</li>
	<li>4. (item #20) <b>Committer Control Over Web Content</b>. Whatever form: blogs, wikis, or
	other web content flavour of the month. We just want to be able to create a
	page for some current issue or plan item, and be able to create a reasonably
	short URL for it. This current issue list is a good example. I had to stick
	that list into the webtools project space even though it is unrelated to web
	tools. Similarly, the "RCP" home page is in the platform UI team's web site
	viewable only through viewcvs. There are many cross-component, and sometimes
	cross-project, issues that need web space. These currently have to be hosted
	within a single component's web space and only that team will have commit
	rights to it.</li>
	<li>5. (item #11) <b>Subversion.</b> In addition to CVS</li>
	<li>6. (item #7) <b>Short URLs</b>. Direct (short) URLs to project sections, a.k.a., no
	frames. Definitely no frames.</li>
	<li>7. (item #18) <b>Additional Sysadmin/Webdev.</b> Acquire additional system administration
	resources. Currently, the Eclipse Foundation currently has only one system
	administrator to manage all the servers, respond to all user requests and
	implement changes. This is a tremendous amount of work for one person. In the
	event of illness, vacation or other issues, there isn't anyone to back him up.
	Given the importance of these servers to eclipse.org community, this is not a
	sufficient allocation of resources. This would also improve response time to
	committer requests. (see also 25)<ul>
	<li>To quote one of the many committers who voiced this opinion "I've always
	found our website to be an embarrassment -- but I've accepted its current
	state since I value a kick-ass platform more than a nice website! But it is
	time this changes, we don't have a choice. The community is getting too
	large and our tooling is getting in the way of our productivity."</li>
	</ul>
	</li>
	<li>8. (item# 2) <b>Wikis</b>. Per-project would probably be best. (also see 20)</li>
	<li>9. (item #8) <b>Per-project navigation bars.</b> Managed by the project.</li>
	<li>10. (item #15) <b>
	Self Management</b>. Creating new components, managing mailing
	lists, adding/removing committers, ..., more sourceforge-like Use workflow management for IP crucial tasks like
	adding new committers (requires EMO
	interaction, but parts can be self-managed)<ul>
	<li>It sure would be nice if whatever system we use/produce could be
	packaged like <a href="http://www.gforge.org">GForge</a>, the software that
	ObjectWeb uses, and made available for others who want a collaboration
	system like we have built.</li>
	<li>Or maybe just work with GForge to build whatever enhancements we need
	into their system. We would benefit by having something to start from. They
	would benefit from whatever enhancements we build for them...</li>
	</ul>
	</li>
	<li>11. (item #21) <b>Moderated Mailing Lists</b>. A small set of mailing lists (eclipse-dev,
	platform-ui-dev, possibly swt-dev) could benefit from a moderator. High
	density of traffic on the newsgroup means that many people have trouble
	getting their questions answered there. They have begun to turn to the mailing
	lists as an alternative to newsgroups for getting answers. This is not
	surprising - questions on the mailing list are often answered within minutes.
	However, if the larger volume of traffic catches on to the idea of using the
	mailing lists for user questions, then we will lose a valuable communication
	tool for commiters. Perhaps a visible user mailing list would help, but I
	think having the ability to switch to moderated lists (starting with
	eclipse-dev) is the easiest solution. This moderation would not have to be
	stringent - just turn away obvious user questions and point them to the
	appropriate newsgroup. There are many committers who would be happy to
	participate in a rotating moderator position for eclipse-dev. Better one
	committer dealing with the spam than wasting the time of hundreds of people by
	letting these messages through.</li>
	<li>12. (item# 3) <b>Blogs</b>. Per-project or per-component or per-individual? (also see
	20)</li>
	<li>13. (item #6) <b>Reputation System</b>. No community can function without a reputation
	system. Online communities with large growth rates are especially vulnerable
	because the new members do not have the history that helps them filter the
	good from the bad. A reputation system (like E-bay's seller ratings) is
	necessary. (also see 21)<ul>
	<li>The idea here is to capture the communities trust in specific
	individuals in a formal way so that other people can view that trust.
	Obviously, committers would have to be in a high trust/high reputation space
	in order to be committers. So this is more applicable to non-committers on
	the newsgroups and mailing lists.</li>
	<li>There have been at least three (one very recently) disruptive individual
	on the newsgroups. To a newbie, there is no way to tell whether this vocal
	person is knowledgeable or just noisy; whether I, the newbie, should trust
	them or ignore them.</li>
	<li>The EMF system has a
	<a href="http://download.eclipse.org/tools/emf/scripts/models.php">trivial
	version of this</a>.</li>
	</ul>
	</li>
	<li>14. (item #9) <b>Proposals Section</b>. A proposals section (Eclipse Labs?) to nurture
	new proposals instead of hosting them at other companies or at sourceforge.</li>

	<li>15. (item #12) <b>Servlets and JSP</b>. For active, rather than static, project web pages.<ul>
	<li>Which quite naturally also means MySQL and read/write file-system space
	for configuration and/or data files in case a servlet isn't complicated
	enough to justify using a database.</li>
	</ul>
	<li>16. (item #14) <b>Central Password Authentication System.</b> Implement a central
	password authentication scheme such as ldap for as many services as possible
	(download server, Bugzilla, cvs etc). Currently, each user authenticates
	against separate password files on each server. </li>
	<li>17. (item #17) <b>Leverage Mirrors.</b> Leverage the mirrors to reduce bandwidth. (see
	also 26)
	<ul>
	<li>One idea Bjorn had was to limit the bandwidth available to each person
	per time unit (suggestions available) and then to charge a nominal fee ($1?)
	for an extra download.  Use Paypal to clear payments. Structure this to
	hit only those who download three copies of the SDK in a single day.</li>
	<li>Give the mirrors higher QoS than straight downloads and then encourage
	high use clients (companies such as IBM and HP) to have internal mirrors.
	IBM already does this.</li>
	<li>Automatically redirect users to a geographically close mirror based on
	the locale setting in their browser. They can only download from the main
	apache site as a last resort. This is what the Apache project
	<a href="http://httpd.apache.org/download.cgi">does</a>.</li>
	<li>Mirroring of <i>all</i> projects, not just the platform.</li>
	</ul>
	</li>
	<li>18. (item #10) <b>RSS and Atom.</b> For all blogs, wikis, and web pages.</li>
	<li>19. (item #13) <b>PHP/MySQL.</b> Some projects would prefer to use PHP rather than
	servlets and JSP.</li>
	<li>20. (item #24) <b>QoS Bandwidth Throttling</b>. Allow certain people/machines higher
	bandwidth. For example, mirrors and build machines should have higher priority
	access to the bandwidth than an average download. (see also 26)</li>
	<li>21. (item #26) <b>BitTorrent.</b> Eclipse's Update Manager should support BitTorrent
	protocol. Eclipse's download servers ideally should too.<br>
	It doesn't matter how many mirrors we have because if we are successful
	getting people to use Update Manager, UM is hard-coded to go to the main
	Eclipse.org download site. This obviously won't scale. But enabling a
	peer-to-peer protocol like BitTorrent within Update Manager would alleviate
	this, since BitTorrent causes the clients to also serve the content while
	they are downloading. So, your main download server sees roughly constant
	bandwidth utilization as as the number of downloads increases rather than
	linear or geometric utilization...</li>
	<li>22. (item #25) <b>Distributed Infrastructure Monitoring and Trouble Tickets</b>. During
	the most recent milestone, we had problems with both Bugzilla and CVS going
	down. Redundancy would be nice, but ultimately, committers need to be able to
	bring these services back up if things go wrong. Right now, we feel like we
	don't have the tools we need to communicate with the infrastructure team. We
	don't know what to do if we notice a service has gone down, and we never hear
	whether the infra team is aware of a problem or when it is fixed. It also
	might be nice to distribute some system administrator accounts to non-eclipse.org
	people.</li>
	<li>23. (item #23) <b>CVS Mirroring</b>. Mirror the CVS tree as well as the downloads tree.</li>
	<li>24. (item #22) <b>CVS Proxy Support</b>. Support for proxy support for accessing CVS from
	inside a firewall. SourceForge already supports this and is very useful for
	helping committers/contributors from other companies to work with us. </li>
	<li>25. (item# 4) <b>Hierarchical Blogs.</b> The blogs should be linked hierarchically so
	that big news items can bubble up like they do on the SourceForge news system.
	The idea is that when someone in, say, VEP publishes a blog entry, John D
	(over in Tools) would be notified, and with the click of a button, could
	promote the entry to be visible on the Tools project's weblog. And if John D
	promotes it, it would then be forwarded to an Eclipse.org content manager who
	could then click a button to make it visible as an Eclipse front-page news
	item. (also see 20)<ul>
	<li>This would subsume an event repository for project-specific Whats new. Can be tagged
	and queued for the home page.</li>
	</ul>
	</li>
	<li>26. (item #5) <b>EMO Web Content. </b>In particular, presence (website, wikis, blogs,
	mailing lists, cvs, ...) for processes, councils, etc.</li>
	</ul>

	<p>If you are a committer or contributor, we encourage you to
	let us know what your
	infrastructure requests are so that we can lobby for them at the Board meetings.
	What are your additional requests that are not on the list?</p>

	<p>P.S. The <a href="/emf">EMF</a> project seems to have a
	few of these features. For example:</p>

	<ul>
	<li>Our site's What's New is an XML file which is written to automagically
	with every new build promoted to Eclipse. Code for this automagic process is
	in CVS in /home/tools/, emf-home/emf-builds/scripts/. See promoteToEclipse.sh</li>
	<li>We also have a What's New, CVS? application that takes one-week snapshots
	of deltas in CVS, generates those snaps as XML, and then styles that with
	PHP+XSL in order to make it searchable/sortable/filterable.</li>
	</ul>

	<?php
	# Paste your HTML content between the EOHTML markers!
	$html = ob_get_contents();
	ob_end_clean();

	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
	?>