On 03.05.12 21:52, Rick Hillegas wrote:
Thanks for starting this conversation, Kristian. Here's my $0.02:
I see a number of issues here:
1) An impedance mismatch between the Derby and Maven concepts of release
artifacts.
2) The bewildering number of Derby release artifacts today.
3) A request for different Derby release artifacts.
4) A request for a source Maven artifact.
Just to be clear, I think we should try to drive our release process
toward producing fewer artifacts, not more.
Hi Rick,
That last statement is certainly valid, but I prefer that we produce the
artifacts our users need rather than focus too much on keeping the
number down to a minimum. If the resulting process is too hard on the
community, and more specifically the release manager, we have to
simplify it with better scripting/tooling to make it bearable.
Now, actually finding out which artifacts are needed isn't necessarily easy.
Let me explain why I brought up the topic of Maven artifacts:
There are a lot of Maven users out there, and the central Maven
repository contains a huge amount of software. Further, there are
several other systems/tools that can integrate with Maven, for instance
Apache Buildr, Apache Ivy, Groovy Grape, Grails, and Scala SBT.
By having good Maven artifacts for Derby, we make it easier for people
to use Derby. If it's too hard, and I don't think it takes much to reach
this state, people may very well simply switch to another database
system - for new projects with little current investment in Derby that's
a matter of changing a few dependency definitions.
Apache is all about open-source, communities and involvement.
In my opinion, not distributing a source bundle in Maven makes it harder
for Maven users to get involved. Not including line numbers in the class
files makes it harder for someone new to understand what's going on and
to debug the code ([1]). If their application fails because of Derby,
seeing the Derby source code on line X, where the NPE happened, may
convince them that this is indeed a Derby bug and not their own "silly
mistake". The result may be that we get a JIRA report and can fix a bug.
This isn't about what these users are able to do or not, it's about how
much effort it takes for them to get involved. Too much effort means no
involvement ([2]). Derby is only one project out of a large number of
open-source projects that are fighting for involvement from contributers.
I'm not saying we'll see a flurry of new contributions if we fix these
issues, but at least we remove some obstacles for those who have a
little bit of curiosity in them.
Based on your reply I think it would be best to discuss items (2) and
(3) first. Given that we are getting close to a new release, I'm
suggesting that we let this discussion live for a while and that we
don't change anything before 10.9 goes out.
Even if the above means postponing any actions on these topics, people
are very welcome to present their opinions on these topics.
Thanks,
--
Kristian, with his community hat on :)
[1] I know we have a source zip and debug bundles on the web site, and I
know people can access the Subversion repository if they want to. But
it's more tedious than clicking "Download Sources" in my IDE and
double-clicking on the class I'm interested in.
[2] I've seen this myself, where I have given up on reporting a
[potential] bug in a piece of software because I couldn't find the
information I needed, or because filling out the bug report would take
me hours...
< snip - lots of points for discussion >
