Categorieën
LibrePlan

LibrePlan book is in the works, LibrePlan present at T-DOSE conference

Hi all,

I just wanted to give you all an update on what I have been bussy with.

To me one of the most important things is to let you all know that I am currently working very hard on the LibrePlan book. It will be my 10th book but the first one I have written in English.  I guess I need one more month to finish it. When it’s ready, I will publish it on my own space on lulu.com, like all my other books. If you have ideas of things you would really like to see in the book, just drop me an email.

The other newsbit is that the LibrePlan project will be presented at the upcoming T-DOSE conference (www.t-dose.org). At our booth will be a nice/huge LibrePlan banner and the LibrePlan people will wear nice sweaters with LibrePlan logo.

At the T-DOSE conference there will also be a small joke at the LibrePlan booth as you can see in the next image:

20131009_122657_web

We hope to see as many people as possible at the T-DOSE event. So join us!

Kind regards,

Jeroen Baten

Categorieën
LibrePlan

New developments in the Jira-Libreplan connector

We have been bussy! 🙂

It turns out that montly timesheets are NOT the best way to handle Jira worklogs!

Initially we thought that developers would make a Jira worklog in a daily basis. But allthough I can mandate that as a manager, there people in the rest of the world who might do this differently and just enter a worklog of say, 80 hours. So storing that in a LibrePlan monthly timesheet wouldn’t make any sense.

We could store the worklog in a standard LibrePlan timesheet but that way we would not be able to use any additional comments that the developer would have written in the worklog. So we decided to store worklogs in a new LibrePlan timesheet, based on the default timesheet but with an additional summary or comment field. This can easily been done by making a new timesheet template and adding an extra field.

The other thing is, and now it becomes fancy (!), we can calculate the progress of the task since we also get the estimated time from Jira. So if we divide the sum of all worklogs by the estimated time, we get a progress estimation! So we also store that as a progress report on the date the sync is done.

But now it becomes tricky. Suppose someone changes the estimation. Let’s say he doubles it. That means that the progess estimation drops to halve of what is was. This is currently not possible to do manually in LibrePlan, but we are going ahead and doing it anyway in our code. This way, the progress shown in the task is accurate, still the new estimated duration of the task is not. However, the amount of worklogs can be shown in a bar above the task so when that one exceed the length of the task it is a clear signal to a projectmanager to look into that and, if needed, change the amount of time the task needs.

All this new stuff looks pretty fancy and I can’t wait to show a screenshot of it. We are still building so you just have to wait a bit. I will post an update as soon as possible.

In the mean time, I have started to write the book “LibrePlan, the missing manual”. It currently contains 30 pages of newbie course material and I want to write a lot more. I will publish it on my own Lulu.com page when it is done. I am using Asciidoc so I intend to keep the  book as up to date as possible in the future.

Categorieën
Geen categorie

Ubuntu geinstalleerd. En dan?

Om een lang verhaal heel kort te maken; kijk hier maar eens naar!

http://debianhelp.wordpress.com/2012/03/09/to-do-list-after-installing-ubuntu-12-04-lts-aka-precise-pangolin/

Categorieën
Geen categorie

Getting data out of Jira using a REST interface and Python

It is a lot easier than I expected. Have fun with it! Example code:

#!/usr/bin/python
# Author: J. Baten
# Date: 2012-04-10
import urllib, urllib2, cookielib, json
# set up cookiejar for handling URLs
cookiejar = cookielib.CookieJar()
myopener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
jira_serverurl="http://server:8080/jira"
# Search using JQL
queryJQL = "updated >= -1d"
IssuesQuery = {"jql" : queryJQL,"startAt" : 0,"maxResults" : 1000 }
queryURL = jira_serverurl + "/rest/api/latest/search"
req = urllib2.Request(queryURL)
req.add_data(json.dumps(IssuesQuery))
req.add_header("Content-type", "application/json")
req.add_header("Accept", "application/json")
fp = myopener.open(req)
data = json.load(fp)
#print json.dumps(data,sort_keys=True, indent=2)
#print data["issues"]
for k in  data["issues"]:
print k["key"]
#just take the last one for testing
a=k["key"]
#now how can I get their worklogs?
# /api/2.0.alpha1/issue/{issueKey}
queryURL = jira_serverurl + "/rest/api/latest/issue/" + a
# override for testing purposes
queryURL = jira_serverurl + "/rest/api/latest/issue/ZANDBAK-15"
print queryURL
req = urllib2.Request(queryURL)
#req.add_data(json.dumps(IssuesQuery))
#req.add_header("Content-type", "application/json")
req.add_header("Accept", "application/json")
fp2 = myopener.open(req)
data2 = json.load(fp2)
print json.dumps(data2,sort_keys=True, indent=2)
print "Original estimate :" + str(data2["fields"]["timetracking"]["value"]["timeoriginalestimate"])
print "Current estimate :" + str(data2["fields"]["timetracking"]["value"]["timeestimate"])
# /api/2.0.alpha1/serverInfo
fp2.close()
fp.close()

