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!
Regards,
Alan
On Jan 6, 2009, at 6:02 AM, Aaron Peeler wrote:
Alan,
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.
Regards,
Aaron
--On January 5, 2009 4:30:44 PM -0800 "Alan D. Cabrera" <l...@toolazydogs.com
> 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
comments?
Regards,
Alan
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, xCAT.pm for example, implements a common
set of generically-named subroutines. These are called by the core
VCL modules such as new.pm or image.pm.
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
complete.
Regards,
Andy
Alan D. Cabrera wrote:
On Dec 30, 2008, at 10:31 AM, arku...@apache.org wrote:
Author: arkurth
Date: Tue Dec 30 10:31:23 2008
New Revision: 730210
URL: http://svn.apache.org/viewvc?rev=730210&view=rev
Log:
Copied trunk to branches/before-modularized-os. This was done
before making a large commit to trunk for the modularized OS/Vista
code.
Added:
incubator/vcl/branches/before-modularized-os/
- copied from r730209, incubator/vcl/trunk/
What is this "modularized OS/Vista code" work?
Regards,
Alan
--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_ku...@ncsu.edu
919.513.4090
Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu
