| <?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); |
| ?> |