I would never suggest that PMCs not get involved. In fact, quite
the opposite. The policy says "All "prerequisite" dependencies
fall into two cases: "exempt prerequisite" and "non-exempt
prerequisite". This determination is made by the EMO with
input from the relevant PMC
and project leadership. "
In retrospect, talking about the "EMO's purview" was a mistake on
my part. The important part in my message is the history about how
we've interpreted exempt pre-reqs for LinuxTools. Apparently
Docker was a bad example :) Better examples would be systemtap
On 14/10/2015 1:18 PM, David M Williams wrote:
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
discussed and approved
on this list as a
Or, if you are suggesting that
Tools project and IP staff skip the Tools PMC and simply get EMO
for "exempt pre-req", I doubt if anyone on the Tools PMC would
object. :) But I suspect what you mean is what the guidelines
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
[Thanks for making that clear.]
I suspect in this case, the
is the virtual machine that vagrant needs (such as VirtualBox)
is (one) tool that can be used to "manage" (loosely) that
machine. I see no need for us to review VirtualBox (or other
machines) -- I'd assume those would all be exempt pre-reqs, as
the host OS is?
If you think any of what I've
wrong, or have other advice for us, that would be great.
P.S. An additional note for
that I though of as I re-re-read the guidelines: I had a hard
the license for vagrant. I saw an MIT License file in their
but no where could I find a statement that said "vagrant is
under the MIT License". Assuming it really is, and I just didn't
where to look, that leads to the other condition to keep in
we approve "version 1.7.2 and higher" sort of statements, that
assumes the license stays the same. If they ever change the
some future version, a new CQ should be open, and re-evaluated.
not happen often ... but, has a couple of times. That is
obvious, but I just like to be explicit. Especially that it is
as a committer -- there's nothing in place (that I know of) that
detect a change in licensing of a "works with" dependency. Thank
you, again, for your patience with the process, and more so for
tools you provide.
10/14/2015 12:06 PM
[CQ 10263] vagrant Version: 1.7.2
The determination of whether something is an exempt pre-req is
purview of the EMO. In the past the approach that we have
taken with LinuxTools is that if a component is referencing a
runtime (e.g. Docker, LTTng, ...) then it can be reasonably
an exempt pre-req. The idea being that if someone wants to use
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,
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
The third party package must not be installed automatically by a
point. That seems too heavy handed, and depending on many other
details, users may end up installing the bundles/features but
want to use it or be aware of extra things being installed.
other ways to make it easy to install, such as from preferences,
there, the non-EPL license must be explicitly presented to the
you implement that "easy to install" preference). [Mylyn uses
that model, or used to, for some of its connectors, if you need
The functionality must be packaged as a feature, so easy for
packages or users to leave out of their particular distribution
I hope none of those are controversial, but just wanted to be
I has glad to read that it will work with Version 1.7.2 or
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
designation, since that's what I am voting "for".
PMC mailing list <tools-pmc@xxxxxxxxxxx>,
[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
would make sense
> in such cases where the tool is simply invoking another
> 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
so I went with 1.7.2 since that's what I've been using for
there are newer releases. It can be read as 1.7.2 or above,
and if there
enough demand to support earlier versions we could look into
> > Also, you say "when \'vagrant\' isn\'t present, it
> > would be pretty useless." You mean one specific
of "Linux tools",
> > right? Not the whole package?
> Linux Tools consist of multiple tools that are
> so if vagrant is missing only the vagrant feature will be
> would not be entirely useless as we may use p2 touchpoint
> checkAndPromptNativePackage to make the plugin request
> vagrant which would increase the chances to get the
Yes, just the vagrant plugin functionality would be unusable.
currently just 2 plugins (org.eclipse.linuxtools.vagrant.core,
org.eclipse.linuxtools.vagrant.ui) which will be contributing
We could definitely use the native installation touchpoint
that long ago into equinox.p2 to call the system native
(aptitude, yum/dnf, etc.) to attempt to install vagrant. This
to do in the future.
> > Also, are there any alternatives? Other OS software
that in theory
> > might want to use instead? If so, I just wanted to
be sure there
> > least
> > some potential to be open or pluggable, even if in
> There is no plan to be pluggable or extendable or smth
The goal is
> to get the common case automated within the IDE.
> It might make sense to come up with common
> 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
> to happen quite often nowadays). But this is work for the
> most common user scenario is covered and there are
resources for such
In the future it would be great to pull out a common framework
containers, and vagrant since there are terms that map onto
since at least initially the UI for Vagrant tooling will be a
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
and I have considered using such
a tool but decided to go with just vagrant for now. In
addition there is
although even the
language seems to suggest Vagrant won't be going away.
tools-pmc mailing list
To change your delivery options, retrieve your password, or
from this list, visit