Resigning as maintainer of eclipse
Hi
As the subject says. Lately I have not had the motivation to deal with
eclipse and as a result it is currently bit-rotting in unstable.
Furthermore, my daily Debian work has more or less drifted away from
Java work.
The particular issue (#649912) supposedly have a partial patch[1],
though unfortunately eclipse FTBFS on amd64 for me because some files
have "moved" and I have no clue as to why. Due to the above, I realized
that perhaps it was time to move on and make room for some new blood.
There are some people listed as uploaders of eclipse; some of them may
still be around and willing to work on eclipse. That being said I
strongly suspect we need new people in addition to the current ones.
If you are interested in maintaining in eclipse be advised that:
* eclipse takes a lot of effort, commitment and time.
- I have heard plenty of people say they would like to help with
eclipse. Though few actually stay around for longer than a week.
- In my experience, your co-maintainers can/will be busy for extended
periods of time or simply need some "away time" from eclipse.
- Most likely you will need a break from eclipse every now and then
as well.
- Some times you have to deal with a major upstream release mostly
on your own.
* you want some package experience before accepting this package.
- it is not simple, kind nor forgiving.
- you can compenstate with stubbornness and patience in short term.
- But it will wear you down in long term.
* it is very unlikely packaging the eclipse plugins
- we got reasonably good tool support for those, not for eclipse.
* eclipse has its own build system and an implied self circular
build-dependency.
- Every major version eclipse needs to be bootstrapped by a
pre-compiled eclipse.
- upstream unaffected due to incremental development style
- manually bootstrapping is technically possible, but easily
becomes time consuming.
- It is "merely" a nuisance and in the past Fedora did it for us.
- Though it did not work with 3.7, as the bootstrapping did not use
our "common" links (instead it recorded the final target which is
distro specific).
* every major upstream versions have pre-compiled binaries or
sourceless code.
- This has improved a lot since I picked up the package in 2009.
- This is a great source of frustration for me when packaging
eclipse 3.6 and 3.7
* eclipse consists of a myriad of "smaller" upstreams
- LinuxTools handles the build tools we use and usually happy to
carry patches that are not accepted "further upstream".
- Not all upstreams agree to the Debian approach.
- Some bundles are the "official binaries from X".
- Some accept our patches as "fall-back" (e.g. "recompile binary
if it is not present").
* you cannot forward patches to eclipse from someone.
- Author of the patch must forward it (or appear on their BTS and
give his/her consent)
* you generally want to be envolved in LinuxTools's eclipse-build
project.
- Some architecture patches got axed in the 3.7 cycle because we were
not around to refresh them. Presumably the cause of #649912.
* the eclipse build system is a resource hog.
- Over 0.5 GB of B-D (beyond build-essential) and over 2.7 GB size
used at the end of the build.
- javadoc process known to eat over 1.7 GB RAM alone during build.
- With less than 2 GB of RAM your build time will easily exceed an
hour.
- (parts of the) build is parallel by default and I have no clue how
to disable that.
* the build system has been known to ignore errors and happily continue
- In the old days this could cause pre-compiled binaries to end up in
the final package, but I think we have solved all of those problems
by now.
- The error you see is often caused by something that happened
earlier.
- Unfortunately 2-3 screens worth of exceptions and stack-traces
are "normal" in our current builds. >.>
* following Ubuntu bugs can easily kill your motivation.
- The reporters tend to use the precompiled binaries from eclipse.org
and report crash logs.
- Follow-ups are usually "Just download it from eclipse.org and it
works".
* Eclipse "hard-codes" paths (and "versions") of Jars.
- Even minor version updates to (e.g.) sat4j will cause issues.
- Issues propagate to the user's ~/.eclipse and stays there.
* Eclipse depends on multiple or old versions of the same library.
- Defacto you will end up maintaining those.
- Migrating eclipse to the new version can be difficult depending on
the library and eclipse's assumptions about it.
* Eclipse has a very good control on Copyright and License.
- Almost everything is EPL (with some exceptions).
- They have rigid copyright requirements.
- d/copyright is currently auto-generated.
* Eclipse has a strict release cycle.
- Yearly major releases (I think it is in June or July)
- They can be very difficult.
- eclipse-build has been known to prepare earlier to weed out some
of the bugs.
- If time permits, you want to be around for that.
- 2 minor releases.
- Usually relatively simple to do.
* Eclipse know-how is scares in Debian.
- Only a handful of people has worked with eclipse in Debian for the
past 3 years.
- Even fewer with 6+ (active) months of experience.
However, there are oppertunities here:
* Parts of upstreams have started projects to improve Linux distro
integration.
- Unfortunately I have not been able to follow up on this, so
currently we get what Fedora is ordering.
- I can dig out (some of) the relevant bugs on request.
* There is plenty of oppertunities to go further upstream and
improve integration.
- Java and ant are what you need and what you will learn.
* You will most likely be working with people from Fedora/RedHat.
- LinuxTools is filled with those.
- Solutions to lots of problems can usually be found in the Fedora
spec file (or one of their patches).
- Just generalize it and get it into eclipse-build or further
upstream and profit. :)
* When you have maintained eclipse for a year or so:
- most other packages will be pale and trivial in comparison.
- some people will assume you know everything there is to know
about Java (Packaging). :)
- someone will tell you to join NM (or become a DM) if you aren't
already. XD
- Your milage may vary here, but generally your technical skills
will very likely be DM/DD material after a year with eclipse.
* I will be around to answer questions and guide you to the right
people (did I mention LinuxTools's eclipse-build?).
I did not do it myself, but it might be a good idea to coordinate with
team members/co-maintainers to align your expectations. It can be very
demotivational to be (or to feel that you are) the only one working on
the "coming major upstream release".
~Niels
Useful links:
http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build
http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build/Inner_Workings
The "Inner Workings" is a "fairly" new document that describes some of
the things we had to learn the "hard-way" in 2009. Sami Wagiaalla from
Fedora is to praise for starting this.
[1] http://people.debian.org/~nthykier/eclipse/
Both files, the tarball needs to replace the existing tarball in the
upstream part of the package.
Reply to: