Scala updates and a call for participation

Mikolaj Izdebski mizdebsk at redhat.com
Wed Oct 9 17:19:57 UTC 2013


Thank you for progress update Will.

On 10/09/2013 06:41 PM, Will Benton wrote:
> What I have is a build of Scala 2.10 (not ideal for Spark, but necessary for Java 7) that builds on f19 and rawhide locally and in Koji (see the git tag V2.10.2-1).  This build has a couple of limitations:
> 
>    1.  it doesn't build the scala-partest jar (due to a couple of missing dependencies),
>    2.  it doesn't run the test suite as part of the build (due to many more missing dependencies), although the spec patches the test suite to eliminate spurious failures when it is possible to run it as part of a build,
>    3.  it relies on bootstrap binaries in the first release (as per Fedora policy); it isn't clear to me whether or not it is currently possible to bootstrap Scala without Scala

I wouldn't worry too much about bootstrapping with prebuilt binaries.  I
assume that this will be only one-time thing.  (There are some Java
packages that do the bootstrapping with every upstream version bump...)

> 
> Here's how you can help:
> 
>    1.  The current Scala maintainers have been unresponsive for some time (see threads on fedora-devel).  If you're a provenpackager, you can commit the new package and get Scala available in Fedora again.

I think that it would be best to start "unresponsive maintainer"
procedure in this case (if you haven't already done that).  Pushing big
updates like this is not appropriate for provenpackagers.  I think that
most people in Java SIG wouldn't mind if I pushed it, but I would rather
clear thinks up with the official procedure first.

>    2.  If you're a Scala user, you can try the new package and let me know if it works for you.
>    3.  If you're experienced with Java packaging, you can package (or review) missing dependencies for the Scala test suite.

I can help with packaging dependencies and/or reviewing them as long as
they are using Maven.  I will be developing a new Maven packaging
workflow and I need some stuff to package.  I would rather help you than
package a bunch of artifacts which I would throw away.

(I would rather avoid becoming primary maintainer of new packages as I
already have a enough work with my ~250 packages.)

>    4.  If you're interested in getting involved with packaging other Scala ecosystem projects (like sbt and Akka), there will be a chance to do that as well.

After reading your blog post [1] about sbt in Fedora I thought about it
a bit, but I didn't have any closer look at this tool yet and I don't
know the details.

I am probably going to work on integrating Ivy with Fedora artifact
repository (XMvn et al.) in near future and from what I remember sbt is
using Ivy, so there could be some benefit for sbt too.  I have some
solutions in mind, but I want to be as transparent as possible and
discuss all the possibilities.

What I think would really help would be an estimation of the number of
packages that would use each new build system as the level of packaging
automation depends on that -- the more packages using some build system
the tighter it should be integrated with Fedora.  It probably doesn't
make much sense to spend time on integration and maintenance on a new
build system if it will be used to build only two or five packages.

>    5.  If you're interested in improving the quality of my Scala package and can provide actionable feedback, please do so.

To sum up: I am happy to help with packaging or reviews.  New build
systems would probably require some development besides packaging, so I
think that we first need to estimate the amount of work and have some
discussion/planning.



[1]
http://chapeau.freevariable.com/2013/08/making-fedora-a-better-place-for-scala.html

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk


More information about the bigdata mailing list