Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2

["David M Williams" <david_williams@xxxxxxxxxx>]

No problem from me ("works with"
still seems the most accurate ... but, I don't really care -- too much
:). 

Thanks! 




From:      
 Aleksandar Kurtakov
<akurtako@xxxxxxxxxx>
To:      
 Tools PMC mailing list
<tools-pmc@xxxxxxxxxxx>, 
Date:      
 10/19/2015 09:17 AM
Subject:    
   Re: [tools-pmc]
[CQ 10263] vagrant Version: 1.7.2
Sent by:    
   tools-pmc-bounces@xxxxxxxxxxx

---

Anyone having problems giving PMC +1 in ipzilla? If
noone objects, I am going to do it tomorrow as I don't see any reason not
approving it.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
> From: "Doug Schaefer" <dschaefer@xxxxxxx>
> To: "Tools PMC mailing list" <tools-pmc@xxxxxxxxxxx>,
"mike milinkovich" <mike.milinkovich@xxxxxxxxxxx>
> Sent: Wednesday, 14 October, 2015 8:38:23 PM
> Subject: Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2
> 
> Funny how we still haven’t figured out this job after how many years.
I’ve
> been assuming and of the opinion that the PMC is a sanity gate to
prevent
> the EMO from wasting time on a request that the PMC didn’t see necessary
for
> the product. I’d prefer not to duplicate the great work that the
legal team
> is doing and I really don’t have the legal training to know what
these
> things all mean anyway.
> 
> What I do know is whether adding support for these tools to the Eclipse
IDE
> is important for our business that we should try to find the best
way to get
> these into the product from a legal/IP perspective.
> 
> Once there, we can be a sounding board if the legal team has questions,
but I
> think the project is actually the right people for that since they
have a
> good knowledge of the technology being analyzed. I’m lucky to have
used
> Vagrant and Docker and know what they are. But I don’t know what
things the
> PTP guys are working with, for example.
> 
> But I’m happy to be corrected.
> Doug
> 
> From: < tools-pmc-bounces@xxxxxxxxxxx > on behalf of David M
Williams <
> david_williams@xxxxxxxxxx >
> Reply-To: Tools PMC mailing list < tools-pmc@xxxxxxxxxxx >
> Date: Wednesday, October 14, 2015 at 1:18 PM
> To: " mike.milinkovich@xxxxxxxxxxx " < mike.milinkovich@xxxxxxxxxxx
>, Tools
> PMC mailing list < tools-pmc@xxxxxxxxxxx >
> Subject: Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2
> 
> 
> 
> 
> Thanks Mike. I'm not sure how you define "runtime" but I
see this request as
> analogous to "Docker Machine" which was submitted and approved
as "works
> with" dependency in CQ 10209 , and discussed and approved on
this list as a
> "works with" dependency.
> 
> Or, if you are suggesting that the Linux Tools project and IP staff
skip the
> Tools PMC and simply get EMO approval for "exempt pre-req",
I doubt if
> anyone on the Tools PMC would object. :) But I suspect what you mean
is what
> the guidelines state: if we (the PMC) think it is an "exempt
pre-req", then
> it must to the EMO for final approval (and that you would be inclined
to
> approve). [Thanks for making that clear.]
> 
> I suspect in this case, the "runtime" is the virtual machine
that vagrant
> needs (such as VirtualBox) and vagrant is (one) tool that can be used
to
> "manage" (loosely) that virtual machine. I see no need for
us to review
> VirtualBox (or other virtual machines) -- I'd assume those would all
be
> exempt pre-reqs, as much as the host OS is?
> 
> If you think any of what I've said is wrong, or have other advice
for us,
> that would be great.
> 
> Thanks,
> 
> P.S. An additional note for Roland, that I though of as I re-re-read
the
> guidelines: I had a hard time finding the license for vagrant. I saw
an MIT
> License file in their repository, but no where could I find a statement
that
> said "vagrant is licensed under the MIT License". Assuming
it really is, and
> I just didn't know where to look, that leads to the other condition
to keep
> in mind. When we approve "version 1.7.2 and higher" sort
of statements, that
> assumes the license stays the same. If they ever change the license,
in some
> future version, a new CQ should be open, and re-evaluated. This does
not
> happen often ... but, has a couple of times. That is probably pretty
> obvious, but I just like to be explicit. Especially that it is your
> responsibility as a committer -- there's nothing in place (that I
know of)
> that would detect a change in licensing of a "works with"
dependency. Thank
> you, again, for your patience with the process, and more so for the
cool
> tools you provide.
> 
> 
> 
> 
> From: Mike Milinkovich < mike.milinkovich@xxxxxxxxxxx >
> To: tools-pmc@xxxxxxxxxxx ,
> Date: 10/14/2015 12:06 PM
> Subject: Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2
> Sent by: tools-pmc-bounces@xxxxxxxxxxx
> 
> 
> 
> 
> All,
> 
> The determination of whether something is an exempt pre-req is within
the
> purview of the EMO. In the past the approach that we have consistently
taken
> with LinuxTools is that if a component is referencing a particular
runtime
> (e.g. Docker, LTTng, ...) then it can be reasonably described as an
exempt
> pre-req. The idea being that if someone wants to use Docker tools,
they
> probably have Docker installed.
> 
> At least that's how we've done it so far.
> 
> Hope that helps.
> 
> On 14/10/2015 11:33 AM, David M Williams wrote:
> Thanks for the additional detail, from all.
> 
> I can give my +1 to this, under the following conditions:
> 
> Primarily, after re-reading
> https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
> this seems more like a "works with" dependency, than an
exempt pre-req. I do
> not think pervasive enough to qualify as an exempt pre-req.
> 
> The third party package must not be installed automatically by a touch
point.
> That seems too heavy handed, and depending on many other packaging
details,
> users may end up installing the bundles/features but not really want
to use
> it or be aware of extra things being installed. (There are other ways
to
> make it easy to install, such as from preferences, but even there,
the
> non-EPL license must be explicitly presented to the user, if you implement
> that "easy to install" preference). [Mylyn uses that model,
or used to, for
> some of its connectors, if you need an example to follow].
> 
> The functionality must be packaged as a feature, so easy for adopters
or
> packages or users to leave out of their particular distribution or
install,
> if desired.
> 
> I hope none of those are controversial, but just wanted to be explicit.
> 
> I has glad to read that it will work with Version 1.7.2 or higher,
since in
> the past, we've sometimes "forced" users to downgrade some
external package
> to use some part of Eclipse, which isn't nice.
> 
> Please comment, especially if anyone disagrees with the "works
with"
> designation, since that's what I am voting "for".
> 
> Thanks,
> 
> 
> 
> 
> 
> 
> 
> From: Roland Grunberg <rgrunber@xxxxxxxxxx>
> To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx> ,
> Date: 10/14/2015 10:44 AM
> Subject: Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2
> Sent by: tools-pmc-bounces@xxxxxxxxxxx
> 
> 
> 
> 
> > > Is the "version" (1.7.2) a hard constraint? Or
does that must mean 1.7.2
> > > or
> > > above?
> > 
> > I think that one can't file CQ using "any" as version
which would make
> > sense
> > in such cases where the tool is simply invoking another executable.
So we
> > can read that as 1.7.2 or above.
> 
> When the textbox requested a version it wasn't clear to me if I could
say
> 'any'
> so I went with 1.7.2 since that's what I've been using for testing,
although
> there are newer releases. It can be read as 1.7.2 or above, and if
there were
> enough demand to support earlier versions we could look into it.
> 
> 
> > 
> > > 
> > > Also, you say "when \'vagrant\' isn\'t present, it
> > > would be pretty useless." You mean one specific feature
of "Linux tools",
> > > right? Not the whole package?
> > 
> > Linux Tools consist of multiple tools that are integrating underlying
tools
> > so if vagrant is missing only the vagrant feature will be useless.
And it
> > would not be entirely useless as we may use p2 touchpoint
> > checkAndPromptNativePackage to make the plugin request installation
of
> > vagrant which would increase the chances to get the plugin working.
> 
> Yes, just the vagrant plugin functionality would be unusable. There
are
> currently just 2 plugins (org.eclipse.linuxtools.vagrant.core, and
> org.eclipse.linuxtools.vagrant.ui) which will be contributing to this
> functionality.
> 
> We could definitely use the native installation touchpoint contributed
not
> that long ago into equinox.p2 to call the system native installer
> (aptitude, yum/dnf, etc.) to attempt to install vagrant. This would
be nice
> to do in the future.
> 
> 
> > > 
> > > Also, are there any alternatives? Other OS software that
in theory
> > > someone
> > > might want to use instead? If so, I just wanted to be sure
there was at
> > > least
> > > some potential to be open or pluggable, even if in future.
> > 
> > There is no plan to be pluggable or extendable or smth like this.
The goal
> > is
> > to get the common case automated within the IDE.
> > It might make sense to come up with common containers/vms/etc.
basic
> > management modules and widgets which can be used by plugins like
docker,
> > vagrant, name_yours to make adding new one (when it appears and
this seems
> > to happen quite often nowadays). But this is work for the future
when the
> > most common user scenario is covered and there are resources
for such work.
> 
> In the future it would be great to pull out a common framework for
both
> containers, and vagrant since there are terms that map onto each other,
and
> since at least initially the UI for Vagrant tooling will be a subset
of the
> one
> used for Docker tooling.
> 
> 
> > > 
> > > I just spent 30 seconds looking, but this post caught my
eye:
> > > http://stackoverflow.com/questions/7280875/a-better-alternative-to-vagrant
> 
> I have heard of higher-level wrappers around Vagrant such as oh-my-vagrant
> ( https://github.com/purpleidea/oh-my-vagrant) and I have considered using
> such
> a tool but decided to go with just vagrant for now. In addition there
is Otto
> ( https://www.ottoproject.io/intro/vagrant-successor.html) although even the
> language seems to suggest Vagrant won't be going away.
> 
> 
> Cheers,
> --
> Roland Grunberg
> _______________________________________________
> tools-pmc mailing list
> tools-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/tools-pmc
> 
> 
> 
> 
> 
> _______________________________________________
> tools-pmc mailing list
> tools-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/tools-pmc
> 
> 
> --
> Mike Milinkovich
> mike.milinkovich@xxxxxxxxxxx
> +1.613.220.3223 (mobile)
> _______________________________________________
> tools-pmc mailing list
> tools-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/tools-pmc
> 
> 
> _______________________________________________
> tools-pmc mailing list
> tools-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc