[Starlingx-discuss] Python Based VBox Installer
A Python-based installer for StarlingX has been submitted to stx-tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better. The installer is going in via following submission: https://review.openstack.org/#/c/637958/ Numan.
Hi, I just reviewed the tool and I think it's a great tool and it will be really useful for the community. I just have one general question that I would like to extend to the community. Should this tool be supported by a spec? -Erich On Wed, 2019-02-20 at 21:21 +0000, Waheed, Numan wrote:
A Python-based installer for StarlingX has been submitted to stx- tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better.
The installer is going in via following submission: https://review.openstack.org/#/c/637958/
Numan. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi, I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple. Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange. For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design. My .02$, Dariush -----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel.com] Sent: February-20-19 6:21 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer Hi, I just reviewed the tool and I think it's a great tool and it will be really useful for the community. I just have one general question that I would like to extend to the community. Should this tool be supported by a spec? -Erich On Wed, 2019-02-20 at 21:21 +0000, Waheed, Numan wrote:
A Python-based installer for StarlingX has been submitted to stx- tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better.
The installer is going in via following submission: https://review.openstack.org/#/c/637958/
Numan. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush < Dariush.Eslimi@windriver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of the OpenStack code typically does, so organizations could open source internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in that repository could be improved and moved out once it made sense. I think it's worthwhile to have useful internal code open sourced, and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository. Just a thought. :) Thanks, Curtis [1]: https://git.openstack.org/cgit/openstack/osops-tools-contrib/tree/README.rst My .02$,
Dariush
-----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel.com] Sent: February-20-19 6:21 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
Hi,
I just reviewed the tool and I think it's a great tool and it will be really useful for the community. I just have one general question that I would like to extend to the community. Should this tool be supported by a spec?
-Erich
On Wed, 2019-02-20 at 21:21 +0000, Waheed, Numan wrote:
A Python-based installer for StarlingX has been submitted to stx- tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better.
The installer is going in via following submission: https://review.openstack.org/#/c/637958/
Numan. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com
On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote:
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr iver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of the OpenStack code typically does, so organizations could open source internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in that repository could be improved and moved out once it made sense.
I think it's worthwhile to have useful internal code open sourced, and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository.
Just a thought. :)
I really like the idea of having a new repository as a landing zone where things can be stabilize over time. When I started reviewing this tool I noticed that my comments were more focused on design (features that we might not need, restructure of cli arguments and so on) and I understand that fixing this is outside of the scope of sharing an internal tool. So, should be go in the path of creating a new repository? or can we use an "experimental" folder within stx-tools? What do you think about this?
Thanks, Curtis
[1]: https://git.openstack.org/cgit/openstack/osops-tools-contrib/tre e/README.rst
My .02$, Dariush
-----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel. com] Sent: February-20-19 6:21 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; starlingx-discuss@l ists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
Hi,
I just reviewed the tool and I think it's a great tool and it will be really useful for the community. I just have one general question that I would like to extend to the community. Should this tool be supported by a spec?
-Erich
On Wed, 2019-02-20 at 21:21 +0000, Waheed, Numan wrote:
A Python-based installer for StarlingX has been submitted to stx- tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better.
The installer is going in via following submission: https://review.openstack.org/#/c/637958/
Numan. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-disc uss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
On Thu, Feb 21, 2019 at 1:19 PM Cordoba Malibran, Erich < erich.cordoba.malibran@intel.com> wrote:
On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote:
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr iver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of the OpenStack code typically does, so organizations could open source internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in that repository could be improved and moved out once it made sense.
I think it's worthwhile to have useful internal code open sourced, and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository.
Just a thought. :)
I really like the idea of having a new repository as a landing zone where things can be stabilize over time. When I started reviewing this tool I noticed that my comments were more focused on design (features that we might not need, restructure of cli arguments and so on) and I understand that fixing this is outside of the scope of sharing an internal tool.
So, should be go in the path of creating a new repository? or can we use an "experimental" folder within stx-tools?
What do you think about this?
I did put it on the agenda for the TSC meeting that happened earlier today and it was discussed. There were some reasons to have a separate repo, and some not to. It felt like, to me anyways, there were more reasons not to brought up in the meeting, but I'll let others discuss their own reasoning should they want to. :) As an OpenStack Operator who mostly deployed OpenStack and used custom tools to help manage it on Day 2, my perspective may be different than most in terms of sharing tooling that may not have all the Ts crossed and I's dotted in relation to what is now standard open source code quality expectations. Operators are a different sort. :) Thanks, Curtis
Thanks, Curtis
[1]: https://git.openstack.org/cgit/openstack/osops-tools-contrib/tre e/README.rst
My .02$, Dariush
-----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel. com] Sent: February-20-19 6:21 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; starlingx-discuss@l ists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
Hi,
I just reviewed the tool and I think it's a great tool and it will be really useful for the community. I just have one general question that I would like to extend to the community. Should this tool be supported by a spec?
-Erich
On Wed, 2019-02-20 at 21:21 +0000, Waheed, Numan wrote:
A Python-based installer for StarlingX has been submitted to stx- tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better.
The installer is going in via following submission: https://review.openstack.org/#/c/637958/
Numan. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-disc uss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
-- Blog: serverascode.com
On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote:
On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote:
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr iver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of the OpenStack code typically does, so organizations could open source internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in that repository could be improved and moved out once it made sense.
I think it's worthwhile to have useful internal code open sourced, and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository.
Just a thought. :)
I really like the idea of having a new repository as a landing zone where things can be stabilize over time. When I started reviewing this tool I noticed that my comments were more focused on design (features that we might not need, restructure of cli arguments and so on) and I understand that fixing this is outside of the scope of sharing an internal tool.
So, should be go in the path of creating a new repository? or can we use an "experimental" folder within stx-tools?
What do you think about this?
I think that this can land in the stx-tools directory along with the other deployment scripts. As was pointed out in the meeting this morning, this code has been in use within WindRiver for a while now and they are making it available to the community. I think that the initial PR needed to have a better commit message explaining this and a little more thought put into the request before it got reviewed, such as removing the .pyc files, licensing, documentation, the first two where show stopper for me, but easily fixed, documentation could be added later. Sau!
Thanks, Curtis
[1]: https://git.openstack.org/cgit/openstack/osops-tools-contrib/tre e/README.rst
My .02$, Dariush
-----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel. com] Sent: February-20-19 6:21 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; starlingx-discuss@l ists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
Hi,
I just reviewed the tool and I think it's a great tool and it will be really useful for the community. I just have one general question that I would like to extend to the community. Should this tool be supported by a spec?
-Erich
On Wed, 2019-02-20 at 21:21 +0000, Waheed, Numan wrote:
A Python-based installer for StarlingX has been submitted to stx- tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better.
The installer is going in via following submission: https://review.openstack.org/#/c/637958/
Numan. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-disc uss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, February 21, 2019 6:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote:
On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote:
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr iver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of the OpenStack code typically does, so organizations could open source internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in that repository could be improved and moved out once it made sense.
I think it's worthwhile to have useful internal code open sourced, and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository.
Just a thought. :)
I really like the idea of having a new repository as a landing zone where things can be stabilize over time. When I started reviewing this tool I noticed that my comments were more focused on design (features that we might not need, restructure of cli arguments and so on) and I understand that fixing this is outside of the scope of sharing an internal tool.
So, should be go in the path of creating a new repository? or can we use an "experimental" folder within stx-tools?
What do you think about this?
I think that this can land in the stx-tools directory along with the other deployment scripts. As was pointed out in the meeting this morning, this code has been in use within WindRiver for a while now and they are making it available to the community.
I think that the initial PR needed to have a better commit message explaining this and a little more thought put into the request before it got reviewed, such as removing the .pyc files, licensing, documentation, the first two where show stopper for me, but easily fixed, documentation could be added later.
Sau!
Things like the inadvertent inclusion of pyc files (which were already noted in multiple comments in the review) and missing license identifiers seem to be minor and easily correctable mistakes, and maybe not completely unexpected for a “new contributor”. As well, I had also noted in a review comment that this was a long-existing tool that was being published, referencing the email from Numan and asking for the commit message to be updated to explain this. As well, note that this was an optional productivity aid. It does not impact the build, it does not impact any software. It is a tool to help people launch StarlingX in a VirtualBox environment, to aid them in installing and configuring the system. Nobody is required to use it. With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html#... Cheers, Don.
On Mon, Feb 25, 2019 at 10:51 AM Penney, Don <Don.Penney@windriver.com> wrote:
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, February 21, 2019 6:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote:
On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote:
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr iver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of the OpenStack code typically does, so organizations could open source internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in that repository could be improved and moved out once it made sense.
I think it's worthwhile to have useful internal code open sourced, and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository.
Just a thought. :)
I really like the idea of having a new repository as a landing zone where things can be stabilize over time. When I started reviewing this tool I noticed that my comments were more focused on design (features that we might not need, restructure of cli arguments and so on) and I understand that fixing this is outside of the scope of sharing an internal tool.
So, should be go in the path of creating a new repository? or can we use an "experimental" folder within stx-tools?
What do you think about this?
I think that this can land in the stx-tools directory along with the other deployment scripts. As was pointed out in the meeting this morning, this code has been in use within WindRiver for a while now and they are making it available to the community.
I think that the initial PR needed to have a better commit message explaining this and a little more thought put into the request before it got reviewed, such as removing the .pyc files, licensing, documentation, the first two where show stopper for me, but easily fixed, documentation could be added later.
Sau!
Things like the inadvertent inclusion of pyc files (which were already noted in multiple comments in the review) and missing license identifiers seem to be minor and easily correctable mistakes, and maybe not completely unexpected for a “new contributor”. As well, I had also noted in a review comment that this was a long-existing tool that was being published, referencing the email from Numan and asking for the commit message to be updated to explain this.
As well, note that this was an optional productivity aid. It does not impact the build, it does not impact any software. It is a tool to help people launch StarlingX in a VirtualBox environment, to aid them in installing and configuring the system. Nobody is required to use it.
With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here:
https://docs.openstack.org/project-team-guide/review-the-openstack-way.html#...
Sounds like we need to come to a consensus as to when a -2 is appropriate. I personally don't think a -2 is appropriate for a first contribution, regardless of circumstances. Obviously we can't commit .pyc files and need licensing, but I definitely would prefer not to see -2s in this situation. I think this code is important and we need to get this back on track. This is a good "teachable moment" maybe for all sides? :) Thanks, Curtis
Cheers, Don.
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com
On Mon, 2019-02-25 at 11:11 -0500, Curtis wrote:
On Mon, Feb 25, 2019 at 10:51 AM Penney, Don <Don.Penney@windriver.co m> wrote:
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, February 21, 2019 6:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote:
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslim
i@windr
iver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of
OpenStack code typically does, so organizations could open
internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in
repository could be improved and moved out once it made sense.
I think it's worthwhile to have useful internal code open
On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote: the source that sourced,
and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository.
Just a thought. :)
I really like the idea of having a new repository as a landing zone where things can be stabilize over time. When I started reviewing this tool I noticed that my comments were more focused on design (features that we might not need, restructure of cli arguments and so on) and I understand that fixing this is outside of the scope of sharing an internal tool.
So, should be go in the path of creating a new repository? or can we use an "experimental" folder within stx-tools?
What do you think about this?
I think that this can land in the stx-tools directory along with the other deployment scripts. As was pointed out in the meeting this morning, this code has been in use within WindRiver for a while now and they are making it available to the community.
I think that the initial PR needed to have a better commit message explaining this and a little more thought put into the request before it got reviewed, such as removing the .pyc files, licensing, documentation, the first two where show stopper for me, but easily fixed, documentation could be added later.
Sau!
Things like the inadvertent inclusion of pyc files (which were already noted in multiple comments in the review) and missing license identifiers seem to be minor and easily correctable mistakes, and maybe not completely unexpected for a “new contributor”. As well, I had also noted in a review comment that this was a long-existing tool that was being published, referencing the email from Numan and asking for the commit message to be updated to explain this.
As well, note that this was an optional productivity aid. It does not impact the build, it does not impact any software. It is a tool to help people launch StarlingX in a VirtualBox environment, to aid them in installing and configuring the system. Nobody is required to use it.
With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here: https://docs.openstack.org/project-team-guide/review-the-openstack- way.html#code-review-minus-2
Sounds like we need to come to a consensus as to when a -2 is appropriate. I personally don't think a -2 is appropriate for a first contribution, regardless of circumstances. Obviously we can't commit .pyc files and need licensing, but I definitely would prefer not to see -2s in this situation.
I think this code is important and we need to get this back on track. This is a good "teachable moment" maybe for all sides? :)
I agree, we need to get it back. I gave my -2 in the understanding that every new functionality to the project needs a spec and an approval process first. Now that this has been discussed and it's clear we can have this kind of contributions, then I can remove the -2 (the review needs to be restored first) and continue with the review. -Erich
Thanks, Curtis
Cheers, Don.
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 2019-02-25 16:51:21 +0000 (+0000), Cordoba Malibran, Erich wrote: [...]
With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here: https://docs.openstack.org/project-team-guide/review-the-openstack- way.html#code-review-minus-2
Sounds like we need to come to a consensus as to when a -2 is appropriate. I personally don't think a -2 is appropriate for a first contribution, regardless of circumstances. Obviously we can't commit .pyc files and need licensing, but I definitely would prefer not to see -2s in this situation.
I think this code is important and we need to get this back on track. This is a good "teachable moment" maybe for all sides? :)
I agree, we need to get it back. I gave my -2 in the understanding that every new functionality to the project needs a spec and an approval process first. Now that this has been discussed and it's clear we can have this kind of contributions, then I can remove the -2 (the review needs to be restored first) and continue with the review.
Sounds like the use of -2 in that case was more akin to: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html#... Basically, "put this contribution on hold, it can't merge until we have some other discussions." The distinction is easy to miss though, which is why explaining exactly why you voted -2 on a change is critical, as well as stating what you think the next steps are. -- Jeremy Stanley
-----Original Message----- From: Jeremy Stanley [mailto:fungi@yuggoth.org] Sent: Monday, February 25, 2019 12:00 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
On 2019-02-25 16:51:21 +0000 (+0000), Cordoba Malibran, Erich wrote: [...]
With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here: https://docs.openstack.org/project-team-guide/review-the-openstack - way.html#code-review-minus-2
Sounds like we need to come to a consensus as to when a -2 is appropriate. I personally don't think a -2 is appropriate for a first contribution, regardless of circumstances. Obviously we can't commit .pyc files and need licensing, but I definitely would prefer not to see -2s in this situation.
I think this code is important and we need to get this back on track. This is a good "teachable moment" maybe for all sides? :)
I agree, we need to get it back. I gave my -2 in the understanding that every new functionality to the project needs a spec and an approval process first. Now that this has been discussed and it's clear we can have this kind of contributions, then I can remove the -2 (the review needs to be restored first) and continue with the review.
Sounds like the use of -2 in that case was more akin to:
https://docs.openstack.org/project-team-guide/review-the-openstack- way.html#procedural-code-review-2
Basically, "put this contribution on hold, it can't merge until we have some other discussions." The distinction is easy to miss though, which is why explaining exactly why you voted -2 on a change is critical, as well as stating what you think the next steps are. -- Jeremy Stanley
I read the "procedural -2", as well, but it didn't seem applicable here. This section seems to describe a "code freeze", which is not the case here. The description of a "workflow -1" seems to align more with what it sounds like the intent of the -2s were. https://docs.openstack.org/project-team-guide/review-the-openstack-way.html#... Cheers, Don.
On 2019-02-25 18:10:38 +0000 (+0000), Penney, Don wrote: [...]
I read the "procedural -2", as well, but it didn't seem applicable here. This section seems to describe a "code freeze", which is not the case here.
The description of a "workflow -1" seems to align more with what it sounds like the intent of the -2s were. https://docs.openstack.org/project-team-guide/review-the-openstack-way.html#...
The description of a procedural -2 there fails to convey that they're used for a lot more in OpenStack besides just deferring changes until after a code freeze. They tend to get used for any sort of "not now" deferrals which the core reviewers want to remain "sticky" in the face of new patch uploads on the same change. For example, they're commonly applied to block approval of changes are associated with a spec which has been postponed to a subsequent development cycle. Workflow -1 does certainly have some similar connotations, but is more ephemeral and also (primarily) used to simply indicate that a change is a work in progress and so the current patch in it is not yet ready to be reviewed. It gets cleared when a new patch is pushed for the change, since the most common case is that the author expects the next patch to be ready for review. Workflow -1 is also capable of being applied by the change author, whereas a Code-Review -2 can only be applied by a core reviewer on the project. -- Jeremy Stanley
-----Original Message----- From: Jeremy Stanley [mailto:fungi@yuggoth.org] Sent: Monday, February 25, 2019 1:26 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
On 2019-02-25 18:10:38 +0000 (+0000), Penney, Don wrote: [...]
I read the "procedural -2", as well, but it didn't seem applicable here. This section seems to describe a "code freeze", which is not the case here.
The description of a "workflow -1" seems to align more with what it sounds like the intent of the -2s were. https://docs.openstack.org/project-team-guide/review-the-openstack- way .html#workflow-1
The description of a procedural -2 there fails to convey that they're used for a lot more in OpenStack besides just deferring changes until after a code freeze. They tend to get used for any sort of "not now" deferrals which the core reviewers want to remain "sticky" in the face of new patch uploads on the same change. For example, they're commonly applied to block approval of changes are associated with a spec which has been postponed to a subsequent development cycle.
Workflow -1 does certainly have some similar connotations, but is more ephemeral and also (primarily) used to simply indicate that a change is a work in progress and so the current patch in it is not yet ready to be reviewed. It gets cleared when a new patch is pushed for the change, since the most common case is that the author expects the next patch to be ready for review. Workflow -1 is also capable of being applied by the change author, whereas a Code-Review -2 can only be applied by a core reviewer on the project. -- Jeremy Stanley
Ok, thanks for the clarification. Is there some other documentation of voting guidelines/implications that describe this, or is this an unwritten convention?
On 2019-02-25 18:32:43 +0000 (+0000), Penney, Don wrote: [...]
Ok, thanks for the clarification. Is there some other documentation of voting guidelines/implications that describe this, or is this an unwritten convention?
I think it's more just that the authors of the OpenStack Project Teams Guide weren't especially verbose on that point, coupled with conventions continuing to grow over time while that document may have lagged behind them. I've just now proposed https://review.openstack.org/639191 to cover these additional details. -- Jeremy Stanley
On 2/25/19 8:11 AM, Curtis wrote:
On Mon, Feb 25, 2019 at 10:51 AM Penney, Don <Don.Penney@windriver.com <mailto:Don.Penney@windriver.com>> wrote:
> -----Original Message----- > From: Saul Wold [mailto:sgw@linux.intel.com <mailto:sgw@linux.intel.com>] > Sent: Thursday, February 21, 2019 6:19 PM > To: starlingx-discuss@lists.starlingx.io <mailto:starlingx-discuss@lists.starlingx.io> > Subject: Re: [Starlingx-discuss] Python Based VBox Installer > > > > On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote: > > On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote: > >> > >> > >> On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr > >> iver.com <http://iver.com>> wrote: > >>> Hi, > >>> > >>> I see Spec as a high level design for a code that going to be > >>> developed, and to make sure it aligns with how community is going > >>> to use it and to make everybody aware of what is going to do, so > >>> others can chime in and say things that can address multiple needs > >>> and influence its design. Let's call this apple. > >>> > >>> Now I see the case of a code that has been developed before even > >>> the community existed, and now been presented to the community to > >>> fill a gap and improve productivity, no time to change the design > >>> and would be up to community to accept or reject it as is. A case > >>> of donation really, I call this one Orange. > >>> > >>> For Orange I think Spec is not the right word, we need a > >>> wiki/readme to see what it does, and how to use it. It is too late > >>> to produce a spec to influence the design. > >>> > >> > >> OpenStack Operators have a tools landing repository [1] that > >> didn't/doesn't have the same level of requirements the rest of the > >> OpenStack code typically does, so organizations could open source > >> internal. potentially untested, scripts but not have to necessarily > >> adhere to all of the usual requirements. Over time the code in that > >> repository could be improved and moved out once it made sense. > >> > >> I think it's worthwhile to have useful internal code open sourced, > >> and in some cases make it a bit easier to do so, and if the code/tool > >> gets used then start improving it following general standards. This > >> would require a new repository. > >> > >> Just a thought. :) > >> > > > > I really like the idea of having a new repository as a landing zone > > where things can be stabilize over time. When I started reviewing this > > tool I noticed that my comments were more focused on design (features > > that we might not need, restructure of cli arguments and so on) and I > > understand that fixing this is outside of the scope of sharing an > > internal tool. > > > > So, should be go in the path of creating a new repository? or can we > > use an "experimental" folder within stx-tools? > > > > What do you think about this? > > > I think that this can land in the stx-tools directory along with the > other deployment scripts. As was pointed out in the meeting this > morning, this code has been in use within WindRiver for a while now and > they are making it available to the community. > > I think that the initial PR needed to have a better commit message > explaining this and a little more thought put into the request before it > got reviewed, such as removing the .pyc files, licensing, documentation, > the first two where show stopper for me, but easily fixed, documentation > could be added later. > > Sau! >
Things like the inadvertent inclusion of pyc files (which were already noted in multiple comments in the review) and missing license identifiers seem to be minor and easily correctable mistakes, and maybe not completely unexpected for a “new contributor”. As well, I had also noted in a review comment that this was a long-existing tool that was being published, referencing the email from Numan and asking for the commit message to be updated to explain this.
As well, note that this was an optional productivity aid. It does not impact the build, it does not impact any software. It is a tool to help people launch StarlingX in a VirtualBox environment, to aid them in installing and configuring the system. Nobody is required to use it.
With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html#...
Sounds like we need to come to a consensus as to when a -2 is appropriate. I personally don't think a -2 is appropriate for a first contribution, regardless of circumstances. Obviously we can't commit .pyc files and need licensing, but I definitely would prefer not to see -2s in this situation.
As I mentioned above, I was probably over zealous on marking it -2, consider it withdrawn.
I think this code is important and we need to get this back on track. This is a good "teachable moment" maybe for all sides? :)
Lesson learned! Sau!
Thanks, Curtis
Cheers, Don.
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io <mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com <http://serverascode.com>
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Review request for Python Bases VBox Installer has been restored. Kindly remove your -2 votes and add the comments that you would like to get fixed with -1. Some of the earlier comments have been already addressed. If there are new comments, we will address them accordingly. Thanks, Numan -----Original Message----- From: Saul Wold <sgw@linux.intel.com> Sent: February-25-19 2:51 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer On 2/25/19 8:11 AM, Curtis wrote:
On Mon, Feb 25, 2019 at 10:51 AM Penney, Don <Don.Penney@windriver.com <mailto:Don.Penney@windriver.com>> wrote:
> -----Original Message----- > From: Saul Wold [mailto:sgw@linux.intel.com <mailto:sgw@linux.intel.com>] > Sent: Thursday, February 21, 2019 6:19 PM > To: starlingx-discuss@lists.starlingx.io <mailto:starlingx-discuss@lists.starlingx.io> > Subject: Re: [Starlingx-discuss] Python Based VBox Installer > > > > On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote: > > On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote: > >> > >> > >> On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr > >> iver.com <http://iver.com>> wrote: > >>> Hi, > >>> > >>> I see Spec as a high level design for a code that going to be > >>> developed, and to make sure it aligns with how community is going > >>> to use it and to make everybody aware of what is going to do, so > >>> others can chime in and say things that can address multiple needs > >>> and influence its design. Let's call this apple. > >>> > >>> Now I see the case of a code that has been developed before even > >>> the community existed, and now been presented to the community to > >>> fill a gap and improve productivity, no time to change the design > >>> and would be up to community to accept or reject it as is. A case > >>> of donation really, I call this one Orange. > >>> > >>> For Orange I think Spec is not the right word, we need a > >>> wiki/readme to see what it does, and how to use it. It is too late > >>> to produce a spec to influence the design. > >>> > >> > >> OpenStack Operators have a tools landing repository [1] that > >> didn't/doesn't have the same level of requirements the rest of the > >> OpenStack code typically does, so organizations could open source > >> internal. potentially untested, scripts but not have to necessarily > >> adhere to all of the usual requirements. Over time the code in that > >> repository could be improved and moved out once it made sense. > >> > >> I think it's worthwhile to have useful internal code open sourced, > >> and in some cases make it a bit easier to do so, and if the code/tool > >> gets used then start improving it following general standards. This > >> would require a new repository. > >> > >> Just a thought. :) > >> > > > > I really like the idea of having a new repository as a landing zone > > where things can be stabilize over time. When I started reviewing this > > tool I noticed that my comments were more focused on design (features > > that we might not need, restructure of cli arguments and so on) and I > > understand that fixing this is outside of the scope of sharing an > > internal tool. > > > > So, should be go in the path of creating a new repository? or can we > > use an "experimental" folder within stx-tools? > > > > What do you think about this? > > > I think that this can land in the stx-tools directory along with the > other deployment scripts. As was pointed out in the meeting this > morning, this code has been in use within WindRiver for a while now and > they are making it available to the community. > > I think that the initial PR needed to have a better commit message > explaining this and a little more thought put into the request before it > got reviewed, such as removing the .pyc files, licensing, documentation, > the first two where show stopper for me, but easily fixed, documentation > could be added later. > > Sau! >
Things like the inadvertent inclusion of pyc files (which were already noted in multiple comments in the review) and missing license identifiers seem to be minor and easily correctable mistakes, and maybe not completely unexpected for a “new contributor”. As well, I had also noted in a review comment that this was a long-existing tool that was being published, referencing the email from Numan and asking for the commit message to be updated to explain this.
As well, note that this was an optional productivity aid. It does not impact the build, it does not impact any software. It is a tool to help people launch StarlingX in a VirtualBox environment, to aid them in installing and configuring the system. Nobody is required to use it.
With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here:
https://docs.openstack.org/project-team-guide/review-the-openstack-way .html#code-review-minus-2
Sounds like we need to come to a consensus as to when a -2 is appropriate. I personally don't think a -2 is appropriate for a first contribution, regardless of circumstances. Obviously we can't commit .pyc files and need licensing, but I definitely would prefer not to see -2s in this situation.
As I mentioned above, I was probably over zealous on marking it -2, consider it withdrawn.
I think this code is important and we need to get this back on track. This is a good "teachable moment" maybe for all sides? :)
Lesson learned! Sau!
Thanks, Curtis
Cheers, Don.
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io <mailto:Starlingx-discuss@lists.starlingx.io>
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com <http://serverascode.com>
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Wed, Feb 27, 2019 at 9:57 AM Waheed, Numan <Numan.Waheed@windriver.com> wrote:
Review request for Python Bases VBox Installer has been restored. Kindly remove your -2 votes and add the comments that you would like to get fixed with -1.
Some of the earlier comments have been already addressed. If there are new comments, we will address them accordingly.
Thanks! It'll be great to see this code get merged. :) Thanks, Curtis
Thanks,
Numan
-----Original Message----- From: Saul Wold <sgw@linux.intel.com> Sent: February-25-19 2:51 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
On Mon, Feb 25, 2019 at 10:51 AM Penney, Don <Don.Penney@windriver.com <mailto:Don.Penney@windriver.com>> wrote:
> -----Original Message----- > From: Saul Wold [mailto:sgw@linux.intel.com <mailto:sgw@linux.intel.com>] > Sent: Thursday, February 21, 2019 6:19 PM > To: starlingx-discuss@lists.starlingx.io <mailto:starlingx-discuss@lists.starlingx.io> > Subject: Re: [Starlingx-discuss] Python Based VBox Installer > > > > On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote: > > On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote: > >> > >> > >> On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr > >> iver.com <http://iver.com>> wrote: > >>> Hi, > >>> > >>> I see Spec as a high level design for a code that going to be > >>> developed, and to make sure it aligns with how community is going > >>> to use it and to make everybody aware of what is going to do, so > >>> others can chime in and say things that can address multiple needs > >>> and influence its design. Let's call this apple. > >>> > >>> Now I see the case of a code that has been developed before even > >>> the community existed, and now been presented to the community to > >>> fill a gap and improve productivity, no time to change the design > >>> and would be up to community to accept or reject it as is. A case > >>> of donation really, I call this one Orange. > >>> > >>> For Orange I think Spec is not the right word, we need a > >>> wiki/readme to see what it does, and how to use it. It is too late > >>> to produce a spec to influence the design. > >>> > >> > >> OpenStack Operators have a tools landing repository [1] that > >> didn't/doesn't have the same level of requirements the rest of
On 2/25/19 8:11 AM, Curtis wrote: the
> >> OpenStack code typically does, so organizations could open
source
> >> internal. potentially untested, scripts but not have to necessarily > >> adhere to all of the usual requirements. Over time the code in that > >> repository could be improved and moved out once it made sense. > >> > >> I think it's worthwhile to have useful internal code open
sourced,
> >> and in some cases make it a bit easier to do so, and if the code/tool > >> gets used then start improving it following general standards. This > >> would require a new repository. > >> > >> Just a thought. :) > >> > > > > I really like the idea of having a new repository as a landing
zone
> > where things can be stabilize over time. When I started reviewing this > > tool I noticed that my comments were more focused on design (features > > that we might not need, restructure of cli arguments and so on) and I > > understand that fixing this is outside of the scope of sharing
an
> > internal tool. > > > > So, should be go in the path of creating a new repository? or can we > > use an "experimental" folder within stx-tools? > > > > What do you think about this? > > > I think that this can land in the stx-tools directory along with
the
> other deployment scripts. As was pointed out in the meeting this > morning, this code has been in use within WindRiver for a while now and > they are making it available to the community. > > I think that the initial PR needed to have a better commit message > explaining this and a little more thought put into the request before it > got reviewed, such as removing the .pyc files, licensing, documentation, > the first two where show stopper for me, but easily fixed, documentation > could be added later. > > Sau! >
Things like the inadvertent inclusion of pyc files (which were already noted in multiple comments in the review) and missing license identifiers seem to be minor and easily correctable mistakes, and maybe not completely unexpected for a “new contributor”. As well, I had also noted in a review comment that this was a long-existing tool that was being published, referencing the email from Numan and asking for the commit message to be updated to explain this.
As well, note that this was an optional productivity aid. It does not impact the build, it does not impact any software. It is a tool to help people launch StarlingX in a VirtualBox environment, to aid them in installing and configuring the system. Nobody is required to use it.
With that said, the review had been given two -2 votes from cores. As I understand it, this is not a minor thing. From the openstack guidelines, a -2 “is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted.” Having two -2 votes on the update is very significant, thus the decision to abandon the review. The openstack guidelines describing -1 and -2 votes seems pretty clear here:
https://docs.openstack.org/project-team-guide/review-the-openstack-way .html#code-review-minus-2
Sounds like we need to come to a consensus as to when a -2 is appropriate. I personally don't think a -2 is appropriate for a first contribution, regardless of circumstances. Obviously we can't commit .pyc files and need licensing, but I definitely would prefer not to see -2s in this situation.
As I mentioned above, I was probably over zealous on marking it -2, consider it withdrawn.
I think this code is important and we need to get this back on track. This is a good "teachable moment" maybe for all sides? :)
Lesson learned!
Sau!
Thanks, Curtis
Cheers, Don.
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io <mailto:Starlingx-discuss@lists.starlingx.io>
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com <http://serverascode.com>
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com
participants (7)
-
Cordoba Malibran, Erich
-
Curtis
-
Eslimi, Dariush
-
Jeremy Stanley
-
Penney, Don
-
Saul Wold
-
Waheed, Numan