Ed,
Comments below.
On 13/07/2013 11:03 AM, Ed Willink
wrote:
Hi Ed
Some interesting points, not all of which I recognize.
On 13/07/2013 07:39, Ed Merks wrote:
Ask
yourself, as a committer with a significant amount of
experience working on your own project (i.e., you know a lot
about how to work with Eclipse's infrastructure), if you wanted
to work on some other Eclipse project Foo to provide a patch for
a problem, how much work is it to do the following:
- Extract that project's source repos; Does Foo have many
repos? Goodness forbid does it use SVN? If it uses git, does
it also use gerrit so you can commit changes for review?
- Ensure that you have the appropriate VM; Does Foo need
Java 1.4, 1.5., 1.6 or 1.7 to be available? Do they have
project specific settings to help?
- Install the right tools in the IDE; Does Foo rely on build
and generator tools that you'll need to produce runnable
code? Does Foo rely on tools to work with its specialized
artifacts?
- Provision a target platform with the right things needed
by Foo just to compile and run the tests. Are those
dependencies documented? Are there 30 such dependencies?
Which p2 repos do those dependencies come from? Which
versions of the dependencies are needed by which branches of
Foo?
- Provision a workspace with the necessary projects; Are
there 300 hundred of them? Are they logically grouped into
working sets. Do you have you have to figure that out
yourself?
How many of these issues are well addressed by team project
sets? Just the last bullet I think. Also, consider this: how
many of you have tried one of those for project Foo, and ended
up with a sea of errors that can and will cost you hours to
address? This is one of the key barriers to entry, because
those hours spent on setup time will drive anyone but the most
resilient to despair and saps the very lifeblood from those we
wish to tap for involvement and contribution.
Eclipse has very good Java support, so the best source of the code
is the SDK. I see progressively more challenging use cases.
1) Quick Hack. I expect to be able to import an interesting plugin
as source and use an instrumented version of it in a nested
Eclipse. This usually works, but I have submitted a number of
Bugzillas where it doesn't. Shame on all projects that fail to
provide the sources or omit auto-generated sources for distributed
code.
Yes, though it's more valuable to provide a patch, which is best
done via the team support, so better to have the project extracted
from git and submit a patch for review to gerrit...
2) Simple fixes. I expect to be able to import an interesting
plugin from its CM in very much the same way. This was much easier
with CVS that allowed single plugin checkout. It is also more
reliable when projects tag their CM to identify the matching state
for the milestone build. This provides an ability to submit
patches, but may open up the horrors of magic tooling, in which
case a full development workspace is necessary...
Yes, that's often the case.
For the above use cases, I think it is largely a matter for
project testing to ensure that the builds work.
With gerrit submission and associate hudson triggers it's even
better because all the tests are executed...
3) Full development workspace. This has been undermined by GIT,
I'm not sure why you say that. I've grown to love git and am just
falling in love with gerrit!
which
does at least now support Team Project Sets, but the very long
checkout time and disposition details for complete repos when only
one plugin is required (e.g. the EMF Examples Library) makes it
very unattractive to develop/test/use.
Hmm. In general git's performance is so dramatically better than
CVS that I've not found this to be a problem...
The
lack of utility of the GIT Team Project Set has stopped me
complaining about the Team Project Set being removed from the PMI
again.
Here we need new shared discipline. With GIT, perhaps
- the Team Project Set should be available on the PMI, with drag
and drop from Browser to Package Explorer
Yes, or some improved version that considers more of the issues.
I.e., the external dependencies of these things...
-- it should disable auto-builds
-- it should clone the GIT repo
-- create Working Sets all named "Project ...."
Often projects themselves know better what working sets are
appropriate...
-- include "Project Archive ..." and or "Project Dead ..."working
sets that clearly identify all the garbage in the repo that should
be ignored
Better to specify what should be included...
-- (dead projects should have their builders and natures commented
out.)
- the ...releng plugin should provide one or more further Team
Project sets to install all required dependencies for tooling
etc,.
Buckminster is extremely helpful and perhaps under utilized for this
purpose...
-- the user may need some control over activation of these
This seems to benefit from a little bit of help from PSF tooling
- DND from browser
- build disabling
- delegation and configuration of releng PSFs after the main PSF
The rest is just naming and discipline and could at least work
today.
In the end, all the infrastructure that's needed exists, it's mostly
a matter of automated orchestration...
-----
I find that mostly the JVM is not a problem. Surely everyone uses
7 as their primary VM? It is just that we develop for lesser VMs
and it is the testing of the variants that can cause nightmares.
Indeed.
In particular if the workspace preference is not set for 1.5
compliance bad things happen, since we have no inter-project
setting inheritance.
Even if it's set to that, you can still end up calling methods from
1.6.
Why can't e.g. emf.common be designated the EMF 'settings' plugin
so that emf.ecore and all auto-generated plugins inherit their
non-overridden settings from emf.common rather than the exciting
surprises that come from the indeterminate workspace?
Yes, a common set of project-specific settings that can be shared
across dozens of plugins is another issue.
The overrides could be multiply inheritable so that the GMF
'settings' plugin could merge EMF andGEF settings. There may be
conflicts, but let's have the developer sort them out once rather
than each user.
Perhaps an extension to API tooling can validate that
- Import Plugin with Sources will inherit determinate settings
independent of the workspace
- Checkout Plugin from CM will inherit determinate settings
independent of the workspace
- multiply inherited settings are not conflicting
Yes, all these kinds of things are what's needed to lower the
barrier to entry.
Regards
Ed Willink
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
