People want to drive "big" changes from the beginning but in reality it doesn't work that way in no FOSS project - one has to start with small things, not so small, slightly bigger, big, bigger, huge, etc. People that are dedicated go through the process and gain the ability to change so much for the reason that there is not that many other people working on the platform.
Is this perfect - NO, not at all. How can it change? There is only a single way I see - more people start contributing - but not contributing the next big thing - help us revive the platform. Things like:
- improve test suite - no big change can happen if the committer is not at least partly sure that nothing bad happens. That's a huge opportunity for people wanting to join as it doesn't require that much deep knowledge from the beginning. E.g. in SWT it was a test infrastructure work (~100 commits) just to modernize to the state where there is one test suite for all platforms with all the quirks in it to make it possible to run from maven build in a sane way. And tests can be run from the maven build run but still fail!!!
- bug triaging - Yes, having 1142(at the time of writing) open bugs for SWT/GTK only is not helping me see new problems. Verifying bugs, producing snippets that make it easier to reproduce, patches that fix it or simply closing the bug cause it has been fixed long ago. This is really valuable help as it is huge time drain. Reports that are vague or too big don't get that much attention as the current amount of people is already having problems driving the next release!!!
- cleanup the codebase - Making use of new features available for years, standardizing on given idioms, removing deprecated. All these boring things that make it easier to not be afraid of change, to jump into the project easily, to verify things easily, etc.
- improve the build system - Huge task and huge time drain for potential contributors. If the build takes so much longer than needed even without running the tests in it, how can someone easily verify a change. Yes, I mean building the whole platform and running all tests to verify that you're not breaking something few layers above you.
If/when we get the things above done - jumping into the problem space would be way easier and there would be enough people with experience in it already so we don't get to this state again.
With so many Eclipse users and people unhappy with the current state of affairs maybe it's time to try different approach. Is this the right one? No idea. Will it work? No idea either, but there is only one way to know it - let's try.
This is plea to the people that haven't been involved into Eclipse and wondered whether they can help improve - Yes, you can.
P.S. These are my own thoughts and doesn't represent a statement from any of the Eclipse groups I'm member of.
9 comments:
I absolutely agree. Cleanup work is essential to make it easier to move stuff in the future.
Also it is an easy way to get into the project, we (platform team) are very happy to merge a small cleanup patch.
In my opinion, a good way to lower the barriers to entry is to provide a valid setup script for the Oomph Installer [1]. I saw a demo of the tool at ECE 2013 and I can tell the tool works well.
I have one bug in mind that I would love to fix. With my limited knowledge of the JDT, I have materialized some plugins, and identified the code position where I should start (and try to change something). I am very confident that this is the correct position to start because I found a TODO describing what I want to change at the precise line.
My current blocker is that I have no idea how I should set up my workspace to start working on this. I must admit I never took the time to look at it… Maybe it is not as complicated at it seems to be, but I do not want to waste my free time on finding the git repo and setting up the workspace…
I imagine that with CBI and Gerrit code review, when it will be easy to get feedback the modification I could make.
See also Ed Merks blog post “Shoes for the Shoemaker” [2]
[1] https://wiki.eclipse.org/Eclipse_Oomph_Installer
[2] http://ed-merks.blogspot.fr/2014/02/shoes-for-shoemaker.html
Please someone from the platform team(s) review the Platform.setup that I spent more than a week authoring, and use that basis to prepare setups for smaller subsets of the overall platform project, e.g., the JDT project along with its test suites. After all, if the platform team really wants others to help do house-keeping tasks as introductory activities, it's best one isn't forced to spend a day (or a week) setting up an environment, hunting for repos, figuring out if they're Gerrit enabled, figuring out why there are errors in some of the bundles that just don't seem to want to go away, why Ant tasks are't built properly, and so on.
One counter point to keep in mind with respect to this overall them is to ask, why is so much cleanup activity needed? Likely that's because the established committers are spending time doing cool new things. Who can blame them? Of course everyone wants to do cool new things. So when we ask others to do house-keeping before getting around to doing cool new things, we have to expect that it's not a great selling point. If you compound that with the horribly menial task of figuring out how to set up the initial starting point, a functional IDE with the right tools and source, you might as well go buy a lottery ticket if you hope for a big win.
Ed, my experience (from the areas I'm involved into) is not that there is so much cleanup activity needed because existing committers do cool new stuff but because there are so few committers still active that all we manage to do is to barely keep the platform compiling and not crashing. Everything else is a dream for me.
I expect there are so few active committers because they're working on cool new things on other projects, e.g., Orion. JDT is focused on cool new Java 8 support. E4 gets more focus than years-old platform bugs. This is to be expected: cool new things are the lifeblood of a project and are what motivates developers to work hard every day. Housekeeping motivates very few people, but as you suggest, it's fundamentally important too. A tool to enable automated setup of the basis for getting start on such an activity, isn't a dream, it's a reality, but providing the setup description for doing so is yet more housekeeping, so finding someone with the time for it is challenging. If you want to motivate the housekeepers, do something to eliminate the menial job of enabling it...
Exactly, doing the yet more housecleaning to allow simple things like "run the tests" so one can verify his changes is where I struggle now. I agree with you that automated tool will help but getting test verification is more important in my eyes as otherwise committing smth is too risky, thus spending more time on such things myself.
I know it's not this OR that, we need this AND that in order to move to faster pace. And this will happen only if some more people jump in now to help make it AND.
It certainly makes very good sense to ensure that when changes are contributed, tests will uncover any problems caused by those contributions. That being said, as long as there are things of higher priority than enabling contributions one should expect the status quo to continue.
Note that much of the effort that Eike and I invest in Oomph was motivated by a need for housekeeping in our own projects: it's just too much work to set up new development environments that keep up with all the changes in dependencies. It was also motivated by the recognition that this is a universal problem so the effort would benefit the whole community. Note however that the effort I spent to configure a setup for the platform was purely motivated as a contribution to the platform intended to address exactly the problem you raise in your blog: it's just too hard to contribute. It's a bit ironic in light of this blog if that contribution, focused purely on housekeeping, does not have sufficient priority to act upon.
Do you think a problem of not enough people volunteering in "housekeeping", "infrastructure" work may be solved by paid staff, dedicated to such work?
I think this is an existence of paid staff behind IntelliJ platform that enables it improving things, which are still not good in Eclipse?
Can anyone estimate required efforts?
I don't think that hiring somebody and tasking him/her with "just do cleanup work" is sustainable approach. This is not the kind of work good engineer can do everyday for long periods without starting to cut on quality.
I really think that this would better happen as a community event where everybody does a small chunk.
Just what LibreOffice did.
Watch https://archive.fosdem.org/2013/schedule/event/challenges_libreoffice/ for context of what I mean.
Post a Comment