[Starlingx-discuss] Python Based VBox Installer

Curtis serverascode at gmail.com
Wed Feb 27 15:24:02 UTC 2019


On Wed, Feb 27, 2019 at 9:57 AM Waheed, Numan <Numan.Waheed at 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 at linux.intel.com>
> Sent: February-25-19 2:51 PM
> To: starlingx-discuss at 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 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
> >
>
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
>


-- 
Blog: serverascode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190227/343245d4/attachment-0001.html>


More information about the Starlingx-discuss mailing list