incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Jaquith." <andrew.r.jaqu...@gmail.com>
Subject Re: Throw away 3.0 Re: JSPWiki & Apache Incubation?
Date Sat, 14 Jan 2012 19:11:56 GMT
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.santos@gmail.com>
wrote:

> On Thu, Jan 12, 2012 at 8:00 PM, Harry Metske <harry.metske@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.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
View raw message