Categorieën
Geen categorie

Migrating from cvs to git

Hello,

Starting in a new job I was confronted with the use of a CVS repository. Needless to say, I wanted to migrate that to GIT. I found out there are several ways to do this, some bad, some better. I first started to use cvs2svn to convert to subversion and after that ‘git svn clone’ to do the second step. Turns out that where the first step takes approx 1,5 hours, the second step can take between 4 and 10 days! I started to use my Ubuntu workstation first and switched to some nice hardware but running CentOS 5. Unfortunately the standard cvs2svn rpm in the repo is rather old.

Finally I found the best way and it goes like this:

Get the latest cvs2git source from its project page (http://cvs2svn.tigris.org/). I used 2.3. It is a python thing. Next, analyse the script below and copy and tune it. It will make you happy (unless you are into S&M, than I would recommend doing it the hard way using the native cvs2svn rpm on a CentOS 5 system).

This script will migrate a 2 Gb CVS repo in approx 1.5 hours to a git repo. Good luck and happy hacking.

#!/bin/bash
export PYTHONPATH=/home/intrazis/jeroen/cvs-to-git-conversion/cvs2svn-bin/usr/lib/python2.4/site-packages/
export PATH=/home/intrazis/jeroen/cvs-to-git-conversion/cvs2svn-bin/usr/bin:$PATH
p=`pwd`
> cvs2git.log
date >> cvs2git.log 2>&1
echo "Resetting stuff"  >> cvs2git.log 2>&1
rm -rf cvs2git-tmp
mkdir cvs2git-tmp
#rm -rf cvsroot
rm -rf git-repo
mkdir  git-repo
# copie the cvs repo you have to this server
echo "copie repo"
scp -r  user@server:/var/cvsroot .
echo "Ready scp"  >> cvs2git.log 2>&1
date >> cvs2git.log 2>&1

##############################################################################################
#+ cvs2svn --pass=3 --retain-conflicting-attic-files --encoding=ascii --encoding=utf8 --encoding=utf16 --fallback-encoding=utf8 --dumpfile=svndump --write-symbol-info=symbol-info.txt cvsroot
#----- pass 3 (CollateSymbolsPass) -----
#Checking for forced tags with commits...
#The following paths are not disjoint:
#    Path tags/csource contains the following other paths: tags/csource/BasicHTML, tags/csource/IzInit, tags/csource/Login, tags/csource/include,
#Please fix the above errors and restart CollateSymbolsPass
#
#hacking the cvsroot files to boldly go and remove the tag 'csource' .
#  grep -R --exclude=*.gif,v "csource:" cvsroot/*
echo "hacking the cvsroot files to boldly go and remove the tag 'csource' ."  >> cvs2git.log 2>&1
for file in `grep -lR  "csource:" cvsroot/*`
do
  sed -i -e 's/csource:/csource-org:/' $file
done
echo "======================================================="  >> cvs2git.log 2>&1
date >> cvs2git.log 2>&1
##############################################################################################
# put all possible options into the cvs2git.options file. An example is available in the cvs2git python source
cvs2git --options=cvs2git.options >> cvs2git.log 2>&1
date >> cvs2git.log 2>&1
mkdir git-repo
cd  git-repo
date >> cvs2git.log 2>&1
git init  >> cvs2git.log 2>&1
date >> cvs2git.log 2>&1
#Load the dump files into the new git repository using git fast-import:
#
#git fast-import --export-marks=../cvs2svn-tmp/git-marks.dat < ../cvs2svn-tmp/git-blob.dat
#git fast-import --import-marks=../cvs2svn-tmp/git-marks.dat < ../cvs2svn-tmp/git-dump.dat #This can, of course, be shortened to: # echo "Start fast-import off dump and blob files"  >> cvs2git.log 2>&1
cat ../cvs2git-tmp/git-blob.dat ../cvs2git-tmp/git-dump.dat | git fast-import
echo "ready"  >> cvs2git.log 2>&1
date >> cvs2git.log 2>&1
cd ..