Re: [VOTE] Graduate JSPWiki from Incubator
+1. On 16 Apr 2012, at 01:46, Juan Pablo Santos RodrÃguez wrote: Hello all, The Apache JSPWiki project entered Incubator in October of 2007. Since then we have added two new committers from diverse organizations. The codebase of our product has been growing slowly but surely, and we think is mature enough to go through graduation; also, we have made two releases following the ASF policies and guidelines. Thanks to the mentorship we have received through this period, we have learnt to self-govern and grow our community using accepted Apache practices. Given these milestones, I feel that JSPWiki is ready to graduate from Incubator. The first step towards graduation is to vote as a community that JSPWiki is ready to graduate. If the vote is successful, we will draft a board resolution proposal and call it to vote on the general Incubator list. The complete graduation process is described [1]. Please cast your votes: [ ] +1 Graduate JSPWiki from Incubator [ ] +0 Indifferent to graduation status of JSPWiki [ ] +1 Reject graduation of JSPWiki from Incubator This vote will remain open for at least 72 hours from now. [1] http://incubator.apache.org/guides/graduation.html Thanks, juan pablo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ready to Graduate?
JSPWiki has lost a massive amount of steam in the last year or so due to committers lives interfering with contributions. No known cure exists for life, unfortunately. Simply put, I don't think anyone has the capacity right now to do the graduation. I do not know whether the situation will change. We have discussed this among ourselves, but have no real conclusions. Code-wise the only real showstopper is actually making a release. There's still some trickle of contributions coming in, but they're mostly only for the non-Apache releases we did a long time ago. Advice useful. /Janne On Oct 18, 2010, at 22:12 , Noel J. Bergman wrote: Please evaluate the status of your project with respect to graduation. Why, for example, are Thrift and JSPWiki not yet ready to fly? What about Ace? Others? --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Yes. If knowing about the policy means wading through all the old board resolutions (like with the @author -policy, which is not mentioned anywhere on the web site - who knows how many other such policies we have that a podling does not know of?), it creates a very frustrating situation - not to mention a very inconsistent situation where copying another podling or an existing Apache TLP results in the wrong way. Could we make following best practices what ever we decide those are a graduation requirement instead of a release requirement? So releases which don't clearly violate some ASF policy are voted out quickly and its the poddling graduation that is delayed until they've done a release we're all happy with. +1. /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [appeal] Help JSPWiki Graduate!
On Aug 10, 2009, at 06:49 , David Crossley wrote: Gee, i hope that more people will assist with this offer to review your project status. That was supposed to be your week to have some special attention. It's holiday season - I myself haven't had anything but cellphone access to the intahweb until this weekend ;-) Yes, we're keeping our task list in JIRA instead of the web page, simply because it's a lot easier, and encourages participation more than a static HTML file somewhere. I know. However, that page is what the incubation docs ask for. Remember that the Incubator PMC (all volunteers with no time) currently has 38 projects to oversee. We must have such information in a consistent place and format. True; I added a JIRA issue on it. But it does not have to be updated until right before graduation, yes? https://issues.apache.org/jira/browse/JSPWIKI-588 That is a high-level summary, whereas your Jira can provide detail for some tasks. A good idea would be to add the links. I suggest adding a link to it alongside all other proposals at http://wiki.apache.org/incubator/ Done. OK, good. And then a script copies it in the right place during release process, I take it? See general instructions in http://www.apache.org/dev/#web http://www.apache.org/dev/project-site.html No, the websites are managed in SVN. Your project's committer does ssh to the server and deliberately does an 'svn up' (of course after initial checkout) in /www/www.apache.org/dist/incubator/jspwiki/ Yes, that's what I meant - someone must have a release script which checks out the necessary bits from SVN, builds the release and deposits it in a right place. Anybody have a good example of such a script? I meant adding the KEYS file to that distribution area as explained by the various How to ASF mirror docs. Gotcha. /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [appeal] Help JSPWiki Graduate!
The podling Status page hasn't been updated in ages. http://incubator.apache.org/projects/jspwiki.html Personally i would at least add some News items in there. That would help to encourage more participants and helps the IPMC at graduation review time. There are some items that i expect are already done. Investigate some other projects status files. Yes, we're keeping our task list in JIRA instead of the web page, simply because it's a lot easier, and encourages participation more than a static HTML file somewhere. We should probably have a link to the relevant JIRA issues so that the info is in one place (as you well know, information kept in multiple locations is always out of date). We have multiple news channels out there (a blog, the wiki, an a twitter account). So perhaps we should just feed the Twitter news stream in a badge onto the page? Clutch shows that there is one new committer since entry. It should show two new committers; Harry Metske and Florian Holeczek. Don't know why that is. It gets that from the status News section. I tried to find your Incubator Proposal wiki page and compare with the current list of committers, but could not find it. The incubator proposal wiki page is at http://www.jspwiki.org/wiki/ApacheJSPWikiProposal and provide decent patches. Getting more committers should encourage others. True... I suggest practicing ahead of time, as it will be less frustrating when you go for the real release. Note down your steps. Look around other projects and TLPs - many have notes about their release process so that other devs can assist and can do it themselves next time. Releasing is a process we've done over many times :-). Most say that whoever is designated the Release Manager needs to be prepared to put in a large amount of time. Unfortunately, nobody over here has a large amount of time available :- (. JSPWiki is *fully* voluntary, which means that other priorities are more important often. This BTW explains our very long incubation time as well. License headers: I glanced at some files. Looks okay. If not already done, then i suggest running RAT or using other tools from the committers repository. https://issues.apache.org/jira/browse/JSPWIKI-545 I see that your LICENSE file includes references to the supporting products licenses. Personally i think that that is a reasonable solution to a hard maintenance problem. Others say that we are required to display actual text of all licenses there. Yes, we chose to put the actual licenses under doc/ with the LICENSE file being a reference to them. Otherwise it becomes a real PITA to maintain, esp. considering that we've been changing our support libraries quite a lot recently. Hmmm, i think that this file is intended for actual notices that are requested in the various supporting products licenses. Never really knew the purpose :-) One thing that you can get ready prior to release is the distribution area at w.a.o/dist/incubator/jspwiki/ Gotcha. Look around other TLPs. Many have HEADER.html etc. files. (Yes i know that not many other incubating projects do it.) For people who stumble directly to mirrors or worse, directly to w.a.o/dist/ space, rather than going via your project's download page, these notices encourage them to download from the mirrors instead, and provide instructions for download verification. For example see Forrest. We store those ancillary files in our SVN. OK, good. And then a script copies it in the right place during release process, I take it? I am not sure what the requirements are to notify that the release is by a project in incubation. There are some docs at incubator.apache.org site. See the mirror headers at w.a.o/dist/incubator/ top-level. There is some disclaimer text there that you might like to use too. Yes, it's something that we've been wondering... Our release scheme will look interesting with a version numbering such as JSPWiki-3.0.0- alpha-1-incubating. ;-) The KEYS file is something else that you can get ready ahead of release time. Even if it only contains the signature of the Release Manager. Better with more, of course. It should be up to date already. Anyway, i hope that helps a little to ease your next phase. Thanks; that should help! One interesting question is what we should do to jspwiki.org domain. I'm quite willing to give it to ASF, no worries, just to ease any potential trademark issues; but whether ASF wants it is another matter. /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [appeal] Help Us Graduate!
*grin* I completely missed this email the first time around. I think JSPWiki would certainly benefit from the attention - we're fairly close to having all the bits and pieces in place (minus a release or two). It's just that we're slightly unsure as to what to do... When I collected the list of Things To Do Before Graduation (https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310732fixfor=12313986 ), I think I found at least two, if not three, separate lists. Wouldn't mind if you guys took a peek at the different items on the JIRA milestone above and gave your comments. I (and most of the other devs, most of whom are Europeans) are on holiday right now, but we should be getting back to speed in a week or two. Personally, I would like to get most of the issues looked at in advance so that we wouldn't have to bump our heads against the oh, but your release is missing X, do it all again too many times. /Janne On 5 Aug 2009, at 06:16, David Crossley wrote: On Nov 21, 2008 William A. Rowe, Jr. wrote: I'd like to suggest a thread on general@ for each of those projects who believe they are close to graduation, but not sure what to do next. To kick off such a thread, email *me* with a summary (like you do for status reports) of where your project is now in terms of community, code, releases and functionality. Don't forget to tell everyone *what* the code does, the language it's coded in, etc :) Most importantly, point out what help *you* think it needs. (Once launch the discussion your fellow podling members can offer their perceptions and opinion about what's needed, so we'll get a balanced view.) Here are the rules to keep this fun... Reply to *me*, not the list, so I can put one podling up for help at a time. Keep this subject so I can keep them in their own folder. If I see something missing, I'll help with editing the appeal so that everyone has enough information to jump in if they want to help. This also lets you remain anonymous, if you prefer - just tell me upfront. Only one of these at a time, let's give each podling our undivided attention on gene...@. I'll post the first appeal just as soon as I get it. Exactly one week of general@ discussion to help solicit the advise, help needed, advise, and possibly attract some other helpers reading general@ to your podling-dev@ list. Then let another have their turn. After a week, I'll kick off the second podling based on whichever appeal is next in my email queue, then the third, etc etc. Betting we can discuss and help out four podlings before we take a break for the holidays, and pick back up in January. Anyone want to give this a try? I am very disappointed that no podlings took up your suggestion. I wonder if the various podling developers are attentive to this general@ list. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: PPMC Member list
I don't remember adding PPMC members to such a file in the podlings that I've been mentoring - my guess would be that we just stopped maintaining that file. Can anyone confirm? AFAICT we udpdate the poddling status page with the PPMC members. Should I file a JIRA issue to get it fixed from the website? BTW, how do new PPMC members get added to the project-private - mailing lists? That info is missing from the guide too. /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Starting a new incubation
Jaffre does not need skeletons/stubs. The endpoints are pojos, parameters and return values are java.io.Serializable objects. No registry is required. Jaffre Connectors listen well-defined ports that can easily be bound to a specific address. They are firewall friendly. An experienced programmer will be able to fly over, and understand the whole Jaffre code in less than an hour. Jaffre is intended to be easily customized. OK, I'm sold on this project by this speech alone. +1 ;-) /Janne, who really wishes he could get back the hours he spent configuring RMI over the years - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Champion needed for new workflow project proposal
I don't mind championing you but as mentioned by others, there will be several hurdles to overcome. To change the license, you will have to get an agreement from everybody who ever contributed a patch to the source you plan to incubate, even for a minor bug fix. I don't know how painful that would be in your case. IANAL, but why would you need a CLA for a minor bug fix or small patch? For copyright to form, the item needs to be long and complex enough to be recognized as original - a few lines don't a copyrighted work make. With JSPWiki, we took CLAs from major contributors (of which there were over 20, that was quite a job) when they were identifiable, and rewrote the sections which didn't have an identifiable author or for which CLA could not be obtained. /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: UIMA [WAS Re: Suspending Projects]
My pet hypothesis (or maybe I'm just looking for excuses) is this: UIMA is heavily used in academia. Now academics have no problems with open source, to the contrary. But they have an overwhelming need to publish and build up a reputation. So they like to publish their source code on their own web site, where it's clear it's their work, rather than contribute to some community effort. If you look around, you'll see all manner of university efforts around UIMA, but very little of that code finds its way back into the ASF repo. FWIW, I've noticed this with JSPWiki too - there are at least three (maybe four-five) separate forks of the JSPWiki codebase within the academia, with little contribution back to us. There are a few additional reasons for this: * The authors feel that their code is not mature enough for inclusion, and often they may be right - code is created to solve a specific problem and on a proof-of-concept level with little regard to e.g. maintainability. * Often, the forks are not maintained after the paper is completed and published. The authors move to different subjects, and have little interest to keep working on the codebase (which might be needed in case of invasive modifications) * It brings them no benefit to contribute back, since there is little attachment to the project itself. What's important is their modifications; the project itself is just necessary noise which allows them to tinker with their grand ideas. (Yeah, I worked for the uni for three years ;-) /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to start a new workflow project on ASF
* you'll need to relicense from LGPL to ASL 2.0, can you have a written agreement from all the copyright holders (probably all past committers)? At least for JSPWiki this was a fairly big job. You might want to look at http://www.jspwiki.org/wiki/ApacheRelicensing for the kind of tracking we did. In the end, we had to reimplement two software modules because we couldn't get Software Grants, or the module had so many authors we didn't know who really owned the copyright on it. So be prepared for that. It is a good idea to start simply by firing off an email to all the past committers to check if they are even reachable. If you can't reach most of them, you know you are in trouble :-). /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ** MISSING ** January Incubator Reports
Where are the reports for BlueSky, Cassandra, Imperius, JSPWiki, Stonehenge, Lucene.net, Sanselan, Tashi, Thrift, and VCL? This is unacceptable to have so many projects disregarding the need to report. JSPWiki has been added. Sorry guys, the report has been ready for a few days in the repo already, but there were some personal circumstances which made me forget to copy it to the wiki earlier today. /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Some advice needed on JSPWiki package names
Hi ho folks! We were preparing for a massive rename from our old jspwiki name space to the org.apache.jspwiki.* -package to prepare for our first Apache release when we hit a major snag. Turns out that Jasper JSP compiler has a bug in it, and it thinks all classes with their FQN starting with org.apache.jsp are it's own, instead of org.apache.jsp. (note the trailing period). We are tracking this issue at https://issues.apache.org/jira/browse/JSPWIKI-465 Now, Jasper has this fixed in the trunk, but since it's used rather widely in other servlet containers, it means that very few servlet containers will be able to run JSPWiki for quite a while. We've got some fairly hackish ways around this (which cause pain), so the question to Incubator folks is - can we use a different package name than org.apache.jspwiki for our project, or does it require a full rename of the project itself? For example, org.apache.x.jspwiki where x can range from being a literal x to something else? We'd hate to lose the JSPWiki brand (due to four missing characters in an another project!) because we've existed for over seven years and have an established name. In addition, figuring out a new name for a project is always a real pain... Any ideas/advice from more experienced people? Any other options than those listed at JSPWIKI-465? /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: On incubating releases
So the first thing that happens post graduation is that you piss off the entire community by breaking all backwords compatibility by changing all the package names? Ick. Not a good first experience once out of the incubator. We (JSPWiki) will do this by taking advantage of the package change and rewriting our API. Since everything will be broken anyway, the package change does not matter (or it does, but hopefully the benefits will outweigh the cries of murder from the plugin developers). We *are* releasing outside of Apache into our pre-incubation release channel (with big disclaimers about this not being an ASF release everywhere, even if our mailing lists do reside on apache.org, etc). However, we do use the ASF release process to vote, make sure the artifacts are fine, etc. This is a part of the training to be an ASF project. We will start releasing into the incubator (whatever the release channel is) once we change the packages to org.apache, and do the API rewriting work then in the org.apache namespace. It's tricky, and has been a lengthy process, because we had so much baggage from being an LGPL project. But it's working out okay. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Key signing practicalities Was: status of PGP support in Maven
So you assume that that www.apache.org can not be hacked? What if a signing key *IS* in KEYS but not signed by anyone (because the developer has never attended an Apache key signing event)? Which reminds me - if one does not attend an Apache key signing event (which tend to be in faraway countries, traveling to which usually means parting with lots of cash), how *does* one get the key signed? Is there a regional list somewhere? Any people near Helsinki, Finland who are willing to have a coffee and sign my key? ;-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Names for the Web2.0kit
Just in case nobody mentioned this to you yet: Olio is the Finnish word for object as in object relational database or object- oriented programming. You may or may not find this suitable. :-) Unfortunately, it also means that there are quite a few Finnish IT companies with the word olio in their name. Also, olio.fi is owned by a Finnish web design company (though they haven't put anything on it yet). Again, this may or may not be suitable. :-/ /Janne On 22 Sep 2008, at 19:44, Shanti Subramanyam - PAE wrote: Olio is short and easy. I don't like the hodgepdge defintion. But then the dictionary also says medley, potpourri etc. which have more positive connotations. So either Ketero or Olio is fine. Shanti On 09/20/08 09:52, Henning Schmiedehausen wrote: We seem to have some way to check these through nameprotect.com. Once we narrowed down to two or three candidates, we can check these there. Ketero sounds a lot like Kitaro. :-) Olio is nice (and short, which I like). Ciao Henning On Sat, 2008-09-20 at 02:44 -0700, Craig L Russell wrote: There's a software consulting company in Bangalore called Sonata Software. Too close for comfort. http://en.wikipedia.org/wiki/ Sonata_Software Looking on Google, Olio, Potpourri don't appear to have conflicts. Mix Match is a PC product for photoshopping picture frames. Not really a conflict to me. Shanti Software is a consulting services company. Too close for me. Ketero is ok. One of the top hits on Google is this email thread! But Katera Software is a similar-sounding name. Cetero is a medical research company. Not a conflict. My favorites, in order: Ketero Olio Potpourri MixMatch Craig On Sep 16, 2008, at 1:12 PM, Shanti Subramanyam - PAE wrote: Since I didn't see any response to the proposed names below, here are a couple more : potpourri sonata (4 movements: web/cache/objectstore/db ? ) Shanti Original Message Subject: Re: [DISCUSS] Web20Kit: A Web 2.0 technology evaluation kit Date: Thu, 04 Sep 2008 09:51:30 -0700 From: Shanti Subramanyam [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Here are some suggestions for alternate names : Olio Ratatouille MixMatch (3 above indicating we're trying to mix and match components) Ketero (Ethiopian I believe for 'appointment') or Catero Shanti Craig L Russell wrote: Hi Martin, On Aug 26, 2008, at 7:51 PM, Martin Cooper wrote: Yeah, an association with WebKit was my first assumption as well. Agreed. New name.initiate().run(). --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN move
So, to make this a little more clear, when Wicket performed a few non-ASF releases on their old project site was their old Subversion repository shutdown and the ASF Subversion repository exclusively used? Yes. We are volunteers. Having to maintain 2 repositories would have been prohibitive. We made it absolutely clear that if we were not able to create releases from our code base, and had to maintain 2 repositories, we would not have joined Apache. I can also say the same for JSPWiki. Having to maintain two code repositories, two issue trackers and a total of four mailing lists would be too much of a pain. Both to developers and users. I don't think JSPWiki would've attempted Apache Incubation if that were a requirement. Yes. When we imported our repository we included everything (full history) from our old SVN repository. Ditto. The Incubation work has been concentrating on relicensing the code under AL 2.0, and learning the Apache ways of working. We release updates to the old releases using our own distribution mechanism (for the general user, there is no trace of Apache anywhere, except the fact that the issue tracker is on ASFs site, and so is the mailing list). However, this gives us a great way to practice the Apache way of working with minimal disruption to development. Since JSPWiki code has been under various versions of GPL since 2001, this relicensing stuff has taken quite a while, including pieces of code which needed to be completely rewritten from scratch. If that work had to be done in two repositories at the same time, we might as well have forgotten about it. It was clear from the beginning that the transition of a large project into Apache would not be easy or fast, especially since all of the committers are working on a volunteer basis. I find the Incubator to be an excellent safe haven where this work can be done. Yes, but older versions are no longer maintained (we currently only support ASF releases, provided there are no security issues). This is also our plan; there is no desire to continue maintenance of the LGPL-version of the code, once the ASF transition and incubation is complete. /Janne, who is sorry he can't contribute much to this conversation - I'm on holiday behind a slow cell connection... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Podlings with existing releases and community
+1 I think this is good, as it codifies an existing practice. /Janne On 3 Jul 2008, at 20:42, Craig L Russell wrote: Hi, Many projects that come to Apache already have existing releases. Some are still beta but others have already shipped a few production versions. This raises the issue of how to build on their existing communities while they work on doing project management the Apache way, changing package names, voting on releases, updating licenses, and documenting provenance. Most of what I've seen about how to do this is in the mentor guide: IP Clearance: Initial Clean Up; and On Repackaging. The focus here is on cleaning up the code base. No mention of cutting non- Apache releases from the import part of the repository. I'd like to expand on this a bit. It's very difficult to manage two code bases in two different repositories during a several-month (best case) to years (worst case) incubation period. I'd like to propose explicitly allowing existing communities to continue to develop code in the import part of their repository while they are cleaning up their IP, updating licenses, and changing package names. We can document that existing projects with communities may need to have a few releases using the original package names during incubation. While transitioning to releases the Apache way, a podling can release code from the import part of their repository. These releases are not incubator releases and do not need to be approved by an Apache PMC. Does anyone see issues with this, before I propose a patch to the guides? Thanks, Craig Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Again: The Maven Repository
It sounds as if waiting at the last possible second to move from org.jsecurity.* to org.apache.jsecurity.* is the best option for us. That way we can move over to the Apache SVN as soon as possible, but impact the existing community only when absolutely necessary. This is what we decided with JSPWiki as well - since renaming the packages is going to cause massive breakage of all 3rd party apps anyway, we'll use it as an opportunity to refactor some of the APIs in order to avoid a double breakage in concurrent versions. In the mean time, we'll release using the old mechanism through jspwiki.org - we'll just use Apache processes and infra to train ourselves in the Apache way of working while we transition everything under the Apache license (which we BTW completed just this week - if you check out the trunk, there should be no more LGPL dependencies around ;-). /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
The package names have to change when a podling comes into the incubator (to the org.apache namespace). So, the blow has to happen anyway. I'm not suggesting we enforce this for existing podlings necessarily, but future ones should probably do it. Once the podling graduates, the plugins would need to change the package name they use because they are now based on an official ASF library. Is find/replace really that difficult? *Once* is doable. We can do a lot of refactoring of old code during that anyway, clean away unused APIs, etc. *Twice* (that is, once from com.ecyrd.jspwiki to org.apache.incubator.jspwiki; then from org.apache.incubator.jspwiki to org.apache.jspwiki) is not so nice. Besides, us doing search-replace on other people's code and then redistributing it is very probably not ok anyway. Our own code is trivial to modify; all the external code is not. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
As an end user, I would _hate_ to have to change all of my code to reference a totally new package structure after the podling graduates. That's a major pain... With JSPWiki we have plenty of plugins and other extensions donated by people over the years. Every binary break means that we obsolete most of this stuff (unless we can take the responsibility of recompiling everything). Every binary break means that we will have to answer questions from people running obsolete software because they can't afford the cost of the upgrade because they have money invested in the customizations. So it's not only the pain of upgrading the package definitions; changing packages issues a damaging blow to the ecosystem nurtured in the incubator. Sometimes the impact can be minimal; sometimes it could be rather bad. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SGAs and CCLAs?
Hi! During the relicensing efforts of JSPWiki, some people returned Software Grants, some ICLAs. ICLAs I can find at http:// people.apache.org/~jim/committers.html, but how do I check that ASF has received the SGAs? How about corporate CCLAs? /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. I would assume though that if there is enough interest among the community, the subject of supporting something like Git could be opened up with the Board, yes? /Janne, who does not really know how this bit of ASF works... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving a failed incubation project
very much agreed and I guess if one can show a migration path (as I have suggested) which doesn't break too much, then I think nobody should mind renaming the packages. But with the ASF member hat on I think the package org.apache.* is something which the ASF should protect, just as the logo and the brand name itself resp. add a policy to the incubation process which people have to agree to when entering the incubation phase. With respect to JSPWiki, we would have an interesting situation: Our last release, 2.6.0, which is LGPL, is in the com.ecyrd.jspwiki package, and we have dozens and dozens of modules which are depending on it. In fact, our structure is such that we encourage people do develop their own plugin modules rather than do anything else. There are plenty of these contributed at jspwiki.org, and probably a lot more plugins inside companies which are not available to us. With 2.8, we are just planning to take the 2.6, and make an Apachified version of it in the incubation process. No real functionality change, just minor upgrades and fixes, and get an Apache-licensed version out as quickly as possible. WIth 3.0, we are planning to revamp most of the APIs, and we've been flagging this as a break point. Now, if we, with 2.8, have to change to org.apache.*, we will obviously break compatibility with any of the existing plugins. Then again, with 3.0, we will break it again. This will cause some ruckus in our developer base, and we'd certainly like to keep the 2.8 as compatible to 3.0 as possible, that is, keep using the com.ecyrd.jspwiki package throughout the 2.8 phase and move to org.apache together with the API break in 3.0. Any advice or policies? /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache SW Grant in other languages?
You might find interpretations or explanations in other languages, but those would of course not be legally binding. Who would be willing to expose him- or herself to the legal liability resulting from a translation error? I suppose anybody whose English is not strong enough - after all, you need to understand what you are signing, and the chances of getting an erroneous interpretation are far less, if the document is translated by a professional translator, as opposed to yourself having learned English for three years at school a dozen years ago, and currently mostly use it to read comments at Youtube videos. Legal text is often difficult enough to understand in your native language, and often uses vocabulary which you would never normally encounter in your daily life - even if you used English a lot. Yes, software authors often have strong English skills, but going legal is another matter entirely. As you say, translation errors may cause legal liability. So, failing to understand the legal text, they would rather NOT sign the document, which in turn means no contribution. Having a native translation and the original legal text side by side would make it a lot more approachable by non-native English people. I know ASF *is* an US entity, but many contributor's aren't. Out of JSPWiki active contributors, only one lives in the US, and we have a lot of users from India and China. I would applaud ways to help these people to get more involved... I'll also contact legal-discuss on this. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache SW Grant in other languages?
Who would be willing to publish a translation claiming that it is authoritative, and thereby expose him- or herself to legal liability towards people that rely on this translation instead of the original? Ah, gotcha. Yup, you're right. Maybe one could collect some donations and then hire a lawyer to create a professional translation, either authoritative or with all the necessary disclaimers in place. That might be useful from ASF's point of view. There are precedents, e.g. with Creative Commons. And copyright legislation is relatively harmonized across countries anyway (thanks to the Berne convention, and the ceaseless lobbying of the copyright management associations). /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache SW Grant in other languages?
Hiya! One of my contributors is asking if either the CLA or the Software Grant are available in other languages than English (French, Dutch or German preferred). Couldn't find anything directly off the Apache website... Any knowledge? /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] PDFBox proposal
How? Just curious. We don't have built-in PDF generation from pages, which is one of the more requested features. Apparently many companies like the ability to create documentation on a wiki, and then dumping it to a PDF for shipping. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] PDFBox proposal
JSPWiki could certainly use it! +1 from me... /Janne On Nov 15, 2007, at 03:08 , Jukka Zitting wrote: Hi, Ben Litchfield, the author of the PDFBox library, has been working with us at the ApacheCon preparing a proposal to bring PDFBox into the Apache Incubator. See http://wiki.apache.org/incubator/PDFBoxProposal for the current draft of the proposal. Some of the details are yet to be worked out, but the general idea is there. All comments and questions are welcome! BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JSPWiki Incubation
Thank you for your vote of confidence. We shall endeavour to be worth your trust! :-) /Janne On 17 Sep 2007, at 23:53, Dave wrote: On 9/12/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Are we ready to incubate? Time to sum up the vote: Votes: +1 Matthieu Riou +1 Alexey Petrenko +1 Martijn Dashorst Binding votes: +1 Craig Russell +1 Noel Bergman +1 Henri Yandell +1 Nicolas Hedman +1 Ted Husted +1 Dave Johnson +1 Jukka Zitting +1 Bertrand Delacretaz +1 Henning Schmiedehausen And we have mentors: - Dave Johnson - Sam Ruby - Henning Schmiedehausen - Craig L Russell Congratulations JSPWiki project, you are accepted into the Apache Incubator. May you enjoy your time in incubation, but not so much that you lose your desire to graduate ;-) I will go ahead and submit the mailing list and subversion space requests to the Infrastructure JIRA. I'll take a look at the latest Incubator docs first and Roller's old request as an example before I do that. What else should we be doing now to get the new podling in place? - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
In my (totally non-lawyer) opinion, the cleanest way to change the JSPWiki code to the Apache License might be for the project to release an Apache License version of their code, before coming to the Incubator, using their existing release channels. This would mean that the existing community has agreed on this, with the release being a very public notice of the agreement. There's just one catch: if we do the license change first, and then Apache says nah, we're not interested, we have done all the work for nothing. Also, moving the development (and the mailing lists) to Apache Incubator would also be a very public notice of the agreement. We would, of course, make big noise about this on our web site as well. All of our current contributors are aware of this already and have agreed to the license change. The people who are no longer a part of the community would not notice it on the Apache website, nor on the JSPWiki web site - they are no longer using the software anyway. And, as I said, we have already tracked down everyone (save one, and I know his boss personally ;-) and received permission to do this. I don't know whether all of them need to sign a CLA though... We are tracking the progress here: http://www.jspwiki.org/wiki/ApacheRelicensing /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Well, let me put it this way: it would be kinda dumb to run our public wiki site on another wiki engine. ;-) Dumb? So we must already be dumb, then, to be running other things like JVMs that don't come from the ASF, rather than our own. Nonono, what I meant was that it would be odd to have www.jspwiki.org running on Confluence or Moin Moin - it would look like we are not eating our own dog food. It's not at all clear from that list that those are wikis and not just regular web sites. Does JSPWiki have an auto-export capability, like Confluence does, so that pages can be offloaded to static resources, instead of hitting the wiki all the time? All of the resources listed are wikis (except, obviously, the mailing list. Even the blog is a wiki, though it is not open to the general public to edit). There is an external tool which allows a full or subset of files to be turned into static HTML resources, if necessary, but we do not currently provide one ourselves. You'll need a dedicated team of people, not just one person, that is committed to doing this on an ongoing basis. Very true. Being a hobby project has allowed us to be somewhat lenient towards things like web site availability (though having said that, we have two maintainers in two timezones, and in general our downtimes happen only when we upgrade something). This is one of the questions highlighted in our proposal, and help from the ASF is needed towards resolving these - I can't tell you how to run your services :-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 6 Sep 2007, at 17:20, Gwyn Evans wrote: While agreeing that it's something that needs looking at closely, I'm not I'm not sure it's downbeat as I think you're suggesting. The 3rd-party licencing policy at http://www.apache.org/legal/3party.html redirects to the draft at http://people.apache.org/~rubys/3party.html, but that suggests that, especially for use in binary form, licences such as CDDL or CPL aren't necessarily incompatible... That is exactly where the category B is coming from. Do we need to wait until ASF gets the 3rd party license policy completed? Please note that it would be *impossible* for us to work without some of the category B libraries, such as the JUnit testing library. Also, things like JavaMail libraries are highly useful for our user experience (e.g. sending email in case the user forgets his password). If there is an Apache-compatible implementation available, then fine. There are some custom licenses out there where we would need help from ASF's lawyers to check whether the licenses are really ok. Having to reimplement e.g. a permissive HTML-parser or a caching library would be a real PITA. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Is there a roadmap for when JSPWiki will have all of the features and functionality of both Confluence and MoinMoin, including the Confluence macros we use, and the migration tools so that we can move all the existing data from these existing wikis to JSPWiki? Without that, I don't see us replacing our existing wikis with JSPWiki, and I'm absolutely not in favour of adding a third wiki flavour to our infrastructure. Is this the real reason JSPWiki wants to come to the ASF? To be the wiki that the ASF runs on? Well, frankly, I don't really care what other projects are running :-). It's up to each project to choose the kind of infrastructure they choose. And I certainly see the point of not complicating the infrastructure. But, over time, migration tools will certainly emerge. We have so far not really been working on such things, as it hasn't really been a priority. Whether then the decision is made by ASF to adopt JSPWiki as an official tool is pretty much out of my hands. I would certainly like to see it happen, and can offer help, but I'm not exactly holding my breath. It's certainly not a driving factor in this whole transition. The way I see it, it's a decision that ASF will do based on ASF's own needs :-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
I believe Janne has already looked into this and has a good list of all former contributors. Janne, can you comment on the difficulty of this challenge? Already ahead of you. We have all but one tracked down and all have already agreed. The question is whether they need to sign CLAs or whether it is just enough that they verbally in an email agree to the license change. I have discounted people who have just sent simple patches, since in my admittedly non-legal opinion, simple patches do not cross the boundary of an original work, and therefore cannot be claimed to be copyrighted. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
This is interesting. Have you seen, that we are currently voting on the Jackrabbit list to enter Sling into the incubator. You may find more information at [1]. Yes, actually I did. I think it is something we can consider later. JSPWiki needs to do quite a lot of things internally than just render content, so it is yet unclear how that could possibly be applied and whether it would fit our needs. I mean - at the moment we don't really need Sling for anything, because we already have everything in place, and we don't have any pressing needs to change it. But I'm certainly keeping my eyes open on that one. :-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
