Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

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.


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


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
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".


Roland Grunberg <rgrunber@xxxxxxxxxx>
Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
10/14/2015 10:44 AM
Re: [tools-pmc] [CQ 10263] vagrant Version: 1.7.2
Sent by:        

> > 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

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:
> >

I have heard of higher-level wrappers around Vagrant such as 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
( although even the
language seems to suggest Vagrant won't be going away.

Roland Grunberg
tools-pmc mailing list

To change your delivery options, retrieve your password, or unsubscribe from this list, visit

tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Mike Milinkovich

+1.613.220.3223 (mobile)
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top