revolution branch and lenya 1.5

[Jörn Nettingsmeier <po...@uni-duisburg.de>]

hi solprovider!

solprovider@apache.org wrote:
> On 8/9/06, Joern Nettingsmeier <po...@uni-due.de> wrote:
> 
> Joern,
> 
> I believe you will be very happy with Lenya 1.3.  1.3 removes Areas;
> it uses that portion of the URL for the module.  1.3 adds Revisions,
> which make publishing and rollback incredibly easy.  1.3's content
> structure is based on UNIDs (or UUIDs), and uses Structures to
> maintain hierarchies.  Today, you can see how content works with File
> and Link resources.  Editing XML resources will be added soon; the
> code is half written, but I was unable to work on it for the last two
> weeks.  I am uncertain there will be an upgrade path from 1.4 to 1.3;
> content should be easy, but Modules have very different internals.
> Hopefully we can merge 1.4's ability to have Module-specific Java
> class files if that feature proves useful.

it sure sounds interesting, and my remark about areas did in fact 
originate with you earlier comments on that topic.

but i have bet on 1.4 with my project, and there is no chance of me 
trying 1.3 unless the day gets significantly longer than 30 hours... 
i've worked hard at gaining a little insight into the workings of trunk, 
and i'm not in a position to write that off and learn something new atm, 
as much as i would like to play with your ideas.

i think the revolution branch is a good idea in itself to see new ideas 
come up, and i wish more people would review and collaborate on it, but 
at the same time the lenya community is very small and all eyeballs on 
the revolution branch are lost for the trunk.... hopefully the 1.3 
branch will be used enough that the good concepts in it will be fed back 
into the trunk.

1.3 is a symptom of sitting on code too long (both on your part for the 
perceived lack of interest of the lenya committers, and on the part of 
the committers for maybe having too ambitious or unclear goals).
it's good that the block is now overcome, and for that the 1.3 branch 
was certainly necessary.
one might also argue that trunk carries too much cruft, and that a 
clean-room rewrite (a "revolution") could do good. 2 months ago, i would 
have supported that view.
but lately the committers (notably andreas) have done an amazing 
clean-up job, which shows that the evolutionary approach seems to work 
very well.

personally (without having looked at 1.3 in depth) i hope that the two 
branches will be reconciled in the beginning of the 1.5 period, and that 
all developers will be working on the same trunk again. branching should 
happen frequently, but only on sub-systems if possible, to ease merging 
afterwards.

imho we can afford neither duplicate nor disregarded work in such a 
small community, so i do hope that the 1.5 cycle will start with a merge.


best,

jörn



-- 
"Open source takes the bullshit out of software."
	- Charles Ferguson on TechnologyReview.com

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: revolution branch and lenya 1.5

[so...@apache.org]

On 8/10/06, Jörn Nettingsmeier <po...@uni-duisburg.de> wrote:
> solprovider@apache.org wrote:
> > I believe you will be very happy with Lenya 1.3.  1.3 removes Areas;
> > it uses that portion of the URL for the module.  1.3 adds Revisions,
> > which make publishing and rollback incredibly easy.  1.3's content
> > structure is based on UNIDs (or UUIDs), and uses Structures to
> > maintain hierarchies.  Today, you can see how content works with File
> > and Link resources.  Editing XML resources will be added soon; the
> > code is half written, but I was unable to work on it for the last two
> > weeks.  I am uncertain there will be an upgrade path from 1.4 to 1.3;
> > content should be easy, but Modules have very different internals.
> > Hopefully we can merge 1.4's ability to have Module-specific Java
> > class files if that feature proves useful.
>
> it sure sounds interesting, and my remark about areas did in fact
> originate with you earlier comments on that topic.

We seem to share many concepts of how a CMS should work.

> but i have bet on 1.4 with my project, and there is no chance of me
> trying 1.3 unless the day gets significantly longer than 30 hours...
> i've worked hard at gaining a little insight into the workings of trunk,
> and i'm not in a position to write that off and learn something new atm,
> as much as i would like to play with your ideas.

1.3 is not ready for production use, and someone with a production
system should not switch to it (yet).  One difference is our ideas
about using unfinished code in production.  You have complained about
1.4 trunk changing and sometimes being broken.  I never take that
risk.  My customers are on 1.2 until 1.3 goes gold.

> i think the revolution branch is a good idea in itself to see new ideas
> come up, and i wish more people would review and collaborate on it, but
> at the same time the lenya community is very small and all eyeballs on
> the revolution branch are lost for the trunk.... hopefully the 1.3
> branch will be used enough that the good concepts in it will be fed back
> into the trunk.

I do not mind that 1.3 has remained my private sandbox.  Hopefully
that will change once the basic functionality is completed.

I am hoping 1.5 is based on 1.3, and adds JCR support, and maybe a
"backwards-compatible with 1.4" enhancement to the Module system.
Andreas' experience with adding JCR to 1.4 should allow JCR to be
easily added to 1.3.  1.3's Module system is based on replacing
fallback; 1.4's Module-specific Java classes may not be inherited
using that mechanism, but we should find some alternative.

> 1.3 is a symptom of sitting on code too long (both on your part for the
> perceived lack of interest of the lenya committers, and on the part of
> the committers for maybe having too ambitious or unclear goals).
> it's good that the block is now overcome, and for that the 1.3 branch
> was certainly necessary.

1.3 is a symptom of my late entry into developing the core of Lenya.
When I started with Lenya, I made many suggestions, but did not
realize the strength of the "Show me the code" attitude.   Then I
became a Committer, but 1.4's development was not compatible with my
suggestions (specifically adding JCR before redesigning the content
storage.)  I started 1.3 mostly to prove my suggestions were easy to
integrate and would produce an easier and more flexible platform.  It
is still early to know if I was correct, but it seems likely.

> one might also argue that trunk carries too much cruft, and that a
> clean-room rewrite (a "revolution") could do good. 2 months ago, i would
> have supported that view.

1.3 also contains much cruft; it is there for backwards-compatibility
with 1.2.  After 1.2 goes gold, it should be easy to remove the cruft,
losing backwards-compatibility once there is a good transition
version.  (The instructions could be "Migrate to 1.3.1 before
upgrading to 1.3.2+.")

> but lately the committers (notably andreas) have done an amazing
> clean-up job, which shows that the evolutionary approach seems to work
> very well.

I am happy 1.4 approaches completion.  We need releases to gain and
maintain interest in the project.

> personally (without having looked at 1.3 in depth) i hope that the two
> branches will be reconciled in the beginning of the 1.5 period, and that
> all developers will be working on the same trunk again. branching should
> happen frequently, but only on sub-systems if possible, to ease merging
> afterwards.
>
> imho we can afford neither duplicate nor disregarded work in such a
> small community, so i do hope that the 1.5 cycle will start with a merge.

Me too.

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org