perfsonar development work

[Loukik Kudarimoti <>]

Thanks to Google cache and Joe (for the clue), I got the cached pages 
(1st version of these pages) see below.


Loukik Kudarimoti wrote:
> Szymon Trocha wrote:
> > Dear all,
> >
> > Minutes from ISS session are already available here:
> > http://wiki.perfsonar.net/jra1-wiki/index.php/ISS-Session-10-Jan-07
> >
> > They include discussion and decisions on: SVN structure, versioning, 
> > service naming scheme, docs, installation testing and eventType.
> >
> > You can also see actions marked "A".
> Szymon,
>
> All the minutes have been wiped out because of the wiki outage. I 
> suppose you have the original notes. Can you please restore them as 
> some of the agreements are quite important for the next few months.
>
> Maciej,
>
> Can you please increase the backup frequency for our wiki. This will 
> help because the content on our wiki tends to be changed on a daily 
> basis. I suppose a backup frequency as high as once in two-days or 
> even once a day (at midnight) will be helpful for such crashes.
>
> Loukik.
>
>
> > Regards,


 *ISS-Session*-10-Jan-07


      From GEANT2-JRA1 Wiki

[edit 
<http://wiki.perfsonar.net/jra1-wiki/index.php?title=ISS-Session-10-Jan-07&action=edit&section=1>]


     Minutes of *ISS session* 10th January 2007

*A*(all): As soon as RC is published make bugs antries in Bugzilla

*SVN structure*

Proposal

https://svn.internet2.edu/svn/perfsonar/trunk/
https://svn.internet2.edu/svn/perfsonar/trunk/perfsonar-base/
https://svn.internet2.edu/svn/perfsonar/trunk/perfsonar-bundle/
https://svn.internet2.edu/svn/perfsonar/trunk/perfsonar-doc/   --- templates, 
samples, management documents,
https://svn.internet2.edu/svn/perfsonar/trunk/perfsonar-mgmt/ --- all 
management related documents  - to be evaluated
https://svn.internet2.edu/svn/perfsonar/trunk/GN2_JAVA-RRDMA/
https://svn.internet2.edu/svn/perfsonar/trunk/GN2_JAVA-XMLLS/
https://svn.internet2.edu/svn/nmwg/trunk/nmwg/doc/  --- all schemas and 
related documents
https://svn.perfsonar.net/svn/perfson/trunk/perfsonar-bundle/doc/install.txt
https://svn.perfsonar.net/svn/perfsonar/trunk/perfsonar-downloads/   --- tar 
files of all our service releases

Release tags and branches proposals

https://svn.internet2.edu/svn/perfsonar/tags/JAVA-RRD-MA-1.1/
https://svn.internet2.edu/svn/perfsonar/tags/JAVA-RRD-MA-1.1.1/

*Versioning*

LK: Numbering is important for users so that they can see whether it's 
compatible

RL: What if some services of the bundle changed schema while the others 
didn't?

LK: Should be then upgarded to upper version. This should be done in 
future by the installation script whether to upgrade services when the 
new bundle comes. Automatic updates should be available from the 3rd 
release.

ST: From users perspective service numbers within bundle should be 
transparent.

RL: What if a user wants to install a single service?

LK: He should use a budle then. Even for a single service - it would be 
a preferred way of service installations.

*A*(all): Major number of service version will indicate protocol change. 
NUmbering of individual services can be different from bundle number

*A*(all): psBase is a set of classes which can be used by developers. 
psBase versioning will also take place using the same schema as 
individual services.

*A*(LK): To find a person who will take care of psBase versioning

*Naming scheme*

The group agreed on naming criteria:

   * Should be uniquely identifable
   * Must include unique project name
   * Could include category e.g. rrdma or ls

*A*(all): Use the following naming scheme for projects:

projectname_[language|metric|category]*
*optional, can be combination fo some of them

Underscore required between projectname and the latter part Version 
number could be added to tar file or release tag

RL: Who is in the Steering Commitee? Decisions should be more 
transparent and explained to the audience.

*A*(JB): Create mailing list for the Steering Committee

*Documentation*

*A*(all): Keep functional and interface specifications separate

*A*(all): Continue with RNC file included for the current release but 
review it later on

*A*(MS): Evaluate tools for creating application documentation like 
docbook. Send example of tools to the mailing list.

*Installation testing*

*A*(MG): Produce tar file for LS in order to start installation testing

LM: We should have a similar look for installation process for different 
services

*A*(LK): Define what should be in which step of installation (in Wiki)

*A*(ST): Investigate how SVN structure can be used for docs and how to 
move from Wiki to SVN as well as what to remove (end of January)

LK: In future the installation should be Web-based

RL: We need to find benefits first to decide

*A*(all): Wait for users' feedback on current installation scripts and 
then decide

LM: Improvement on user's documentation is a must

RL: We don't have any how-tos and faq now.

*A*(LK): Work on a simple how-tos/FAQ on a Web page

*A*(all): Evaluate perl/ant installation scripts in order to choose perl 
or ant scripts for future

*A*(all): RC tags should be kept over release but removed afterwards 
apart from leaving the last one and possibly renaming it instead of "RCx".

*A*(all): When bug fix is done this particular tag should be copied to 
branches directory

*A*(all): We should maintain a particular version of dependencies across 
all services

*A*(all): jar files should not be collected in one place on SVN. Just 
use URLs. Developers should use reliable project dependencies.

*A*(all): tar files for release bundles can be place on SVN in Downloads 
directory

*eventType*

JB: We must use fully qualified names defined by NMWG instead of just 
"untilisation". These names are already defined in schema but not 
documented enough. This change affects the value not namespace.

*A*(JB): To send proposal to the mailing list for accepting

*A*(MS): To send to the mailing list information about a new group in OGF