To the new VTR Administrator,

Thank you for taking up the responsibility of being the administrator for the 
VTR project. The VTR project provides a dependable software baseline from which 
other researchers may use to launch their new FPGA research ideas. For the VTR 
infrastructure to be useful, the many different components necessary to conduct 
architecture experiments must stay compatible with each other.  This responsibility 
falls to you, the VTR administrator.  The rest of this document describes the details of your role.

Developers on the VTR project will look to you for guidance.  So the first thing 
you should do is familiarize yourself with the duties of a normal developer.  
This information is found in the New Developer Tutorial in this folder as well 
as the readme files of the trunk.

The VTR trunk is supposed to represent the most up-to-date, stable, version of 
the software.  However, with many collaborators working together, inevitably 
someone will commit code in such a way that makes the trunk unstable.  
Developers working on the project sync with the trunk regularly so an unstable 
trunk will slow down their work. Hence, it is important to monitor the trunk and 
get whoever breaks it to fix it ASAP.  This is where buildbot comes in handy.  
Whenever anyone commits code, our buildbot setup will automatically compile the 
code then run some regression tests.  Buildbot flags problems and reports who 
made which commit.  The VTR buildbot website is located here: 
http://canucks.eecg.toronto.edu:8080/ It gives you regular updates on the state 
of thet trunk. As the administrator, you should check buildbot regularly (eg. 
once a day in the morning). When the trunk breaks, e-mail the person who broke 
it.  Details of the management of the buildbot system itself should already be 
e-mailed out.

People using VTR will report issues to either the wiki or the e-mail 
vpr@eecg.utoronto.ca. The VTR project wiki is located here: 
https://code.google.com/p/vtr-verilog-to-routing/ You should also add your 
e-mail to the vpr@eecg mailing list.  When an issue gets flagged, you should 
triage the issue to whoever is responsible or reject the issue as invalid.  When 
there is nobody to pass an issue to, unfortunately, the issue falls on you.

How much support you are willing to give other researchers is up to your own 
discretion.  I encourage helping others because it builds a friendly research 
community.  But there will come a time when the support that someone requires 
exceeds what you can reasonably supply.  In such a case, a polite response of 
"I'm sorry, the support that you require is beyond what I can provide" is a good 
diplomatic way to decline providing assistance.

Finally, you are responsible for the maintenance of the wiki and list of 
contributors to the project.

There are benefits being the point man for VTR.  By virtue of having to keep the 
system as a whole working, you will become knowledgeable with every part.  When 
you meet others in conferences, talking about your work is also much easier 
because many have experience with the VTR tools.  Lastly, if you have an 
interest in visiting other universities, some are interested in hearing a talk 
about the latest developments in the tool.


- Jason Luu

Former VTR Administrator