Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
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 > wrote:
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
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 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/
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/
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" > 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
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
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" 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
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, 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
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
Looks like it's a good chunk of work. However, working in this manner whereby huge checkins appear with little or no discussion is extremely frowned upon in the ASF. Maybe this was something that you were working on before the incubation started. However, it still would have been nice to get a heads up as to what was cooking in the kitchen and, even better, solicited opinions and help. 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
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
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
Re: svn commit: r730210 - /incubator/vcl/branches/before-modularized-os/
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
