RE: [eclipse.org-planning-council] eclipse.org server usage patterns ver

["Mik Kersten" <beatmik@xxxxxxx>]

Title: New Page 1

I think that this is a great idea.  Traditionally much of the web infrastructure gets based on web browser based clients.  We’re in exciting times now with increased usage of rich Eclipse-based clients, and I couldn’t agree more that the usage patterns of these need to be considered as part of the infrastructure policies.  Rich clients have potential to both provide additional user value while providing use of network resources then web browser clients.  For example, in Mylyn we continually find ways to be more lazy about retrieving bug contents over the network, and Mylyn users aren’t affected by bugs.eclipse.org slowness because they never wait synchronously for it to respond.  

 

In addition to the Team/CVS client, I would like to add the following two to the list to be considered as first-class clients to eclipse.org services:

 

Mylyn (bugs.eclipse.org)

·         We need a policy for outages.  To date the informal Bugzilla Upgrade policy has worked well (we get notified and have at least a couple of weeks to test against the new Bugzilla before it goes live).  We would like to extend that policy to any significant changes of Bugzilla service to avoid outages like bug 205249.

·         We can provide the contributor community with additional features that can reduce the burden of bug triage and would like feedback to help prioritize such features or to solicit contributions for them with mechanisms like the Summer of Code (e.g., bug 205196, bug 150278).

 

Update Manager (download.php)

·         Mirroring and other redirect semantics that work for web browsers result in problems for the Update Manager, which causes confusion when the Update Manager fails to find a feature or dependency (e.g., bug 205348 and bug 204860).

 

Mik

 

From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Bjorn Freeman-Benson
Sent: Wednesday, October 03, 2007 9:38 AM
To: Cross project issues; eclipse.org-planning-council; 'Denis Roy'; Mike Milinkovich; emo@xxxxxxxxxxx
Subject: [eclipse.org-planning-council] eclipse.org server usage patterns versus new innovative tools

 

Planning Council, Cross Projects List, EMO,

The eclipse.org IT infrastructure (cvs, svn, bugzilla, wiki, eclipsecon, etc) is designed to support current usage patterns and expected growth to those patterns. Innovation in frameworks and tools can affect those usage patterns. I think we should write up a policy for how Eclipse projects should assist the EMO in planning for usage pattern changes.

For example, our CVS system is designed around the historic usage pattern of developers syncing up with the HEAD, doing some work, then committing their changes, iterating a few times a day, maybe a dozen times a day. But what if the Team-CVS project team wanted to include a "automatically check for changes" feature in the Team-CVS code. If the automatic part ran frequently (every few minutes), this might impose a large load on the eclipse.org CVS servers and bandwidth - a dramatic change to the usage pattern. And yet we don't want to discourage innovation like this because it could be a great feature for end users.

We (the EMO) would want to be involved in design decisions so that we can understand what the usage pattern changes and their impacts will be. And we'd like to be involved in web-api design so that there are ways for us to throttle back the bandwidth/resources at critical times (e.g., the big June release and the last week before EclipseCon). For example, the hypothetical Team-CVS feature could utilize a reply code from the servers to throttle back how often it checks for updates. Etc.

I've started a wiki page for comments: http://wiki.eclipse.org/Eclipse.Org_Usage_Patterns_Policy
- Bjorn

--
[end of message]