/FederatedCommons
On 11/11/2008, John Spackman [EMAIL PROTECTED] wrote:
Hi Paul,
Great :)
I'm working on some addition patches for JELLY-184 and a few others; they
don't always make a lot of sense added to a single JIRA entry though, IE
patch for one bug affecting the patch script for another
Hi Henri,
Using Henri's analogies from his recent blog, I took Jelly home from the
Commons a couple of years ago and we're now ready to put it in the
window
and see if we're invited to play [...snip...]
As below - analogy was about other Apache projects but probably
applies here as you say.
and commits in order for you to
become a committer.
Henri, can you please agree that we try to make jelly enter a
maintained mode, within a month or so, before we show not actively
maintained on the web-page?
thanks in advance
paul
Le 11-nov.-08 à 06:28, John Spackman a écrit :
Hi Paul,
I agree
Hi Russel,
Of course graceful demise is entirely appropriate. The question I have
is whether putting effort into maintaining a demising system is worth it
compared to putting that effort into transferring to a different (more
appropriate, in my view) technology for dealing with the problem.
Hi Russel,
Forgive me for butting in on a conversation but . . .
Anytime :)
Isn't this whole Subversion centralism problem solved by using a DVCS
such as Bazaar, or Git -- and soon, I gather, Mercurial.
Yes, kind of - I've only recently come across Git and the concept of DVCS
but it was
Hi,
We're still actively using Jelly and while the usefulness of some of the
extension modules may be debatable (and definitely without wishing to enter
into a debate of whether it is appropriate to have executable data), as a
core tool Jelly has allowed us to rapidly produce pluggable
such repair?
I could then try to apply a patch you submit to jira.
I am not sure (and hope not) that the web-site can only be fixed by
the migration to maven2...
paul
Le 08-nov.-08 à 10:20, John Spackman a écrit :
We're still actively using Jelly and while the usefulness of some of the
extension
