MozillaWiki

User:Edransch/BalrogReport: Difference between revisions

User page Discussion

User:Edransch/BalrogReport (view source)

Revision as of 01:15, 7 May 2012

80 bytes removed ,  7 May 2012
Undo revision 427767 by Edransch (talk)
No edit summary
(Undo revision 427767 by Edransch (talk))
Line 4: Line 4:
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.
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.
</p><p>2.0 ANALYSIS</p><p>
</p><p>2.0 ANALYSIS</p><p>
<p>&lt;p&gt;Since Balrog administrative interface is in early stages of development, several features are potential candidates for inclusion in the administrative interface. The use cases considered have all been raised by Release Engineers in team meetings as possible important use cases for Balrog’s administrative interface. Some of the examined features are critical to Release Engineerings Q2 goals while others are out of the scope of Balrog’s specification. Whether or not a feature falls under the Q2 goal, a feature’s overall usefulness, and the difficulty of design and implementation must all be considered when examining a feature.
<p>Since Balrog administrative interface is in early stages of development, several features are potential candidates for inclusion in the administrative interface. The use cases considered have all been raised by Release Engineers in team meetings as possible important use cases for Balrog’s administrative interface. Some of the examined features are critical to Release Engineerings Q2 goals while others are out of the scope of Balrog’s specification. Whether or not a feature falls under the Q2 goal, a feature’s overall usefulness, and the difficulty of design and implementation must all be considered when examining a feature.
</p>
</p>
<p>&lt;p&gt;2.1 Rollback Improvements&lt;/p&gt;
</p>
</p>
&lt;p&gt;2.1 Rollback Improvements</p>
<p>
<p>
One important feature of the administrative interface is support for rolling back changes to the database. The simplest rollback functionality to implement is the ability to rollback a single change. The server side code for the first part has already been implemented. The client side code should be fairly straightforward to implement, taking a short amount of time. This feature has high priority as it is required for Balrog to have functional equivalence to AUS2. Thus, it falls under the Q2 goals list and should be completed by June. Since part of this feature is already implemented and functional, and the completion of the feature is a small amount of work, the target of Q2 is realistic and achievable. (and I should probably do it ASAP&#160;:P ) </p>
One important feature of the administrative interface is support for rolling back changes to the database. The simplest rollback functionality to implement is the ability to rollback a single change. The server side code for the first part has already been implemented. The client side code should be fairly straightforward to implement, taking a short amount of time. This feature has high priority as it is required for Balrog to have functional equivalence to AUS2. Thus, it falls under the Q2 goals list and should be completed by June. Since part of this feature is already implemented and functional, and the completion of the feature is a small amount of work, the target of Q2 is realistic and achievable. (and I should probably do it ASAP&#160;:P ) </p>
Line 14: Line 12:
<p>Another potential use case for the Balrog administrative interface is to display a visual representation of the history of the database. As mentioned above, each change to each database table is stored in a separate history table. Currently, these history tables cannot be viewed in the administrative interface. A few distinct use cases are candidates for integration into the History view: viewing information on who made changes, rolling back an entire table to a previous state via the interface, and viewing the state of the database at a specific time.  Information on who made changes is very useful when debugging problems with the server. If it seems like the problem is related to a specific change, the person who made the change can be consulted to help fix the problem. Providing the option to roll back to a previous state in the table will require additional database level code, which is a moderate amount of work. Finally, viewing the site at a specific state could help users verify that they have chosen the correct state before executing a rollback to that state. This last feature in particular requires substantial design and implementation. It would take a large amount of time to complete the design and implementation and should not be explicitly included in a goal for this year. However, viewing the page at a specific state could be implemented separately from the rest of the history view. The other features are more time efficient to implement and will likely take a moderate amount of work to implement. These features are of high value to the project, and should be implemented as soon as possible. They should be targeted at Q4 2012 or Q1 2013.
<p>Another potential use case for the Balrog administrative interface is to display a visual representation of the history of the database. As mentioned above, each change to each database table is stored in a separate history table. Currently, these history tables cannot be viewed in the administrative interface. A few distinct use cases are candidates for integration into the History view: viewing information on who made changes, rolling back an entire table to a previous state via the interface, and viewing the state of the database at a specific time.  Information on who made changes is very useful when debugging problems with the server. If it seems like the problem is related to a specific change, the person who made the change can be consulted to help fix the problem. Providing the option to roll back to a previous state in the table will require additional database level code, which is a moderate amount of work. Finally, viewing the site at a specific state could help users verify that they have chosen the correct state before executing a rollback to that state. This last feature in particular requires substantial design and implementation. It would take a large amount of time to complete the design and implementation and should not be explicitly included in a goal for this year. However, viewing the page at a specific state could be implemented separately from the rest of the history view. The other features are more time efficient to implement and will likely take a moderate amount of work to implement. These features are of high value to the project, and should be implemented as soon as possible. They should be targeted at Q4 2012 or Q1 2013.
</p><p>2.3 JSON Blobs
</p><p>2.3 JSON Blobs
<p>&lt;p&gt;A third important use case for Balrog’s administrative interface is managing the JSON blobs that make up the ‘data’ column in the releases table. These blobs control which file is served for each platform and locale for a release. Unfortunately, they are difficult to edit by hand, since they are very large text files (approximately 500Kb per release). Additionally, it is nearly impossible to notice the differences between two blobs manually. Adding the ability to edit the blobs in an intelligent manner and to view a diff of the files offers a significant convenience gain for Balrog’s administrative interface. However, these features are both very complex. The ideal situation for these features would be that someone has already implemented them and released them under a licence compatible with Mozilla’s. One such implementation for editing JSON is found at jsoneditoronline.com, with source code released under the Apache2.0 licence at https://github.com/wjosdejong/jsoneditoronline.  This tool offers a simple and intuitive tree-based interface for editing JSON. Integrating the tool into Balrog’s current code would be a moderate amount of work. Unfortunately, a web based JSON diff tool of similar polish does not exist. In order for Balrog to move forward, the best solution is to rely on other diff tools for comparing blobs. If an html based diff tool is released in the future (as a Google Summer of Code project, for example), it could be integrated into Balrog. Users can currently download and upload blobs as needed, allowing them to edit blobs in their preferred software on their local machine. Thus, these two features are for convenience only and do not provide any missing functionality. Since neither of these two features is required for the Q2 goal, the integration of the JSON editor should be targeted at Q4 2012, and the JSON diff tool should be monitored and integrated when a suitable tool is available.
<p>A third important use case for Balrog’s administrative interface is managing the JSON blobs that make up the ‘data’ column in the releases table. These blobs control which file is served for each platform and locale for a release. Unfortunately, they are difficult to edit by hand, since they are very large text files (approximately 500Kb per release). Additionally, it is nearly impossible to notice the differences between two blobs manually. Adding the ability to edit the blobs in an intelligent manner and to view a diff of the files offers a significant convenience gain for Balrog’s administrative interface. However, these features are both very complex. The ideal situation for these features would be that someone has already implemented them and released them under a licence compatible with Mozilla’s. One such implementation for editing JSON is found at jsoneditoronline.com, with source code released under the Apache2.0 licence at https://github.com/wjosdejong/jsoneditoronline.  This tool offers a simple and intuitive tree-based interface for editing JSON. Integrating the tool into Balrog’s current code would be a moderate amount of work. Unfortunately, a web based JSON diff tool of similar polish does not exist. In order for Balrog to move forward, the best solution is to rely on other diff tools for comparing blobs. If an html based diff tool is released in the future (as a Google Summer of Code project, for example), it could be integrated into Balrog. Users can currently download and upload blobs as needed, allowing them to edit blobs in their preferred software on their local machine. Thus, these two features are for convenience only and do not provide any missing functionality. Since neither of these two features is required for the Q2 goal, the integration of the JSON editor should be targeted at Q4 2012, and the JSON diff tool should be monitored and integrated when a suitable tool is available.
</p>
</p>
</p>
&lt;/p&gt;<p><br />
</p><p><br />
&lt;p&gt;2.4 Help Documentation
<p>2.4 Help Documentation
An additional important feature of the Balrog administrative interface is the inclusion of help documentation in the web page. This feature has very high priority as Mozilla’s operations scale, since it will help new users gain familiarity with the administrative interface. Additionally, if adding documentation is postponed and new features that are added to the interface before help documentation is introduced, upfront cost of adding documentation will be larger. Therefore, there is significant benefit to implementing help documentation as soon as possible. However, help documentation is not required for Balrog to have functional equivalence with AUS2, so it is not necessary to include it in the Q2 goals. There are some design decisions that need to be made here regarding whether to make the help available on a separate page, or via mouseover tooltips, or separate sections of the same page. These decisions will affect the complexity of the implementation of the feature. Integrating help into the web pages themselves will likely be a large amount of work, with mouseover tooltips being the most complex. Given the complexity of the implementation and the high priority of adding help documentation, this feature should be implemented in 2012, either in Q3 or Q4.
An additional important feature of the Balrog administrative interface is the inclusion of help documentation in the web page. This feature has very high priority as Mozilla’s operations scale, since it will help new users gain familiarity with the administrative interface. Additionally, if adding documentation is postponed and new features that are added to the interface before help documentation is introduced, upfront cost of adding documentation will be larger. Therefore, there is significant benefit to implementing help documentation as soon as possible. However, help documentation is not required for Balrog to have functional equivalence with AUS2, so it is not necessary to include it in the Q2 goals. There are some design decisions that need to be made here regarding whether to make the help available on a separate page, or via mouseover tooltips, or separate sections of the same page. These decisions will affect the complexity of the implementation of the feature. Integrating help into the web pages themselves will likely be a large amount of work, with mouseover tooltips being the most complex. Given the complexity of the implementation and the high priority of adding help documentation, this feature should be implemented in 2012, either in Q3 or Q4.
2.5 Release Manager Access  
2.5 Release Manager Access  
Line 27: Line 24:
Some essential features to Balrog’s administrative interface can be implemented as part of the Q2 goal, others cannot be implemented before this deadline.
Some essential features to Balrog’s administrative interface can be implemented as part of the Q2 goal, others cannot be implemented before this deadline.
</p>
</p>
&lt;/p&gt;<p>It is important to consider the scope and purpose of Balrog’s administrative interface in order to prevent scope creep and ensure the project can move forward.
</p><p>It is important to consider the scope and purpose of Balrog’s administrative interface in order to prevent scope creep and ensure the project can move forward.
</p><p>Some functionality for Balrog’s administrative interface would be useful, but are outside the resources of Mozilla’s Release Engineering team. Leveraging community contributors as well as other open source projects would be extremely valuable.
</p><p>Some functionality for Balrog’s administrative interface would be useful, but are outside the resources of Mozilla’s Release Engineering team. Leveraging community contributors as well as other open source projects would be extremely valuable.
<p>&lt;p&gt;4.0 RECOMMENDATIONS
<p>4.0 RECOMMENDATIONS
Adding interface support for rolling back a single change is an essential feature for Balrog’s administrative interface to be functionally equivalent to AUS2 and should be implemented as part of Release Engineering’s Q2 goal.
Adding interface support for rolling back a single change is an essential feature for Balrog’s administrative interface to be functionally equivalent to AUS2 and should be implemented as part of Release Engineering’s Q2 goal.
</p>
</p>
</p>
</p><p>Displaying a history view for Balrog’s tables opens up possibilities for multiple features. Allowing the user to view the site at a specified state of the history table is out of the immediate scope of Balrog’s administrative interface and should not be prioritized. However, a simple change list view and support for rolling back to a specific state in the database are valuable use cases that should be implemented by Q1 2013.
&lt;/p&gt;<p>Displaying a history view for Balrog’s tables opens up possibilities for multiple features. Allowing the user to view the site at a specified state of the history table is out of the immediate scope of Balrog’s administrative interface and should not be prioritized. However, a simple change list view and support for rolling back to a specific state in the database are valuable use cases that should be implemented by Q1 2013.
</p><p>Blob editing and diffing are problems that are out of the scope of Balrog’s administrative interface. However, existing tools such as jsoneditoronline can be integrated in to Balrog to provide the necessary functionality. Integrating jsoneditoronline is major convenience gain for Balrog administrators and should therefore be targeted at Q4 2012.
</p><p>Blob editing and diffing are problems that are out of the scope of Balrog’s administrative interface. However, existing tools such as jsoneditoronline can be integrated in to Balrog to provide the necessary functionality. Integrating jsoneditoronline is major convenience gain for Balrog administrators and should therefore be targeted at Q4 2012.
</p><p>Adding release manager access is dependent on implementing help documentation. The two features can be developed in parallel and are very important for long term scaling of Mozilla’s release process. However, they are large projects and will require interaction with the Release Management team. The time required to complete them is outside of the time available in 2012. These projects should not be implemented in 2012, but rather should be scheduled for early 2013.
</p><p>Adding release manager access is dependent on implementing help documentation. The two features can be developed in parallel and are very important for long term scaling of Mozilla’s release process. However, they are large projects and will require interaction with the Release Management team. The time required to complete them is outside of the time available in 2012. These projects should not be implemented in 2012, but rather should be scheduled for early 2013.
</p><p>Visualizing the rules in a separate view as a graph is outside of the scope of Balrog’s administrative interface. A simpler view for checking which rules apply to a given incoming request should be implemented. This simpler rules view should be implemented by Q4 2012.
</p><p>Visualizing the rules in a separate view as a graph is outside of the scope of Balrog’s administrative interface. A simpler view for checking which rules apply to a given incoming request should be implemented. This simpler rules view should be implemented by Q4 2012.
</p>
</p>
Edransch
31

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/427768"