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. "
(emphasis added)
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,
autotools,
or lttng.
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
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
|