[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