You've made a good point. Rather than generating the process in an ad hoc fashion, we should whip one up as soon as possible.

There are no standard development processes in the ASF. There are rules about releases and what can go into them. The ASF likes to let projects define the specifics how they want to work. There are, however, guiding principles that influence how projects define their process. The top priority is building and maintaining community.

This priority takes precedence over everything else. It can be frustrating at times and this is usually the hardest for new projects to grok. But it is so important that building and maintaining community takes equal weight in the eyes of the Incubator PMC to code base vetting. So important that this is the usual reason that incubated projects take longer than expected to graduate or, worse, are withdrawn.

So with that in mind, here's a phrase that has me worries "We have a lot of work/submissions over the next couple of months". There's been no discussion on this list about architectural/feature additions and modifications. This worries me. We're not a SourceForge where code can be developed externally then dumped into our repositories when it's done.

With that said, I invite the current project team to come up with a development process that makes planning and development transparent. You should be thinking of ways to get more members of the community involved in this project. Part of this is requiring architectural and development conversations in public on this list. Simply posting roadmaps and Jira issues won't do. You should not be having development meetings at your office as you previously have done. It precludes involvement of the community.

Finally, some tactical advice. Never work on anything unless there's a Jira issue for it. When you check in your code place the Jira issue number in the checkin comment, e.g. "VCL-325 added SNMP MIBs to storage management". This allows products such as Fisheye to index the two together. Road maps are great. Architectural diagrams are great. Creating Jira issues for everything that you will do or want to do is great. It allows people to volunteer to pick up work or offer to help. I will remind you that community is the raison d'etre for VCL being here. This means that no person "owns" a chunk of technology. If a person is working on a a corner of this project and someone else wants to help that person must be accommodating and share the work; there is no such thing as "dibs" on an area of architecture.

Whew! That's a lot of words to swallow. Thanks for sticking with us so far!


On Jan 6, 2009, at 6:02 AM, Aaron Peeler wrote:


Could you define the process for checking in new code, modifications, or bug fixes.

This is the first we've seen or heard of having to add Jira issue numbers.

Also, we've not found anything yet in the Apache guides which defines this process, so if you have any links, please forward them.

We're willing and wanting to do this right but we would like to know the specific process. We have a lot of work/submissions over the next couple of months, so if we could get the process nailed down on our end that will save a lot of time and reduce the frustration on changing our work habits.


--On January 5, 2009 4:30:44 PM -0800 "Alan D. Cabrera" < > wrote:

Andy, I'm seeing more checkins w/out Jira issue numbers in them. Would you mind making sure that everything on your plate has a Jira issue and
that all your checkins have their corresponding Jira # in the checkin


On Dec 30, 2008, at 12:10 PM, Andy Kurth wrote:

Hi Alan,
This is to add management node support for Windows Vista.  I have
been working on getting VCL to support Vista and it's now in a
working state.  We will use Vista as a proof of concept for the OS
modularization design since its initial use will be minimal.

OS modularization is an extension to the major changes made from
version 1.x to 2.0.  Prior to 2.0, calls to interact with different
components which VCL utilizes or supports were intermingled
throughout the code and controlled by if/else statements.  This made
the task of adding support for additional components difficult.

Starting with version 2.0, we modularized the parts of the code
which interact with the provisioning engines.  We use the term
"provisioning engine" to mean the systems which can perform the
basic tasks to prepare a machine.  The provisioning engines
currently supported are xCAT 1.3, VMWare, and an interface to
utilize NCSU's Solaris lab machines when the labs are closed.  Each
provisioning engine module, for example, implements a common
set of generically-named subroutines.  These are called by the core
VCL modules such as or

Also for version 2.0, the predictive reloading logic has been
modularized in the same manner.  This is the algorithm used to
determine which image is loaded on a machine when a reservation is


Alan D. Cabrera wrote:
On Dec 30, 2008, at 10:31 AM, wrote:
Author: arkurth
Date: Tue Dec 30 10:31:23 2008
New Revision: 730210

Copied trunk to branches/before-modularized-os. This was done
before making a large commit to trunk for the modularized OS/Vista

   - copied from r730209, incubator/vcl/trunk/

What is this "modularized OS/Vista code" work?

Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University

Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU

Reply via email to