incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: Throw away 3.0 Re: JSPWiki & Apache Incubation?
Date Thu, 12 Jan 2012 19:00:22 GMT
Does it make sense to call for an official Apache vote on how to proceed ?

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.santos@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 <frank@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<florian@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message