31
edits
User:Edransch/BalrogReport: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
<h2> 1.0 INTRODUCTION </h2> | <h2> 1.0 INTRODUCTION </h2> | ||
<p>The Release Engineering team at Mozilla is currently working on implementing a new piece of software to serve updates to Firefox and Thunderbird users. The aim with the new update server, code named Balrog, is to address the pain points in the current implementation of the update server (AUS2). One such area of weakness for AUS2 is the administration of the server and database to modify the updates that are served to Firefox users. | <p>The Release Engineering team at Mozilla is currently working on implementing a new piece of software to serve updates to Firefox and Thunderbird users. The aim with the new update server, code named Balrog, is to address the pain points in the current implementation of the update server (AUS2). One such area of weakness for AUS2 is the administration of the server and database to modify the updates that are served to Firefox users. AUS2 lacks a web interface, being controlled only via the command line and requires manual adjustment. Thus, Balrog’s administrative interface is an essential part of the project. The target audience of the administrative interface for Balrog is currently Mozilla’s Release Engineering team, but may be expanded in the future to include the Release Management team. There are many possible use cases for the administrative interface that need to be addressed. With limited resources available to work on the project, the Release Engineering team must evaluate new features carefully and allocate resources accordingly. | ||
This report examines some possible use cases and features for Balrog’s administrative interface and analyses their viability for inclusion in the project. The features considered are rollback functionality (single change and previous-state rollback), history view, editing JSON dictionaries (blobs), displaying the difference between (diffing) JSON blobs, help documentation, adding release manager access to Balrog, and visualizing how incoming requests are handled by rules. The main criteria used to analyze the above use cases and features are inclusion in existing goals statements, value of the feature, complexity of design and implementation. In this report, the amount of time required to implement a feature will be approximated by “small” meaning less than one week, “moderate” meaning one to two weeks, and “large” meaning more than two weeks. All estimations in this report assume approximately one developer is working full time on the project. | This report examines some possible use cases and features for Balrog’s administrative interface and analyses their viability for inclusion in the project. The features considered are rollback functionality (single change and previous-state rollback), history view, editing JSON dictionaries (blobs), displaying the difference between (diffing) JSON blobs, help documentation, adding release manager access to Balrog, and visualizing how incoming requests are handled by rules. The main criteria used to analyze the above use cases and features are inclusion in existing goals statements, value of the feature, complexity of design and implementation. In this report, the amount of time required to implement a feature will be approximated by “small” meaning less than one week, “moderate” meaning one to two weeks, and “large” meaning more than two weeks. All estimations in this report assume approximately one developer is working full time on the project. | ||
</p> | </p> | ||