[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