1. Andrew Elwell <Andrew.Elwell@cern.ch> White Areas, October 2009
The Savannah CLI
Andrew Elwell
White Areas, October 2009

2. Background Savannah chosen as patch/bug/task manager
It doesn't have an API
The ease of adding new projects (groups) means that field names vary.
Produces 'pretty' HTML rather than 'parsable'
PHP / MySQL
Mothballed development
Although esr did a svn checkin on 15 Oct.
“Typo fix, test commit”
4 checkins to trunk since Dec 2007
White Areas - Savannah CLI

3. Automated savannah access
How?
Duplicating patches
Closing old bugs
Checking validity of patch metadata
.... etc
White Areas - Savannah CLI

4. … Choice. The problem is choice.
White Areas - Savannah CLI

5. CLI Mk 1.x … before my time (don't blame me)
Still in CVS as legacy code.
Maintenance updates only
Syntax sucks
Mandatory params are -i item, -o operation
Optional params depended on operation
Slow.
Many required python packages aren't current
Field names hard coded for jra1mdw (gLite Middleware)
White Areas - Savannah CLI

6. I need some information first. Just the basic facts:
Relax.
I need some information first.
Just the basic facts:
Can you show me where it hurts?
White Areas - Savannah CLI

7. usage White Areas - Savannah CLI Usage: savannah
-h --help Show this help
-l --login Allows the user to explicitly log in Savannah
-V --verbose Activate progress messages
Mandatory parameter:
-t --tracker Savannah tracker [patch,bugs]
-o --operate Operations (see below for supported operations)
Optional parameter (depending on operation):
-i --item Savannah item number
-n --name Savannah parameter name
-v --value New value/comment
-g --group Savannah group (for gLite this is jra1mdw)
-f --file File containing submit information in xml format
-a --att_tracker Tracker of the new attached item [patch, bugs, task]
Supported operations are:
Operation | req options
attach Attach item v (tracker | [i,a,v]
specified with a) to item i |
comment Add a comment | [i,v]
set Set value | [i,n,v]
list List available values | [i]
list_dependencies List the dependencies | [i]
get Get a parameter | [i,n]
get_available Get available values | [i,n]
for selectbox |
clone clone (priority not cloned) | [i,g]
submit submit a new item | [g,f]
White Areas - Savannah CLI

8. Why does it suck? Overly complex syntax.
Should be able to update multiple things at once (as per web page)
… without needing an XML fetish
Close an old bug and add a comment
./cli –bug 1234 –set status=wontfix --comment “it's not a bug, it's a feature”
./cli --tracker bugs --item 1234 –operate set –name status –value wontfix ; ./cli --tracker bugs --item 1234 –operate comment –value “it's not a bug, it's a feature”
White Areas - Savannah CLI

9. What you see on these screens up here is a fantasy; a computer enhanced hallucination!
White Areas - Savannah CLI

10. Towards 2.0 (1)
Decruft
Separate out config file for each savannah group
Which can be auto-generated by a script as needed
Adding new fields to savannah needn't be a hassle.
code_2_platform = {
"100": "None",
"101": "SL4",
"102": "SL5", }
<select name="platform_version_id">
<option value="100">None</option>
<option value="101">SL4</option>
<option value="102" selected="selected">SL5</option>
<option value="103">Debian 4</option>
<option value="104">Debian 5</option>
White Areas - Savannah CLI

11. Towards 2.0 (2) Allow searching to retrieve result set
Work on multiple results in a set
Work across multiple trackers (likely to need wrapper)
./generate_task –patch 1000,1001,1002 –assign horat \
–comment “more BDII patches for you”
./cli –search 'Pre-Production release'='3.1.0 PPS Update 51” --set Release='3.1.0 Update 57' –set status='in production'
Hmm, why is patch #3204 still 'in pre-production' when it has a value in the Release field? </aside>
White Areas - Savannah CLI

12. Who uses it? What for? Mailing List (savannah-cli-users)
Moved development to SVN
runk/
Stick requirements/bugs in trac,mail,or twiki
But TELL ME THEM
I can file as 'wontfix' too
White Areas - Savannah CLI

13. Results 'Ready for Review' change of bugs
Patch => released, bugs 'fix (not) certified' => 'ready for review'
Working, unglamorous solution
Foreach bug in patch:
If status=fix certified/fix not certified:
./cli -bug $bug –set status='ready for review”
Else complain
White Areas - Savannah CLI

14. How? James already used the XKCD comic BeautifulSoup is wonderful
Even if my Python-fu is weak
selects = soup.find('table').findAll('select')
for sel in selects:
sel_name = sel['name']
print "SELECT NAME=%s" % sel_name
for o in sel.findAll('option'):
print " %s, %s" % (o['value'],o.renderContents())
White Areas - Savannah CLI

15. Patch by Danika Adds interactive mode and submit_all bulk upload
Moves some things from savannah.foo to self.foo
Someone else looked at the code! \o/
I've not merged it tho.
Yet.
White Areas - Savannah CLI

16. Th- Th-Th-Th-Th-... That's all, folks.
Questions?
White Areas - Savannah CLI