[Starlingx-discuss] Python Based VBox Installer

Saul Wold sgw at linux.intel.com
Mon Feb 25 19:51:29 UTC 2019



On 2/25/19 8:11 AM, Curtis wrote:
> On Mon, Feb 25, 2019 at 10:51 AM Penney, Don <Don.Penney at windriver.com 
> <mailto:Don.Penney at windriver.com>> wrote:
> 
> 
> 
>      > -----Original Message-----
>      > From: Saul Wold [mailto:sgw at linux.intel.com
>     <mailto:sgw at linux.intel.com>]
>      > Sent: Thursday, February 21, 2019 6:19 PM
>      > To: starlingx-discuss at lists.starlingx.io
>     <mailto:starlingx-discuss at 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 at 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 at lists.starlingx.io
>     <mailto:Starlingx-discuss at 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 at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 



More information about the Starlingx-discuss mailing list