Repling inline to both Paul and John: On Sun, Nov 9, 2008 at 2:26 PM, Paul Libbrecht <[EMAIL PROTECTED]> wrote: > > Le 09-nov.-08 à 05:35, John Spackman a écrit :
<snip> >> 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". If we're invited to play then great - >> any changes we make will be contributed back (and documentation will come >> with those changes) - but my "home life" is a small business that keeps me >> very busy and my focus here is on gradually contributing fixes/improvements >> and documentation rather than taking Jelly a great leap forward as an O/S >> product. As below - analogy was about other Apache projects but probably applies here as you say. Don't worry about great leap forwards btw - scratch your itch to reduce maintenance pain of your fork; that's all anyone does and it adds up to value. <snip> > We can make a vote on that... or we can simply try to make it cleaner and > start applying code patches. I don't think retirement was what Henri > suggested. Paul: Well... definitely a strong line towards retirement. :) Informing users that it's an inactive project. >> Please don't get me wrong - I am very grateful for your offer to apply >> patches etc sent via JIRA but I am cautious as I think of the potential >> extra work that would entail and how much simpler it would be if I could >> just issue an SVN commit. > > I fully understand but Apache foundations' practice has really always been > such. There are a few bits at play here. There's a cultural pressure in that we don't want to give committer rights to people until they show commitment as we're indicating to the rest of Apache's communities that this person has shown commitment somewhere. There's also a legal bit - need to get committers to sign CLAs as they're expected to do larger pieces of work. >> Returning again to Henri's blog, instead of Jelly being a first use case >> for retiring a commons project, how about it being a first use case for a >> "Federated Commons" subproject? Blog wise that was targetted more at the Commons like components inside other Apache projects, than moving an item out of Commons. >> I appreciate the point that making commits >> open to anybody has it's problems and is not something the team want to do >> right now, but given that the list is contemplating retiring Jelly this >> could be an ideal opportunity to experiment with something where the team >> has little to lose. >> The original SVN archive would remain intact at Apache, >> and I'd take a copy of it for my 1.x trunk so that I could create branches >> (possibly using Git); any projects already using Jelly 1.0 would be >> completely unaffected, but new users and users wishing to update would be >> referred to the new Federated Jelly website & repository. There's a separate concept called Apache Attic that this fits into. Basically Apache will retire something and if people want it to continue life there are various ways back, including the one above of a fork being created elsewhere and linked to from Apache as a known fork that people are recommended to go get involved in. Though the plan isn't to do it for Commons components per se - as usual Commons doesn't quite fit the model :) Reminds me that I need to send in the board resolution/proposal for that ... I've been in a maintenance process mood recently it seems :/ Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
