You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2009/01/06 01:30:44 UTC
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
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, arkurth@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_kurth@ncsu.edu
> 919.513.4090
>
>
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
Posted by Matt Hogstrom <ma...@hogstrom.org>.
The desired process is what the community decides it is. A good
measure of success of the process is where people don't say, wow,
where did that come from. Its always a balance to figure out how to
be most productive and be community oriented at the same time.
Keeping a number of other folks informed about what your doing outside
of code drops feels like chugging through mud at times. Alan's
suggestions of using JIRA was exactly that, just a suggestion. The
community needs to determine what they like and they can always change
it over time as the community dynamics change as well.
On Jan 6, 2009, at 11:48 AM, Aaron Peeler wrote:
> We fully agree and understand the meaning of the community.
> Communication is vital.
>
> But my main point is we still need to know the desired process flow
> of what is expected. To date we have not been informed of the proper
> steps. So having a process outlined is important.
>
> This isn't something we're doing on the side, (supporting VCL - the
> production system at NCSU and it's development), it is our full-time
> focus.
>
> We'll start working on the suggestions Alan mentioned below as a
> starting point, but again we'd appreciate a quick bullet list of
> do's and don'ts as soon as someone gets the chance.
>
> Aaron
>
>
>
> --On January 6, 2009 11:21:00 AM -0500 Kevan Miller <kevan.miller@gmail.com
> > wrote:
Re: svn commit: r730210 -
/incubator/vcl/branches/before-modularized-os/
Posted by Aaron Peeler <aa...@ncsu.edu>.
We fully agree and understand the meaning of the community. Communication
is vital.
But my main point is we still need to know the desired process flow of what
is expected. To date we have not been informed of the proper steps. So
having a process outlined is important.
This isn't something we're doing on the side, (supporting VCL - the
production system at NCSU and it's development), it is our full-time focus.
We'll start working on the suggestions Alan mentioned below as a starting
point, but again we'd appreciate a quick bullet list of do's and don'ts as
soon as someone gets the chance.
Aaron
--On January 6, 2009 11:21:00 AM -0500 Kevan Miller
<ke...@gmail.com> wrote:
>
> On Jan 6, 2009, at 10:13 AM, Alan D. Cabrera wrote:
>
>> 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.
>
> Alan raises excellent points. The absolute key is communication via
> public discussion on the dev list. Wiki roadmaps and jira issues are
> nice, but not sufficient. Public discussions are what allow "communities"
> to form and grow.
>
> Some of the specifics (e.g. Jira issues for all svn commits) are a
> community decision. There's no getting around the communication
> requirement.
>
> --kevan
>
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 6, 2009, at 10:13 AM, Alan D. Cabrera wrote:
> 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.
Alan raises excellent points. The absolute key is communication via
public discussion on the dev list. Wiki roadmaps and jira issues are
nice, but not sufficient. Public discussions are what allow
"communities" to form and grow.
Some of the specifics (e.g. Jira issues for all svn commits) are a
community decision. There's no getting around the communication
requirement.
--kevan
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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" <list@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, arkurth@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_kurth@ncsu.edu
>>> 919.513.4090
>>>
>>>
>>
>
>
>
> Aaron Peeler
> OIT Advanced Computing
> College of Engineering-NCSU
> 919.513.4571
> http://vcl.ncsu.edu
>
Re: svn commit: r730210 -
/incubator/vcl/branches/before-modularized-os/
Posted by Aaron Peeler <aa...@ncsu.edu>.
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"
<li...@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, arkurth@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_kurth@ncsu.edu
>> 919.513.4090
>>
>>
>
Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu