You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by Danny Bols <db...@osirion.be> on 2003/10/15 18:48:43 UTC
Lenya Stability
Hi all,
I have been following this community now for a few weeks and I get the
feeling we are dealing with a stability problem. Developping neat features
is one thing, but organizing things so those neat features are testable,
usable, documentable and saleable for/to other users and developpers is
another thing. We should ban out the scenario of downloading the latest CVS
version and not knowing which publication to use and not knowing which part
of the publication is currently working and which is not.
I would like to propose the following strategy:
1. One example/reference publication
There should only be one publication (I would suggest the default one) where
every single feature of Lenay is implemented and properly working on all
platforms (so what about this BXENG editor which doesn't work in IE?). The
more publications we have the more work we have to keep them all up and
running. Our valueable time should not be wasted maintaining those redundant
publications. Park all the publications for the time being, except for the
default one, and lets concentrate on only ONE and only ONE publication!
Why should we do this?
- So we don't get those repeating questions of new users how to get lenya up
and running but by making those new users part of this community by showing
them all those neat features.
- Stability: Tracking and solving of issues and bugs will be much faster. An
error in our example/reference publication means RED ALERT and reaction is
needed!
- Functionality: The example/reference publication should make clear which
functionality is available and which is not.
- Documenting: Documentation can be enhanced by referencing to a real
working example/reference example.
2. Commiting new enhancements
Developpers should agree on only committing their work under the condition
it's implemented in the ONE example/reference publication.
Why should they do that?
- Because other users/developpers are then able to test and to taste the new
stuff and to become enthusiastic about it.
- Because we make it possible to give the enhancement a critical review
which can result in ideas to make it even better.
- The example/reference publication is the first step to good documentation
(if we can't see the enhancement why should we document it).
3. Contract
We should concentrate on making the contract clear between Lenya and
publications. What should be the responsibility of lenya and what should be
the responsiblity of the publication?
4. Functionality
We should have a way to discuss the functionality issues reffering to our
example/reference publication. Let's move the current RFC's (Request For
Comments) to wiki so we give the community a way to discuss about it.
5. Stablity
Before introducing new possible riscs concentrate on making the current
version stable, so everyone is able to TEST, TEST and TEST. Lets begin by
making the core functions stable first. What are the core functions? Lets
make an inventory of the core first.
=//=//=//=
Diving into Lenya I can see a lot of very nice and complex features
(workflow, revisions, security, scheduling etc), which I would love to use
in one of my projects, but I also see that making the core functions of
Lenya work in a simple publication is very hard. IMHO a different management
of our valueable time would be one step into the right direction.
What do you think?
Danny Bols
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
Gump (Re: Lenya Stability)
Posted by Andreas Kuckartz <A....@ping.de>.
> > * integrate with gump
> What is gum?
Gump
http://jakarta.apache.org/gump/
Create gump.xml and integrate in Apache Jakarta Gump process
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19578
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
RE: Lenya Stability
Posted by Danny Bols <db...@osirion.be>.
From: Gregor J. Rothfuss
> Danny Bols said:
>
> > 1. One example/reference publication
>
> i am with michael that we need more than one publication.
>
> *hovewer*
>
> the oscom and unipublic publications need to go.
> oscom has too narrow a use case to be of general interest, and unipublic
> is superceded by unicms.
I don't know enough about the details of all the publications to give a
sinfull comment. I think we should start a discussion about which ones will
and which ones will not be part of the next release.
> > 3. Contract
> > We should concentrate on making the contract clear between Lenya and
> > publications. What should be the responsibility of lenya and what should
> > be
> > the responsiblity of the publication?
>
> +1
OK
> > 4. Functionality
> > We should have a way to discuss the functionality issues
> reffering to our
> > example/reference publication. Let's move the current RFC's
> (Request For
> > Comments) to wiki so we give the community a way to discuss about it.
>
> +1
OK
> > 5. Stablity
> > Before introducing new possible riscs concentrate on making the current
> > version stable, so everyone is able to TEST, TEST and TEST.
> Lets begin by
> > making the core functions stable first. What are the core
> functions? Lets
> > make an inventory of the core first.
>
> +1
OK
> we need to:
>
> * have more unit tests
BIG +1
> * run unit tests before every commit
BIG +1
> * integrate with gump
What is gum?
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
Re: Lenya Stability
Posted by "Gregor J. Rothfuss" <gr...@wyona.com>.
Danny Bols said:
> 1. One example/reference publication
i am with michael that we need more than one publication.
*hovewer*
the oscom and unipublic publications need to go.
oscom has too narrow a use case to be of general interest, and unipublic
is superceded by unicms.
> 3. Contract
> We should concentrate on making the contract clear between Lenya and
> publications. What should be the responsibility of lenya and what should
> be
> the responsiblity of the publication?
+1
> 4. Functionality
> We should have a way to discuss the functionality issues reffering to our
> example/reference publication. Let's move the current RFC's (Request For
> Comments) to wiki so we give the community a way to discuss about it.
+1
> 5. Stablity
> Before introducing new possible riscs concentrate on making the current
> version stable, so everyone is able to TEST, TEST and TEST. Lets begin by
> making the core functions stable first. What are the core functions? Lets
> make an inventory of the core first.
+1
we need to:
* have more unit tests
* run unit tests before every commit
* integrate with gump
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
RE: Lenya Stability
Posted by Danny Bols <db...@osirion.be>.
Michael Wechner
>
> Danny Bols wrote:
>
> >Hi all,
> >
> >I have been following this community now for a few weeks and I get the
> >feeling we are dealing with a stability problem. Developping
> neat features
> >is one thing, but organizing things so those neat features are testable,
> >usable, documentable and saleable for/to other users and developpers is
> >another thing. We should ban out the scenario of downloading the
> latest CVS
> >version and not knowing which publication to use and not knowing
> which part
> >of the publication is currently working and which is not.
> >
>
> agreed. That's why we need to consolidate on the 1.2 release with fully
> working publications (all links and functionality working)
OK...also see my comments below
> >I would like to propose the following strategy:
> >
> >1. One example/reference publication
> >There should only be one publication (I would suggest the
> default one) where
> >every single feature of Lenay is implemented and properly working on all
> >platforms (so what about this BXENG editor which doesn't work in
> IE?). The
> >more publications we have the more work we have to keep them all up and
> >running. Our valueable time should not be wasted maintaining
> those redundant
> >publications. Park all the publications for the time being,
> except for the
> >default one, and lets concentrate on only ONE and only ONE publication!
> >
>
> NO, but read on further below
I have a different point of view which needs an explanation, so see my
comments below
> >Why should we do this?
> >- So we don't get those repeating questions of new users how to
> get lenya up
> >and running but by making those new users part of this community
> by showing
> >them all those neat features.
> >
> agreed
OK...also see my comments below.
> >- Stability: Tracking and solving of issues and bugs will be
> much faster. An
> >error in our example/reference publication means RED ALERT and
> reaction is
> >needed!
> >
> this can be done for all the publications by implementing "web tests"
> and "junit tests"
I don't have expierence with testing tools....but from my point of view in
this phase of the development proces introducing testing tools and writing
test scripts etc is introducing extra riscs and complexity in the project.
IMHO this is not the right approach.
> >- Functionality: The example/reference publication should make
> clear which
> >functionality is available and which is not.
> >
> agreed
OK.
> >- Documenting: Documentation can be enhanced by referencing to a real
> >working example/reference example.
> >
> agreed
OK.
> ok, now I need to explain why I am so strongly against having only one
> sample publication.
>
> Diversity makes the core generic and keeps it generic. This is what
> differences Lenya from other
> CMF/Ss (maybe not all). I know it's more work in first place, but it's
> worthwhile and there are tools
> which can help such as for instance web tests, but they need to be used
> (no offense meant here)
I got your point here....but also see my comments below
> I might sound like your grandpa, but I already made the experience with
> only one publication and
> I don't want to live through it again, because it will kill it in the
> end and I guess that's not the goal.
Actually, I was afraid sounding like a grandpa :-)
> I very much agree with the problems your pointing out, but we have
> improved a lot very recently and
> I am very confident that we are able to consolidate finally.
>
> We need to focus on the long run and not on the short run.
I got your point....but also see my comment below.
> >2. Commiting new enhancements
> >Developpers should agree on only committing their work under the
> condition
> >it's implemented in the ONE example/reference publication.
> >
>
> If it's a core feature then it needs to run with all publications. But
> it would certainly make sense
> to introduce the pricinple of deprecation.
>
> If it's a feature of a specific publication, then all cloned
> publications need to work with it
See my comment below.
> >3. Contract
> >We should concentrate on making the contract clear between Lenya and
> >publications. What should be the responsibility of lenya and
> what should be
> >the responsiblity of the publication?
> >
> agreed. This is what I would regard as the "API" of the Lenya core
If this API apart from the JavaDocs is also telling us things like which
sitemaps are expected in a publication, how doctype is retrieved, which URI
space is preserverd etc.
> >Diving into Lenya I can see a lot of very nice and complex features
> >(workflow, revisions, security, scheduling etc), which I would
> love to use
> >in one of my projects, but I also see that making the core functions of
> >Lenya work in a simple publication is very hard. IMHO a
> different management
> >of our valueable time would be one step into the right direction.
> >
> >What do you think?
> >
>
> Your input is very much appreciated, so please don't just see my big NO,
> also see the many +1 and "agreed".
>
> I am not claiming that the existing sample publications are best of
> breed. They grew historically and they can certainly
> make way for better ones, but they need to be diverse. Diversity is key
> to survival (well, not only ;-)
>
> Thanks
>
> Michi
OK...you have been waiting long enough.....now it's time for my comment....
:-)
I'm glad with your reaction Michi ... it is a confirmation about the current
status and it made some things clear to me. I totally agee with you that
when releasing a new version of lenya we need more then 1 example
publication to show the strengths of the framework. If we should only
release one publication the world is going to get the idea that the
publication = (is equal to) lenya.....and we want the world to know that
Lenay is more then all the individual publications we show them. This leads
us to the discussion of how many and which publications are going to make
part of the next release of Lenya.
Ok.
But what I was trying to make clear is that we should optimize the (core)
development process. So my bottom line was about the introduction of a more
efficient development process in which we make better use of the resources
in our community. Let me give you an example: if I hear about a new lenya
component even with a nice technical document but without a real world
example the risk you loose me as a developper is great. But if you introduce
this component, even without documentation, in a real functioning
publication I am with you. It's a way of communicating. An example gives me
the high level scope of a solution without having to know all the tiny
technical details......if I am enthusiastic about a certain example I am
willing to dive deeper into the details.
Still I want to promote the idea of maintaining only 1 publication (I don't
care which one) during core development and when we reach a point of a new
stable core we can concentrate on making all the other publications work. So
my point is more is about HOW to get to a new release instead of WHAT should
be in a new release.
Thanks,
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org
Re: Lenya Stability
Posted by Michael Wechner <mi...@wyona.org>.
Danny Bols wrote:
>Hi all,
>
>I have been following this community now for a few weeks and I get the
>feeling we are dealing with a stability problem. Developping neat features
>is one thing, but organizing things so those neat features are testable,
>usable, documentable and saleable for/to other users and developpers is
>another thing. We should ban out the scenario of downloading the latest CVS
>version and not knowing which publication to use and not knowing which part
>of the publication is currently working and which is not.
>
agreed. That's why we need to consolidate on the 1.2 release with fully
working publications (all links and functionality working)
>
>I would like to propose the following strategy:
>
>1. One example/reference publication
>There should only be one publication (I would suggest the default one) where
>every single feature of Lenay is implemented and properly working on all
>platforms (so what about this BXENG editor which doesn't work in IE?). The
>more publications we have the more work we have to keep them all up and
>running. Our valueable time should not be wasted maintaining those redundant
>publications. Park all the publications for the time being, except for the
>default one, and lets concentrate on only ONE and only ONE publication!
>
NO, but read on further below
>Why should we do this?
>- So we don't get those repeating questions of new users how to get lenya up
>and running but by making those new users part of this community by showing
>them all those neat features.
>
agreed
>- Stability: Tracking and solving of issues and bugs will be much faster. An
>error in our example/reference publication means RED ALERT and reaction is
>needed!
>
this can be done for all the publications by implementing "web tests"
and "junit tests"
>- Functionality: The example/reference publication should make clear which
>functionality is available and which is not.
>
agreed
>- Documenting: Documentation can be enhanced by referencing to a real
>working example/reference example.
>
agreed
ok, now I need to explain why I am so strongly against having only one
sample publication.
Diversity makes the core generic and keeps it generic. This is what
differences Lenya from other
CMF/Ss (maybe not all). I know it's more work in first place, but it's
worthwhile and there are tools
which can help such as for instance web tests, but they need to be used
(no offense meant here)
I might sound like your grandpa, but I already made the experience with
only one publication and
I don't want to live through it again, because it will kill it in the
end and I guess that's not the goal.
I very much agree with the problems your pointing out, but we have
improved a lot very recently and
I am very confident that we are able to consolidate finally.
We need to focus on the long run and not on the short run.
>
>
>2. Commiting new enhancements
>Developpers should agree on only committing their work under the condition
>it's implemented in the ONE example/reference publication.
>
If it's a core feature then it needs to run with all publications. But
it would certainly make sense
to introduce the pricinple of deprecation.
If it's a feature of a specific publication, then all cloned
publications need to work with it
>Why should they do that?
>- Because other users/developpers are then able to test and to taste the new
>stuff and to become enthusiastic about it.
>- Because we make it possible to give the enhancement a critical review
>which can result in ideas to make it even better.
>- The example/reference publication is the first step to good documentation
>(if we can't see the enhancement why should we document it).
>
>
>3. Contract
>We should concentrate on making the contract clear between Lenya and
>publications. What should be the responsibility of lenya and what should be
>the responsiblity of the publication?
>
agreed. This is what I would regard as the "API" of the Lenya core
>
>
>4. Functionality
>We should have a way to discuss the functionality issues reffering to our
>example/reference publication. Let's move the current RFC's (Request For
>Comments) to wiki so we give the community a way to discuss about it.
>
+1 but on all sample publications ;-)
>
>
>5. Stablity
>Before introducing new possible riscs concentrate on making the current
>version stable, so everyone is able to TEST, TEST and TEST. Lets begin by
>making the core functions stable first. What are the core functions? Lets
>make an inventory of the core first.
>
+1 (please see my presentation I gave at the Cocoon GetTogether:
Consolidation, consolidation, consolidation, ...)
>
>=//=//=//=
>
>Diving into Lenya I can see a lot of very nice and complex features
>(workflow, revisions, security, scheduling etc), which I would love to use
>in one of my projects, but I also see that making the core functions of
>Lenya work in a simple publication is very hard. IMHO a different management
>of our valueable time would be one step into the right direction.
>
>What do you think?
>
Your input is very much appreciated, so please don't just see my big NO,
also see the many +1 and "agreed".
I am not claiming that the existing sample publications are best of
breed. They grew historically and they can certainly
make way for better ones, but they need to be diverse. Diversity is key
to survival (well, not only ;-)
Thanks
Michi
>
>Danny Bols
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: lenya-user-help@cocoon.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-user-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-user-help@cocoon.apache.org