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

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

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