Re: Clojure team or maintainence within pkg-java?
On 07/06/2011 05:56 AM, Wolodja Wentland wrote:
> I am currently working with Phil and Daigo on getting Clojure into a better
> shape on Debian and we primarily work on updating the clojure{,-contrib}
> packages and getting leiningen into Debian.
I've noticed Phil tweeting about Debian things and wondered what
was going on :) I really enjoyed his presentation on leiningen
at the Clojure Conj.
> We are unsure if it would make sense to create a new pkg-clojure team that
> would, as of now, consist of the three of us or if it is a better idea to
> maintain these packages within the Java team.
>
> The people working on Scala formed their own team, but as Phil and I are quite
> new to packaging we would "just" have a single DD in our team. What are your
> thoughts? Do you mind to see all "based-on-JVM" languages maintained by the
> Java team?
>
> Our general tendency seems to be that we favour the creation of a new team,
> but I would love to get some additional feedback.
My personal opinion is that it's too early to spin up a new
team and all the associated infrastructure. Let's work on
a design plan and implement the packaging first... It may
become clear after this that a new team is indeed justified --
esp. to handle bug triage.
While I'm quite impressed with leiningen and I'm certain that
it would very difficult to be a serious Clojure developer without
it, I feel we may need to rethink the approach for Debian.
Leiningen is very much like (and indeed dependent) upon maven
for resolving dependencies. This is an essential solution for
our friends stuck on platforms that do not have a native,
robust packaging system that handles interdependencies.
What would be ideal, I think, is to capture the metadata
in Clojure libraries and use it to metadata for Clojure Debian
packages... taking as much inspiration -- and code -- from
leiningen as possible. If we use leiningen directly we'll
probably have to disable live Internet downloading at build
time (as was done with maven) as this is against Debian policy.
Allow me to let you know about two related efforts:
1. Packaging Jigsaw for Debian.
This is part of our Google Summer of Code project
http://wiki.debian.org/SummerOfCode2011/Jigsaw
and involves adapting the (now JDK 8) modular JDK
to native Debian packaging. We have similar challenges:
we have a set of interdependent modules and metadata that
describes them.
2. Building Clojure experimental on Jigsaw
This is a personal interest of mine to build upon our Jigsaw
work... Most notably I hope to achieve:
- Better startup time for Clojure as we won't have to read
all of rt.jar (and friends)
- Better modularity of Clojure itself... This is actually fairly
advanced, but if we can refactor the clojure jars as well
that can fill the "modularity gap" between Jigsaw underneath
and the Clojure libraries (Leiningen) above.
- Exposing the new concurrency tools (Fork/Join) as
discussed by David Edgar Liebke in his Conj talk
"From Concurrency to Parallelism". So this might
require reviving the "par branch".
- Reviving the Tail Call Optimization patch to the JVM
and insuring the Clojure runtime exploits the
performance benefits of it.
Respectfully,
--Tom
Reply to: