All: This is a good discussion. These three options seem sensible to me.
I'd favor option 1. I'm pretty much retired from coding; lots of life changes. I don't think we have a large enough core set of developers to keep moving the project forward, at least in a good enough state to be "Apache good." Also: I agree that 3.0 tried to change too many things. Andrew On Jan 12, 2012, at 5:59 PM, Juan Pablo Santos Rodríguez<juanpablo.san...@gmail.com> wrote: > On Thu, Jan 12, 2012 at 8:00 PM, Harry Metske <harry.met...@gmail.com>wrote: > >> Does it make sense to call for an official Apache vote on how to proceed ? >> > > oops, my fault, I was referring more to take a decission on what to do > rather than to make an official Apache vote, I should have been clearer.. > > btw, I would prefer going on option 2. > > > regards, > juan pablo > > >> >> And if I summarize all discussed options correctly we would roughly have 3 >> options : >> >> 1) quit Apache incubator and move over to something like GitHub >> 2) graduate with 2.8 and gradually improve >> 3) graduate with 3.0 (continue the current 4-year long journey) >> >> Right? >> >> regards, >> Harry >> >> >> 2012/1/10 Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com> >> >>> Hello Frank, >>> >>> I was just writting pretty much the same thing. It seems that we have two >>> possible paths towards graduation/development of JSPWiki itself: >>> >>> Option A - graduate 2.8 branch: >>> 1.- 2.8.5: release current 2.8 as 2.8.5, graduate with it >>> >>> 2.- 2.8.6: rename packages to org.apache.wiki + fix failing unit tests >>> >>> 3.- 2.8.7?: bug fixes >>> >>> 4.- 2.9: in parallel with former point; goals: >>> + improve project documentation >>> + refactor code in order to ease the initial jump-in, possibly splitting >>> the code into sub-modules, i.e.: jspwiki-plugins, jspwiki-providers, >>> jspwiki-filters, jspwiki-workflow, jspwiki-engine and so on. Most >> probably >>> means breaking current API, but we would gain simpler, specific APIs >>> (plugin-api, workflow-api, etc) I have some ideas here, but I think it's >>> better to discuss this when we reach here. >>> >>> 5.- 2.10/3.0: or the new things happen here - retrieve from community >> what >>> should we do next >>> + see how to plug stripes + priha JCR provider work from trunk, at least >>> as modules that could be plugged in. A lot of work has been made in these >>> areas in current trunk and I think it's a pity just throwing out them. >>> Also, both frameworks were chosen because they were meant to simplify the >>> API, and the pluggability of JSPWiki within other systems.. >>> + multiwiki support >>> + enhancements noted by Frank (usb installation, search enhancements) >>> + the idea is to select a few, develop them, release a new version, >>> select a few more, etc. >>> + again, we should discuss this when reaching here >>> >>> >>> pros: seems more community-like, faster graduation, small, incremental >>> steps >>> >>> cons: JSPWIKI-382 (remove posteditor.js as it's license is unclear). >>> Regarding this point, last week I managed to reach posteditor author, >>> Daniel Mota, to ask him if he could clarify the license. He didn't knew >>> about JSPWiki, and he was happy to know that his work was being used, so >> he >>> said that as soon as he comes back from his holidays he would explicitly >>> state the license (MIT-license) at the library page, so we could graduate >>> and use his library. By the way, one question to our mentors: do we have >> to >>> wait this explicit statement in order to graduate? >>> >>> >>> Option B - graduate from current trunk (3.0): >>> 1.- fix at least JSPWIKI-713 and JSPWIKI-714 (and probably others) in >> order >>> to release 3.0.0-alpha >>> >>> 2.- graduate from 3.0.0-alpha >>> >>> 3.- refactor + improve documentation (same as former point 4) + bug fixes >>> >>> 4.- release 3.0.0 >>> >>> pros: LOT of work made here >>> cons: slower pace in order to reach graduation and 3.0.0 final >>> >>> Seems that option A is more feasible and will have more community support >>> but, as always, other opinions? Am I missing something? Let's call for >> vote >>> in order to decide which path should we follow to reach graduation. >>> >>> >>> regards, >>> jp >>> >>> >>> On Tue, Jan 10, 2012 at 11:22 PM, Frank Fischer <fr...@jcpsim.org> >> wrote: >>> >>>> On 01/10/2012 08:49 PM, Jürgen Weber wrote: >>>> >>>>> On Wed, Jan 4, 2012 at 11:59 AM, Florian Holeczek<flor...@holeczek.de >>> >>>>> wrote: >>>>> >>>>> Our community likes the 2.8 series for its stability and simplicity. >>>>>> Therefore, maintaining the 2.8 branch at least for a longer while is >>>>>> something that really makes sense. >>>>>> >>>>> 2.8 is great. It's a reliable work-horse. I like the file based >> storage. >>>>> >>>>> Why not take the radical step, throw the 3.0 branch away, go on with >>>>> 2.8 and make it Apache-ready? I never understood, why a wiki, where >>>>> the wiki engine does the gui, would need a web framework. It should >>>>> suffice to refactor 2.8 to use a controller servlet. >>>>> >>>>> And reread Joel Spolsky: Things You Should Never Do >>>>> http://www.joelonsoftware.com/**articles/fog0000000069.html< >>> http://www.joelonsoftware.com/articles/fog0000000069.html> >>>>> >>>>> 8-) Juergen >>>>> >>>> >>>> Just my thoughts. 2.8 works great and waiting for 3.0 >>>> to work was very frustrating. Why not restart with 2.8 >>>> and let it involve to a better (3.0 like in the end?) system. >>>> >>>> What might be done (with not too much effort): >>>> >>>> - Provide a (better) interface for data storage >>>> + that allows for metadata (parent page ...) >>>> + that decouples the page name from the >>>> capabilities of the file system (special >>>> characters, upper/lower case, length) >>>> A file based data storage should be the default >>>> connection to that interface >>>> (simple, easy to debug, no external dependencies, >>>> the user has access to the data without problems). >>>> >>>> What needs to be considered is under which >>>> 'identifier' (file name) a page should be stored. >>>> The page name as it is used now can to trouble >>>> ('Main' and 'main' considered the same under >>>> Windows, ...). >>>> >>>> One solution would be a filtered, human >>>> readable page name as a (natural) identifier >>>> (just like the suboptimal one that is in use now - >>>> xwiki by the way is nor happy at all if there is a >>>> dot - '.' - in the page name). >>>> >>>> Just an idea: >>>> - a TimeUUID is used as (surrogate) identifier and its string >>>> representation as file name (disadvantage: the >>>> user has to search in the metadata for the page >>>> name to find the file) >>>> - the file itself is a serialised JSON that contains >>>> metadata and contents - like: >>>> { "name":"Main", "author":"me", "contents":"bla bla" ... } >>>> - there are many ways to represent history and >>>> attachments with this scenario - not easy to find >>>> 'the right one'. >>>> >>>> - Simplify things / remove unnecessary options >>>> + is there really a need for other character >>>> sets as Unicode? >>>> + . . . >>>> + . . . >>>> >>>> - Many developers have already (and seperately) >>>> addressed some common needs - but nothing >>>> has happend to 2.8 because all (including myself) >>>> did wait for 3.0 to come (whose development was >>>> too complex for me to follow): >>>> >>>> + Provide an option for simple installation >>>> (on an USB stick). >>>> >>>> + Include attachments in the search algorithm. >>>> >>>> + Archives - a way to transfer pages and >>>> attachments from one installation to another. >>>> >>>> + Search within attachments (TIKA) >>>> >>>> + . . . >>>> >>>> All should be doable in small steps. >>>> >>>> But i see two big problems: >>>> >>>> - The 2.8 API is somewhat chaotic >>>> (example: try to collect all source code >>>> fragments that deal with the search >>>> function). >>>> Some refactoring in small steps might be >>>> a (very) good idea but it would continuously >>>> break the many private addones that have >>>> been developed. >>>> >>>> - Who shall decide what shall be done? >>>> Janne like most of us does not seem to >>>> have that much spare time. >>>> >>>> A voting system? (an authorised developer >>>> presents a relevant compatibility breaking >>>> update and if after one week there are more >>>> or equal '+1' than '-1' he can do what he wants). >>>> >>>> Or GIT-like branching and the developers decide >>>> every few months what should be merged to >>>> the trunk? >>>> >>>> I have no idea >>>> (sorry for the long post) >>>> >>>> Frank Fischer >>>> >>> >>
