commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Spackman" <>
Subject Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Date Tue, 11 Nov 2008 05:28:07 GMT
Hi Paul,

I agree that this is _not_ something where a technical solution is _needed_ 
to go forward, I'm simply trying to keep the options open so that Jelly does 
not disappear (IMHO marking a project as "Not Actively Maintained" is the 
beginning of the end).

IMHO keeping Jelly in Commons Proper is the best choice for Jelly, while the 
2nd choice is to keep it alive elsewhere as a federated Commons is a close 
second, the 3rd choice as a last resort is to create a fork.  And I also 
agree that you need to be able to see who you're supporting, hence the 
reason for a patch submission to JIRA yesterday (with a follow-up in 
response to your comments today).


----- Original Message ----- 
From: "Paul Libbrecht" <>
To: "Commons Developers List" <>
Sent: Monday, November 10, 2008 11:16 AM
Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons


Le 10-nov.-08 à 07:11, John Spackman a écrit :
> Yes, kind of - I've only recently come across Git and the concept of  DVCS 
> but it was my intention to look at using a DVCS for this.
> But DVCS "only" does source code - setting up a seperate branch only 
> works if the community at large see the new branch, whereas the  Commons 
> group are considering marking Jelly as "No Longer  Maintained" and moving 
> the repository out of the main branch.

Hey no!
It's lacking maintainer and we shall be more than happy to make you a
committer having been able to measure the quality of contributions!

The problem is not the technical approach of DVCS, the problem is only
endorsement: it seems rather normal that a person that hasn't been
seen is first a bit observed or?

Setting up a separate fork for a while to achieve this sounds an
avenue to me.
Suggesting patches on jira or any other method or paced-down
contribution should be supported.
I'm happy to receive your source tree from time to time, in full,
inspect it and commit it as is for example.

> From my point of view, I would only want to perform a public branch  with 
> the endorsment of the Commons team; IMHO it's important for new  and 
> existing users to see a future for the project, and for there to  be a 
> link from the official Commons website to the federated Jelly  site.  The 
> original downloads would remain for backward  compatability, but the 
> Commons site would clearly refer users onto  the new site for upgrades and 
> future development.

I don't see any reason why commons would say "things are happening
elsewhere" while it could happen here real soon now. The issue is
endorsement and not distribution.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message