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 > > > > > >
