Re: [mentors] guidelines for contributing large modifications
Did you get your questions answered? Regards, Alan On Jun 2, 2010, at 10:26 AM, Kiran N wrote: The plan sounds good to me! I have a question regarding the development phase of the code changes. Since the changes are huge, do we maintain different revisions of the complete code or just the changed modules are recorded/maintained. Also, what would be the procedure for the testing of the submitted code. Do we have anything called as unit test plans anywhere in the repository? If yes, that would be helpful..! On Tue, Jun 1, 2010 at 2:13 PM, Matt Hogstrom m...@hogstrom.org wrote: Great start Josh ... +1 On Jun 1, 2010, at 11:26 AM, Josh Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (This message is to everyone in the community. I added [mentors] to the subject to help our mentors know it is of particular importance for them to read.) After reading Reg: JIRA issue VCL-202 by Kiran N sent on May 28, I realized we need some guidelines for contributing large modifications to the project. This is the general work flow I'd like to see happen for large modifications. Please provide comments and suggestions. Everyone's input is welcome (and desired) -- if you are interested in becoming a committer, this would be a great place to step up involvement. (1) State on the vcl-dev list what modification you'd like to make. Some background on why the existing codebase doesn't work in your situation would be useful. Remember, when you modify existing code, it affects work being done by other contributors, which can result in imposing additional work on them. (2) Propose a plan on the vcl-dev list for making the modification. There may be others that want the same modification or something similar that can be incorporated at the same time. Those people can help develop the modification. On the other hand, the modification may have a very negative affect on some other part of the project. Also, this provides an opportunity for existing contributors (those who know the codebase well) to provide input on your plan. The plan needs to include how the modification will be maintained in the future - will you continue to maintain it; will existing contributors have to pick it up and maintain it? (3) Create a JIRA issue to track implementation of the plan and start developing. This provides a way for others to track work being done on the modification and ensures information about the modification will be added to the CHANGELOG when the next release is cut. Thanks Josh - -- - --- Josh Thompson Systems Programmer Advanced Computing | VCL Developer North Carolina State University josh_thomp...@ncsu.edu my GPG/PGP key can be found at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkwFJr0ACgkQV/LQcNdtPQNZqwCfYyeB99JT3vxuBs9+gpn+v5vs BWYAn2D5HK/Cvo1Kd5CtpEqFpsJBR8bo =dYgS -END PGP SIGNATURE- -- Thanks, Kiran
Re: [mentors] guidelines for contributing large modifications
The plan sounds good to me! I have a question regarding the development phase of the code changes. Since the changes are huge, do we maintain different revisions of the complete code or just the changed modules are recorded/maintained. Also, what would be the procedure for the testing of the submitted code. Do we have anything called as unit test plans anywhere in the repository? If yes, that would be helpful..! On Tue, Jun 1, 2010 at 2:13 PM, Matt Hogstrom m...@hogstrom.org wrote: Great start Josh ... +1 On Jun 1, 2010, at 11:26 AM, Josh Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (This message is to everyone in the community. I added [mentors] to the subject to help our mentors know it is of particular importance for them to read.) After reading Reg: JIRA issue VCL-202 by Kiran N sent on May 28, I realized we need some guidelines for contributing large modifications to the project. This is the general work flow I'd like to see happen for large modifications. Please provide comments and suggestions. Everyone's input is welcome (and desired) -- if you are interested in becoming a committer, this would be a great place to step up involvement. (1) State on the vcl-dev list what modification you'd like to make. Some background on why the existing codebase doesn't work in your situation would be useful. Remember, when you modify existing code, it affects work being done by other contributors, which can result in imposing additional work on them. (2) Propose a plan on the vcl-dev list for making the modification. There may be others that want the same modification or something similar that can be incorporated at the same time. Those people can help develop the modification. On the other hand, the modification may have a very negative affect on some other part of the project. Also, this provides an opportunity for existing contributors (those who know the codebase well) to provide input on your plan. The plan needs to include how the modification will be maintained in the future - will you continue to maintain it; will existing contributors have to pick it up and maintain it? (3) Create a JIRA issue to track implementation of the plan and start developing. This provides a way for others to track work being done on the modification and ensures information about the modification will be added to the CHANGELOG when the next release is cut. Thanks Josh - -- - --- Josh Thompson Systems Programmer Advanced Computing | VCL Developer North Carolina State University josh_thomp...@ncsu.edu my GPG/PGP key can be found at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkwFJr0ACgkQV/LQcNdtPQNZqwCfYyeB99JT3vxuBs9+gpn+v5vs BWYAn2D5HK/Cvo1Kd5CtpEqFpsJBR8bo =dYgS -END PGP SIGNATURE- -- Thanks, Kiran
[mentors] guidelines for contributing large modifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (This message is to everyone in the community. I added [mentors] to the subject to help our mentors know it is of particular importance for them to read.) After reading Reg: JIRA issue VCL-202 by Kiran N sent on May 28, I realized we need some guidelines for contributing large modifications to the project. This is the general work flow I'd like to see happen for large modifications. Please provide comments and suggestions. Everyone's input is welcome (and desired) -- if you are interested in becoming a committer, this would be a great place to step up involvement. (1) State on the vcl-dev list what modification you'd like to make. Some background on why the existing codebase doesn't work in your situation would be useful. Remember, when you modify existing code, it affects work being done by other contributors, which can result in imposing additional work on them. (2) Propose a plan on the vcl-dev list for making the modification. There may be others that want the same modification or something similar that can be incorporated at the same time. Those people can help develop the modification. On the other hand, the modification may have a very negative affect on some other part of the project. Also, this provides an opportunity for existing contributors (those who know the codebase well) to provide input on your plan. The plan needs to include how the modification will be maintained in the future - will you continue to maintain it; will existing contributors have to pick it up and maintain it? (3) Create a JIRA issue to track implementation of the plan and start developing. This provides a way for others to track work being done on the modification and ensures information about the modification will be added to the CHANGELOG when the next release is cut. Thanks Josh - -- - --- Josh Thompson Systems Programmer Advanced Computing | VCL Developer North Carolina State University josh_thomp...@ncsu.edu my GPG/PGP key can be found at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkwFJr0ACgkQV/LQcNdtPQNZqwCfYyeB99JT3vxuBs9+gpn+v5vs BWYAn2D5HK/Cvo1Kd5CtpEqFpsJBR8bo =dYgS -END PGP SIGNATURE-
Re: [mentors] guidelines for contributing large modifications
On Jun 1, 2010, at 8:26 AM, Josh Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (This message is to everyone in the community. I added [mentors] to the subject to help our mentors know it is of particular importance for them to read.) After reading Reg: JIRA issue VCL-202 by Kiran N sent on May 28, I realized we need some guidelines for contributing large modifications to the project. This is the general work flow I'd like to see happen for large modifications. Please provide comments and suggestions. Everyone's input is welcome (and desired) -- if you are interested in becoming a committer, this would be a great place to step up involvement. (1) State on the vcl-dev list what modification you'd like to make. Some background on why the existing codebase doesn't work in your situation would be useful. Remember, when you modify existing code, it affects work being done by other contributors, which can result in imposing additional work on them. (2) Propose a plan on the vcl-dev list for making the modification. There may be others that want the same modification or something similar that can be incorporated at the same time. Those people can help develop the modification. On the other hand, the modification may have a very negative affect on some other part of the project. Also, this provides an opportunity for existing contributors (those who know the codebase well) to provide input on your plan. The plan needs to include how the modification will be maintained in the future - will you continue to maintain it; will existing contributors have to pick it up and maintain it? (3) Create a JIRA issue to track implementation of the plan and start developing. This provides a way for others to track work being done on the modification and ensures information about the modification will be added to the CHANGELOG when the next release is cut. Seems reasonable to me. Regards, Alan
Re: [mentors] guidelines for contributing large modifications
Great start Josh ... +1 On Jun 1, 2010, at 11:26 AM, Josh Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (This message is to everyone in the community. I added [mentors] to the subject to help our mentors know it is of particular importance for them to read.) After reading Reg: JIRA issue VCL-202 by Kiran N sent on May 28, I realized we need some guidelines for contributing large modifications to the project. This is the general work flow I'd like to see happen for large modifications. Please provide comments and suggestions. Everyone's input is welcome (and desired) -- if you are interested in becoming a committer, this would be a great place to step up involvement. (1) State on the vcl-dev list what modification you'd like to make. Some background on why the existing codebase doesn't work in your situation would be useful. Remember, when you modify existing code, it affects work being done by other contributors, which can result in imposing additional work on them. (2) Propose a plan on the vcl-dev list for making the modification. There may be others that want the same modification or something similar that can be incorporated at the same time. Those people can help develop the modification. On the other hand, the modification may have a very negative affect on some other part of the project. Also, this provides an opportunity for existing contributors (those who know the codebase well) to provide input on your plan. The plan needs to include how the modification will be maintained in the future - will you continue to maintain it; will existing contributors have to pick it up and maintain it? (3) Create a JIRA issue to track implementation of the plan and start developing. This provides a way for others to track work being done on the modification and ensures information about the modification will be added to the CHANGELOG when the next release is cut. Thanks Josh - -- - --- Josh Thompson Systems Programmer Advanced Computing | VCL Developer North Carolina State University josh_thomp...@ncsu.edu my GPG/PGP key can be found at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkwFJr0ACgkQV/LQcNdtPQNZqwCfYyeB99JT3vxuBs9+gpn+v5vs BWYAn2D5HK/Cvo1Kd5CtpEqFpsJBR8bo =dYgS -END PGP SIGNATURE-
