You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/03/15 10:14:58 UTC
Supported and unsupported blocks
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> <snip/>
>
>> So far, I've moved all blocks from /trunk/src/blocks to
>> /blocks/[status]/[name]/trunk and updated the svn:external property on
>> /trunk/src/blocks to "re-import" them at their former place. This way
>> everything should work as it did before the change.
>
>
>
> Cool! As I promised before you get my hero plate and a beer at the next
> GT for daring to move out the blocks from trunk.
>
>> As Daniel and Antonio have already found out, at
>> http://wiki.apache.org/cocoon/BlockStatusPoll I set up a page that
>> should give us an overview on who is able to support which blocks.
>> This should help us to decide on the status we want to give every block.
>
>
> And extra points for putting about everything under blocks/unsupported
> in SVN. That should give us a well needed kick in the ass for actually
> deciding what Cocoon is.
let's look at the results:
I'd say the following blocks are "supported"
authentication-fw AG,CZ,
batik CZ, VG, SW
cron RP, CZ, VG, SW, LG
databases AG, DF, SW, LG
deli AG,
fop AG, CZ, VG, BRD, BD
forms RP, AG, DF,CZ, VG, SW, BRD, BD, LG
hsqldb RP, VG,
html UV, VG, SW, BD
lucene JQ, VG, SW
ojb AG, JQ, VG, BD
poi AG, BRD
paranoid RP, SW
portal CZ,
profiler CZ, VG, BRD
qdox AG,BD
session-fw AG,CZ
template DF, BRD, LG
xsp AG, VG, SW
These blocks have at least two committers that support them. I added "portal" as
I know that there are many users out there (regular bug fixes via bugzilla) and
Ralph hasn't added his name for some reason (although he works regualarly on
fixing bugs and applying patches.)
I also added Deli as Antonio and Marc are both working on it and I therefore
don't consider it as one-man-show.
- o -
The following blocks either have only one committer who supports them or they
aren't supported by an active committer at all.
apples BRD
asciiart
axis
bsf AG,
chaperon
eventcache GH
faces VG,
itext
javaflow
jfor BD
jms GH
jsp
linkrewriter VG,
mail VG,
midi
naming
petstore
proxy BD
python
querybean JQ,
repository
scratchpad
serializers
slide
slop BD
stx DF,
taglib VG,
tour BD
velocity
web3
webdav
xmldb VG,
Where shall we draw the line between "supported" and "unsupported"? Is it really
the "two committers rule" that I applied above?
Another thought: maybe we should add another "state" called "sample". "tour" and
"petstore" could be "sample" blocks, as well as a future block that contains
all samples.
Comments?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jeremy Quinn wrote:
>
> On 15 Mar 2005, at 09:14, Reinhard Poetz wrote:
>
>>
>> Where shall we draw the line between "supported" and "unsupported"?
>> Is it really the "two committers rule" that I applied above?
>
>
> Don't get me wrong, I am happy you are being pro-active about this.
>
> However, I see several items on the "unsupported" list which are IMHO
> important components of Cocoon, or are blocks that I use regularly in
> my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and
> others). In most cases, the fact that they do not currently have >2
> supporters does not effect their quality and usefulness.
It is not about quality and usefulness it is about the degree of
community support.You probably remember Stefano's various discussions
about open source dynamics. One of his main messages, as I understod it,
is that "it's all about coomunity". Software that attracts community
will sooner or later achieve high quality and usefulness and also adapt
to changes in use patterns and development in the world outside, while
software that don't attract community will not adapt to a changing world.
A common complaint about Cocoon is that it is "big, complicated, scary
beast"
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110327845301789&w=2 and
one of the reasons for that is the percieved lack of focus. For someone
who hasn´t followed dev-list closely it can be quite hard to evaluate
what Cocoon is and decide what parts that are safe bets to depend on.
Depending on a block that has support from some committers mean that you
have much larger chance to get answers if you ask something and it also
means that you have much larger chance to get your patches applied. In
short community support it is a very important factor when you evaluate
the techical risk in your project. IMO we should take responsibillity
and give users an realistic idea about the actual level of community
support.
Focus is about choosing and it might be painful, but giving the users
the impression that everything is equally important is really to
complicte life for them. And for us it mean unnecessry duplication of
effort and no coherence in the result. Chosing CForms as the forms
framework is an excelent illustration on what happens when one get from
one man show to community support.
> On reviewing this list again, I see several blocks that I have worked
> on that I probably should have put my name to,
You didin't.
> and I notice several blocks that I know people actively care about,
> that they have not put their name to.
>
> Maybe I misunderstand the purpose of having "supported" and
> "unsupported" blocks, but I would hate to useful work being sidelined
> by not attracting usage or new contributions.
That is of course a dissadvantage, but it should be compared to the
frustration and lack of trust it creates for users to depend on blocks
that are one man shows from people who not are around and support their
work anymore.
--- o0o ---
Taken togther IMO marking the block with >2 supporters as supported is a
good and honest start. For the rest of the blocks, if anybody care
enough it is just to motivate why the block should be marked as
supported and start a vote about it.
/Daniel
Re: Supported and unsupported blocks
Posted by David Crossley <cr...@apache.org>.
Mark Leicester wrote:
> Hi Jeremy (et al),
>
> Ahem... If someone is prepared to nominate me as a committer I'll
> gladly support the midi block. :)
Hah, you and others like you have been on my radar for a long time
to invite as committers. Later.
However, your comment reinforces one of my points. We are creating
a problem for community development and user perception, by making it
look like only committers provide support. It should be the whole
dev community.
--David
Re: Supported and unsupported blocks
Posted by Mark Leicester <ma...@efurbishment.com>.
Hi Jeremy (et al),
Ahem... If someone is prepared to nominate me as a committer I'll
gladly support the midi block. :)
I must admit I haven't had a lot of requests for MIDI block support
since I cobbled it together back in 2003, and neither have I extended
it in any of the ways that I thought I might. Nevertheless, I would
like to see it survive as an example of how much fun Cocoon can be.
Thanks guys, for encouraging enthusiasts like me to create Cocoon
blocks - of all sorts! Long may it continue.
BTW Jeremy, I always meant to thank you for this feedback. :)
> I just updated Cocoon, and took a wizz around the samples ....
> In the MIDI section, I clicked on "A Short MIDI File", and it played
in my browser =:-()
> I NEARLY DROPPED MY CHIPS !!!!!
> Well done!!!
(from http://www.mail-archive.com/dev@cocoon.apache.org/msg02395.html)
Take care everyone,
Mark
On 16 Mar 2005, at 23:19, David Crossley wrote:
> Jeremy Quinn wrote:
>>
>> Don't get me wrong, I am happy you are being pro-active about this.
>>
>> However, I see several items on the "unsupported" list which are IMHO
>> important components of Cocoon, or are blocks that I use regularly in
>> my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and
>> others). In most cases, the fact that they do not currently have >2
>> supporters does not effect their quality and usefulness.
>>
>> On reviewing this list again, I see several blocks that I have worked
>> on that I probably should have put my name to, and I notice several
>> blocks that I know people actively care about, that they have not put
>> their name to.
>>
>> Maybe I misunderstand the purpose of having "supported" and
>> "unsupported" blocks, but I would hate to useful work being sidelined
>> by not attracting usage or new contributions.
>
> Thanks for raising these issues. I wrote a similar mail but didn't
> yet send it ...
>
> I am concerned about the signals that this classification,
> and listing of committers, sends for community-building.
>
> Here are some random thoughts - sorry no time ...
>
> Some blocks have no committers listed, e.g. midi, asciiart
> However, they probably don't need much maintenance, so why would
> they be listed as unsupported, or worse, moved offsite because it
> appears that no-one cares.
>
> I am not putting my name against any blocks, but that doesn't mean
> that i won't help with them. Whenever i make some spare time
> to attend to Bugzilla, i will work on patches for any block.
>
> We try not to mention specific committers names. In fact, we voted
> a while ago to remove author tags from code (but not yet done).
> We really don't want to encourage the community to contact individuals.
>
> --David
>
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
David Crossley wrote:
> Reinhard Poetz wrote:
>
>>Whenever I work as trainer or consultant and Cocoon is the subject, people
>>always ask me the same questions about maturity and community of Cocoon and
>>its blocks. We should tell our users clearly what *we* consider as
>>"supported", "deprecated" and "committed" and then everybody can decide
>>himself what he does with this information.
>>
>>The wiki page is only an indicator which should help us to decide to get an
>>answer on the community aspect which is one part of the answer which state
>>a block has (the others are interface stability, implementation stability
>>and available automated tests).
>
>
> The things that disturb me are the name "supported" and the list of committers.
> Perhaps we should remove that Wiki page once the "job" is done.
no problem as it's only a snapshop of March 2005.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.03.2005 07:52, Bertrand Delacretaz wrote:
>> The things that disturb me are the name "supported" and the list of
>> committers.
>> Perhaps we should remove that Wiki page once the "job" is done...
>
> Agreed, associating people's names with blocks is useful at this
> decision stage but the page should vanish as soon as possible. Blocks
> are either supported *by the community* or not.
The page still exists ;-)
Joerg
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 17 mars 05, à 01:56, David Crossley a écrit :
> Reinhard Poetz wrote:
>> ...The wiki page is only an indicator which should help us to decide
>> to get an
>> answer on the community aspect which is one part of the answer which
>> state
>> a block has (the others are interface stability, implementation
>> stability
>> and available automated tests)....
>
> The things that disturb me are the name "supported" and the list of
> committers.
> Perhaps we should remove that Wiki page once the "job" is done...
Agreed, associating people's names with blocks is useful at this
decision stage but the page should vanish as soon as possible. Blocks
are either supported *by the community* or not.
-Bertrand
Re: Supported and unsupported blocks
Posted by David Crossley <cr...@apache.org>.
Reinhard Poetz wrote:
>
> Whenever I work as trainer or consultant and Cocoon is the subject, people
> always ask me the same questions about maturity and community of Cocoon and
> its blocks. We should tell our users clearly what *we* consider as
> "supported", "deprecated" and "committed" and then everybody can decide
> himself what he does with this information.
>
> The wiki page is only an indicator which should help us to decide to get an
> answer on the community aspect which is one part of the answer which state
> a block has (the others are interface stability, implementation stability
> and available automated tests).
The things that disturb me are the name "supported" and the list of committers.
Perhaps we should remove that Wiki page once the "job" is done.
> Additionally I like Bertrands idea of a more verbose description of a block
> status, that could be part of every block documentation (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111096531612907&w=2 for
> details).
Agreed.
--David
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
David Crossley wrote:
> Jeremy Quinn wrote:
>
>>Don't get me wrong, I am happy you are being pro-active about this.
>>
>>However, I see several items on the "unsupported" list which are IMHO
>>important components of Cocoon, or are blocks that I use regularly in
>>my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and
>>others). In most cases, the fact that they do not currently have >2
>>supporters does not effect their quality and usefulness.
>>
>>On reviewing this list again, I see several blocks that I have worked
>>on that I probably should have put my name to, and I notice several
>>blocks that I know people actively care about, that they have not put
>>their name to.
>>
>>Maybe I misunderstand the purpose of having "supported" and
>>"unsupported" blocks, but I would hate to useful work being sidelined
>>by not attracting usage or new contributions.
>
>
> Thanks for raising these issues. I wrote a similar mail but didn't
> yet send it ...
>
> I am concerned about the signals that this classification,
> and listing of committers, sends for community-building.
>
> Here are some random thoughts - sorry no time ...
>
> Some blocks have no committers listed, e.g. midi, asciiart
> However, they probably don't need much maintenance, so why would
> they be listed as unsupported, or worse, moved offsite because it
> appears that no-one cares.
>
> I am not putting my name against any blocks, but that doesn't mean
> that i won't help with them. Whenever i make some spare time
> to attend to Bugzilla, i will work on patches for any block.
>
> We try not to mention specific committers names. In fact, we voted
> a while ago to remove author tags from code (but not yet done).
> We really don't want to encourage the community to contact individuals.
Whenever I work as trainer or consultant and Cocoon is the subject, people
always ask me the same questions about maturity and community of Cocoon and its
blocks. We should tell our users clearly what *we* consider as "supported",
"deprecated" and "committed" and then everybody can decide himself what he does
with this information.
The wiki page is only an indicator which should help us to decide to get an
answer on the community aspect which is one part of the answer which state a
block has (the others are interface stability, implementation stability and
available automated tests).
Additionally I like Bertrands idea of a more verbose description of a block
status, that could be part of every block documentation (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111096531612907&w=2 for details).
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by David Crossley <cr...@apache.org>.
Jeremy Quinn wrote:
>
> Don't get me wrong, I am happy you are being pro-active about this.
>
> However, I see several items on the "unsupported" list which are IMHO
> important components of Cocoon, or are blocks that I use regularly in
> my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and
> others). In most cases, the fact that they do not currently have >2
> supporters does not effect their quality and usefulness.
>
> On reviewing this list again, I see several blocks that I have worked
> on that I probably should have put my name to, and I notice several
> blocks that I know people actively care about, that they have not put
> their name to.
>
> Maybe I misunderstand the purpose of having "supported" and
> "unsupported" blocks, but I would hate to useful work being sidelined
> by not attracting usage or new contributions.
Thanks for raising these issues. I wrote a similar mail but didn't
yet send it ...
I am concerned about the signals that this classification,
and listing of committers, sends for community-building.
Here are some random thoughts - sorry no time ...
Some blocks have no committers listed, e.g. midi, asciiart
However, they probably don't need much maintenance, so why would
they be listed as unsupported, or worse, moved offsite because it
appears that no-one cares.
I am not putting my name against any blocks, but that doesn't mean
that i won't help with them. Whenever i make some spare time
to attend to Bugzilla, i will work on patches for any block.
We try not to mention specific committers names. In fact, we voted
a while ago to remove author tags from code (but not yet done).
We really don't want to encourage the community to contact individuals.
--David
Re: Supported and unsupported blocks
Posted by Jeremy Quinn <je...@apache.org>.
On 15 Mar 2005, at 09:14, Reinhard Poetz wrote:
>
> Where shall we draw the line between "supported" and "unsupported"? Is
> it really the "two committers rule" that I applied above?
Don't get me wrong, I am happy you are being pro-active about this.
However, I see several items on the "unsupported" list which are IMHO
important components of Cocoon, or are blocks that I use regularly in
my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and
others). In most cases, the fact that they do not currently have >2
supporters does not effect their quality and usefulness.
On reviewing this list again, I see several blocks that I have worked
on that I probably should have put my name to, and I notice several
blocks that I know people actively care about, that they have not put
their name to.
Maybe I misunderstand the purpose of having "supported" and
"unsupported" blocks, but I would hate to useful work being sidelined
by not attracting usage or new contributions.
> Another thought: maybe we should add another "state" called "sample".
> "tour" and "petstore" could be "sample" blocks, as well as a future
> block that contains all samples.
It is possible that querybean is a candidate for the sample block. My
aim for it is that it will become a really simple way to plug searching
into any project. Something I raised before, was that I think we will
see more and more reusable "mini-apps" built with Cocoon and these may
require a new classification.
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mar, 15 de Marzo de 2005, 8:36, Ralph Goers dijo:
> Reinhard Poetz wrote:
>> These blocks have at least two committers that support them. I added
>> "portal" as I know that there are many users out there (regular bug
>> fixes via bugzilla) and Ralph hasn't added his name for some reason
>> (although he works regualarly on fixing bugs and applying patches.)
>>
> Sorry, I must have been asleep. Actually, I've been overloaded with
> stuff the past month or so. Where do I add my name to the portal block?
http://wiki.apache.org/cocoon/BlockStatusPoll
Best Regards,
Antonio
Re: Supported and unsupported blocks
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
>
>
> These blocks have at least two committers that support them. I added
> "portal" as I know that there are many users out there (regular bug
> fixes via bugzilla) and Ralph hasn't added his name for some reason
> (although he works regualarly on fixing bugs and applying patches.)
>
Sorry, I must have been asleep. Actually, I've been overloaded with
stuff the past month or so. Where do I add my name to the portal block?
Ralph
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 15 mars 05, à 18:39, Sylvain Wallez a écrit :
> ...But the word "unsupported" conveys IMO a negative meaning that may
> not be adequate....
How about "contributed" instead? It's much more positive: a
contribution is something that we appreciate, even though we might not
be able to fully support it ourselves.
We could then have:
-supported blocks: essential to many Cocoon applications, fully
supported and tested
-samples blocks: example blocks, mini-apps, fully supported and tested
-contributed blocks: not officially supported, might not even work as
distributed, one-man shows, experimental stuff, etc.
-Bertrand
Re: Supported and unsupported blocks
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
>
> Where shall we draw the line between "supported" and "unsupported"? Is
> it really the "two committers rule" that I applied above?
>
> Another thought: maybe we should add another "state" called "sample".
> "tour" and "petstore" could be "sample" blocks, as well as a future
> block that contains all samples.
Yes. And as stated by Jeremy, samples could also include "mini-apps".
But the word "unsupported" conveys IMO a negative meaning that may not
be adequate. Some blocks have no attached names but contain
straightforward code (or even no code at all like the STX block!). And
although their initial developers may have left, acquiring the knowledge
of how these blocks work may not be that complicated.
So what we should do is have a closer look at those blocks we may be
interested in, and indicate if we consider them to be end-of-life or
dead-end of if we believe they could attract interest and people again
if we promote them a bit.
For this purpose, I suggest to add name in parenthesis to blocks we
believe in even if we don't have an intimate knowledge of their code.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Supported and unsupported blocks
Posted by Torsten Curdt <tc...@apache.org>.
>>>The following blocks either have only one committer who supports them
>>>or they aren't supported by an active committer at all.
>>>
>>>javaflow
>>>
>>
>>It seems weird that noone has put their name by javaflow. Am I the only
>>one using it?
>
>
> :-D
>
> I hope Torsten Curdt and the "Australian connection" will support it. ;-)
Ups! I have missed this poll as well.
Sure there is some stuff I am going to
support :)
cheers
--
Torsten
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mar, 15 de Marzo de 2005, 9:50, Ralph Goers dijo:
> Reinhard Poetz wrote:
>
>>
>> The following blocks either have only one committer who supports them
>> or they aren't supported by an active committer at all.
>>
>> javaflow
>>
> It seems weird that noone has put their name by javaflow. Am I the only
> one using it?
:-D
I hope Torsten Curdt and the "Australian connection" will support it. ;-)
Best Regards,
Antonio Gallardo
Re: Supported and unsupported blocks
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
>
> The following blocks either have only one committer who supports them
> or they aren't supported by an active committer at all.
>
> javaflow
>
It seems weird that noone has put their name by javaflow. Am I the only
one using it?
Ralph
Re: Supported and unsupported blocks
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 16/mar/05, alle 14:21, Stefano Mazzocchi ha scritto:
> Daniel Fagerstrom wrote:
>
>> If I have to choose between an abandoned one man show with full junit
>> test support (whatever that means) and a block with an active
>> community but no tests there would need to be *very* strong other
>> advantages for the one man show, for me to even consider it.
>
> If there is general consensus than a test suite can be more useful
> than a few individuals actually working on the code, we have a
> problem.
This looks much like a false dichotomy. If we have code with no active
committers but a comprehensive test-suite, we have a problem but it's
easier for newcomers to change it without fear of breaking it. If we
have an active community but no tests, we have a problem but we can
hope that of alll those people, someone will step up to write the
tests. We should try to have both, not fight about which is better or
worse.
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/blojsom/blog/
Source.zone: http://sourcezone.info/
Wine & Food Blog: http://www.divinocibo.it/
Re: Supported and unsupported blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> If I have to choose between an abandoned one man
> show with full junit test support (whatever that means) and a block with
> an active community but no tests there would need to be *very* strong
> other advantages for the one man show, for me to even consider it.
If there is general consensus than a test suite can be more useful than
a few individuals actually working on the code, we have a problem.
--
Stefano.
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Torsten Curdt wrote:
>>It is useful for checking that we don't break anything
>>and also documents our learnings about what the code does. Starting to
>>write test code for allready existing code just because it "should be
>>tested" is more than "a lot of work" it is IMO pretty close to wasting
>>time.
>>
>>
>
>May I now say... "Don't agree at all" ;)
>
>It helps a lot(!) if you do refactoring.
>How do you know whether it's working like
>it was before? ...testing everything by hand?
>...well, now that's what I would call a waste
>of time ;)
>
>
If you reread the my message, you can see that we have about identical
opinions about both why and that testing is useful for refactoring. ;)
Also I believe that it is a very good idea to write new code in a test
driven manner.
The point I wanted to make is that I don't think it is a good use of our
effort to start adding tests to existing code *only* because we would
like to approach 100% test coverage. It will mean that you write tests
without have any spcific usecase for them. OTH when you refactor or do
new development you know what parts you are going to change or what you
want new functionality you want to achieve, this makes it much easier to
write high quality test cases as you actually have a use for them.
So I think it is much better use of ones limited time to refactor parts
that are hard to understand or have unclear communication patterns
between components, and add test cases as a part of the job, than just
add test cases in general.
/Daniel
Re: Supported and unsupported blocks
Posted by Torsten Curdt <tc...@apache.org>.
> It is useful for checking that we don't break anything
> and also documents our learnings about what the code does. Starting to
> write test code for allready existing code just because it "should be
> tested" is more than "a lot of work" it is IMO pretty close to wasting
> time.
May I now say... "Don't agree at all" ;)
It helps a lot(!) if you do refactoring.
How do you know whether it's working like
it was before? ...testing everything by hand?
...well, now that's what I would call a waste
of time ;)
cheers
--
Torsten
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Torsten Curdt wrote:
>>>>...Where shall we draw the line between "supported" and
>>>>"unsupported"? Is it really the "two committers rule" that I applied
>>>>above?...
>>>>
>>>>
>>>How about adding another condition: a block can only have "supported"
>>>status if we have automated tests for all its critical functions?
>>>
>>>
>>That's a very interesting point.
>>+1, even if I'm not the most productive test writer :-)
>>
>>
>>>This might make a big difference in the accountability of supported
>>>stuff in our releases.
>>>
>>>
>>Yep. But this also means the core is currently unsupported ;-P
>>
>>
>
>Hehe... Well, time to write some test then ;-P
>
>Actually I somehow like the idea of required tests!
>And it would also clearly draw the line. Much better
>than the two-committer rule.
>
>
Don't agree at all ;) If I have to choose between an abandoned one man
show with full junit test support (whatever that means) and a block with
an active community but no tests there would need to be *very* strong
other advantages for the one man show, for me to even consider it.
And take the >2 commiter rule as a starting point, if you want something
to become supported, give us good reasons a start a vote.
>...but a lot of work :-/
>
>
I agree that test driven programming is a an efficient and good way of
developing code, and I have made good use of it in e.g. the JXTG
refactoring. But as for everything else it is the quality of the tests
that counts. It is far to easy to write tons of testing code that
resembles the commenting style where you tell that "setFoo()" sets foo.
We should definively encourage our selves to write test code when we
refactor things. It is useful for checking that we don't break anything
and also documents our learnings about what the code does. Starting to
write test code for allready existing code just because it "should be
tested" is more than "a lot of work" it is IMO pretty close to wasting time.
/Daniel
Re: Supported and unsupported blocks
Posted by Torsten Curdt <tc...@apache.org>.
>>> ...Where shall we draw the line between "supported" and
>>> "unsupported"? Is it really the "two committers rule" that I applied
>>> above?...
>>
>>
>>
>> How about adding another condition: a block can only have "supported"
>> status if we have automated tests for all its critical functions?
>
>
>
> That's a very interesting point.
> +1, even if I'm not the most productive test writer :-)
>
>> This might make a big difference in the accountability of supported
>> stuff in our releases.
>
>
>
> Yep. But this also means the core is currently unsupported ;-P
Hehe... Well, time to write some test then ;-P
Actually I somehow like the idea of required tests!
And it would also clearly draw the line. Much better
than the two-committer rule.
...but a lot of work :-/
cheers
--
Torsten
Re: Supported and unsupported blocks
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Bertrand Delacretaz wrote:
>
>> Le 15 mars 05, à 10:14, Reinhard Poetz a écrit :
>>
>>> ...Where shall we draw the line between "supported" and
>>> "unsupported"? Is it really the "two committers rule" that I applied
>>> above?...
>>
>>
>> How about adding another condition: a block can only have "supported"
>> status if we have automated tests for all its critical functions?
Presense of the tests is enough, or you want to require that tests must run
without failures? ;-P
> That's a very interesting point.
> +1, even if I'm not the most productive test writer :-)
>
>> This might make a big difference in the accountability of supported
>> stuff in our releases.
>
>
> Yep. But this also means the core is currently unsupported ;-P
Including all of the blocks, as well.
Vadim
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 15 mars 05, à 23:13, Sylvain Wallez a écrit :
> ...Yep. But this also means the core is currently unsupported ;-P
Even if there are few direct tests of the core functionality, several
things are indirectly tested, through anteater and some other tests. We
might not have a precise idea of the coverage but it's probably not
that bad.
-Bertrand
Re: Supported and unsupported blocks
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 15 mars 05, à 10:14, Reinhard Poetz a écrit :
>
>> ...Where shall we draw the line between "supported" and
>> "unsupported"? Is it really the "two committers rule" that I applied
>> above?...
>
>
> How about adding another condition: a block can only have "supported"
> status if we have automated tests for all its critical functions?
That's a very interesting point.
+1, even if I'm not the most productive test writer :-)
> This might make a big difference in the accountability of supported
> stuff in our releases.
Yep. But this also means the core is currently unsupported ;-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Supported and unsupported blocks
Posted by Tim Larson <ti...@keow.org>.
On Wed, Mar 16, 2005 at 09:41:37AM -0500, Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
> >IMO it is an esential service for our users that we in a honest and
> >realistic way tell what we actually, in practicem, with real work,
> >support rather than what we whish we supported.
>
> And I think nobody disagrees with that. Status page (suggested somewhere up
> the thread) indicating the status of the block, some additional information
> about the block, etc, will accomplish this even with flat directory
> structure in SVN.
>
> What exactly changing directory structure buys you? If there is clear and
> structured documentation about the blocks (it can use structure like
> supported/unsupported/contributed/abandoned/whatever) and similarly
> structured hierarchy in the sample webapp, what, on top of this, directory
> structure in SVN gives?
>
> I'm not so against moving stuff, but I'm just trying to understand why to
> move.
I can live with dividing blocks up into directories and moving blocks
around occasionally if that is what we decide, but I have a hard time
understanding the reason for doing this, unless...
...are we dividing into separate directories so we can have separate
downloads, e.g. cocoon-core.tgz, cocoon-extras.tgz, etc.? If so,
then perhaps the distinction should be made by what is commonly used
together, rather than by how supported, tested, etc. the components
are (with an exception for truly experimental, not really released code.)
Otherwise we are just creating more decisions to make when developing
and downloading while not saving ourselves or our users any bandwidth.
I think it is very important to create the types of distinctions between
blocks which we are talking about (level of support, liveliness of
development, degree of test coverage, etc.) I just don't see the
benefit of doing this via division into directories. Directories only
allow for one dimension of grouping, and as we already see we have
several orthogonal concerns along which there is a tension to create
a clear categorization. Meta-data used to generate separate
documentation listings seems ideal for this usecase.
--Tim Larson
Re: Supported and unsupported blocks
Posted by Tim Larson <ti...@keow.org>.
On Wed, Mar 16, 2005 at 03:57:34PM +0100, Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
> >
> > And I think nobody disagrees with that. Status page (suggested somewhere up the
> > thread) indicating the status of the block, some additional information about
> > the block, etc, will accomplish this even with flat directory structure in SVN.
> >
> > What exactly changing directory structure buys you? If there is clear and
> > structured documentation about the blocks (it can use structure like
> > supported/unsupported/contributed/abandoned/whatever) and similarly structured
> > hierarchy in the sample webapp, what, on top of this, directory structure in SVN
> > gives?
> >
> > I'm not so against moving stuff, but I'm just trying to understand why to move.
> >
> Documenting the state is one thing, but imho just doing this in some
> descriptor isn't very visible. Who reads documentation or looks into a
> meta descriptor? :)
> So, by using a directory structure, it's immediately visible for everyone.
If the documentation is clear and easy to find and read, and the user
still does not bother to check it how are we going to give them any
help? ...by also putting this documentation where they will read it,
embedded in the samples pages, just like the current stable/unstable
distinction.
FWIW, When I evaluate other projects I view distinction of modules
via directories with a grain of salt, because I know there is a higher
threshold (more inertia) to moving directories around to mantain
an accurate reflection of status than to just update a descriptor.
--Tim Larson
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 12:11, Tim Larson dijo:
> On Wed, Mar 16, 2005 at 11:59:09AM -0600, Antonio Gallardo wrote:
>> On Mie, 16 de Marzo de 2005, 10:53, Reinhard Poetz dijo:
>> > Can anyone of you explain to me why it should be harmful following the
>> > proposed
>> > directory structure? I understand that some of you think that it is
>> > useless for
>> > you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some
>> others)
>> > appreciate this information at directory level.
>>
>> Upayavira already answered this.
>>
>> Lets start a vote? need we to discuss more the topic?
>
> I do not need to discuss more, as Upayavira captured my thoughts
> on the matter very well. Since we do not have a vote thread
> started yet, my *opinion* is +1 flat structure, -0 directories.
> (i.e. Strongly prefer flat, but would not try to veto directories.)
Same here.
Best Regards,
Antonio Gallardo.
>
> --Tim Larson
>
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>> If nobody stops me, I will put all blocks into
>> /cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It
>> will contain an element indicating the community status
>
>
> +1
>
>
>> and for now *all* blocks get the status "committed".
>
>
> What's "committed"? Do you mean "contributed", or "supported"?
meant "contributed", thanks Vadim
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> If nobody stops me, I will put all blocks into
> /cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It
> will contain an element indicating the community status
+1
> and for now
> *all* blocks get the status "committed".
What's "committed"? Do you mean "contributed", or "supported"?
Vadim
> If somebody wants to see a
> block somewhere else, he needs to start a vote (and for this voting the
> wiki page will be very helpful ...)
>
> So hopefully we can move on to some more productive work ;-)
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Bertrand Delacretaz wrote:
>
>> Le 16 mars 05, à 19:11, Tim Larson a écrit :
>>
>>> ...I do not need to discuss more, as Upayavira captured my thoughts
>>> on the matter very well. Since we do not have a vote thread
>>> started yet, my *opinion* is +1 flat structure, -0 directories.
>>> (i.e. Strongly prefer flat, but would not try to veto directories.)
>>
>>
>>
>> Same here - I do actually prefer a flat structure, with enough
>> metadata in block.xml (for example) to build a page with the status of
>> each block. More flexible and easier to manage.
>>
>> Reinhard, you put my name in the "people who support directories" list
>> - I do support whatever valuable work is being done, and classifying
>> blocks via directories is valuable IMHO. But given the choice I prefer
>> the "flat" option.
>
>
> First sorry for misinterpreting you. I also withdraw my proposal of
> putting blocks into a classifying directory structure (although I still
> think that the community status is *the* classifying property). I don't
> want to waste any further energy in this, as we have to do more
> important things.
>
> If nobody stops me, I will put all blocks into
> /cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It
> will contain an element indicating the community status and for now
> *all* blocks get the status "committed". If somebody wants to see a
> block somewhere else, he needs to start a vote (and for this voting the
> wiki page will be very helpful ...)
>
> So hopefully we can move on to some more productive work ;-)
>
Forgot to mention that I will wait with the move until after the infraton. So
there is some time if there are still some arguments against the move ...
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Bertrand Delacretaz wrote:
> Le 16 mars 05, à 19:11, Tim Larson a écrit :
>
>> ...I do not need to discuss more, as Upayavira captured my thoughts
>> on the matter very well. Since we do not have a vote thread
>> started yet, my *opinion* is +1 flat structure, -0 directories.
>> (i.e. Strongly prefer flat, but would not try to veto directories.)
>
>
> Same here - I do actually prefer a flat structure, with enough metadata
> in block.xml (for example) to build a page with the status of each
> block. More flexible and easier to manage.
>
> Reinhard, you put my name in the "people who support directories" list -
> I do support whatever valuable work is being done, and classifying
> blocks via directories is valuable IMHO. But given the choice I prefer
> the "flat" option.
First sorry for misinterpreting you. I also withdraw my proposal of putting
blocks into a classifying directory structure (although I still think that the
community status is *the* classifying property). I don't want to waste any
further energy in this, as we have to do more important things.
If nobody stops me, I will put all blocks into
/cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It will
contain an element indicating the community status and for now *all* blocks get
the status "committed". If somebody wants to see a block somewhere else, he
needs to start a vote (and for this voting the wiki page will be very helpful ...)
So hopefully we can move on to some more productive work ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 16 mars 05, à 19:11, Tim Larson a écrit :
> ...I do not need to discuss more, as Upayavira captured my thoughts
> on the matter very well. Since we do not have a vote thread
> started yet, my *opinion* is +1 flat structure, -0 directories.
> (i.e. Strongly prefer flat, but would not try to veto directories.)
Same here - I do actually prefer a flat structure, with enough metadata
in block.xml (for example) to build a page with the status of each
block. More flexible and easier to manage.
Reinhard, you put my name in the "people who support directories" list
- I do support whatever valuable work is being done, and classifying
blocks via directories is valuable IMHO. But given the choice I prefer
the "flat" option.
-Bertrand
Re: Supported and unsupported blocks
Posted by Tim Larson <ti...@keow.org>.
On Wed, Mar 16, 2005 at 11:59:09AM -0600, Antonio Gallardo wrote:
> On Mie, 16 de Marzo de 2005, 10:53, Reinhard Poetz dijo:
> > Can anyone of you explain to me why it should be harmful following the
> > proposed
> > directory structure? I understand that some of you think that it is
> > useless for
> > you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some others)
> > appreciate this information at directory level.
>
> Upayavira already answered this.
>
> Lets start a vote? need we to discuss more the topic?
I do not need to discuss more, as Upayavira captured my thoughts
on the matter very well. Since we do not have a vote thread
started yet, my *opinion* is +1 flat structure, -0 directories.
(i.e. Strongly prefer flat, but would not try to veto directories.)
--Tim Larson
Re: Supported and unsupported blocks
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 16 Mar 2005 19:27:23 +0100, Daniel Fagerstrom
<da...@nada.kth.se> wrote:
> Upayavira wrote:
> > Reinhard Poetz wrote:
<snip/>
> > It has been said that moving directories around is likely to cause
> > confusion - where has my block gone? etc.
>
> That's FUD, the whole lifecycle contributed->supported->deprecated is
> likely to take many years (for the few blocks that go through all
> three). And each step is a sigificant step in the blocks life and
> important for the users and is certainly not based on a sudden whim from
> the community.
Personally, I don't think that's FUD. No matter how long it takes for
a block to make the transition form one state to another the moment if
moves directories people are not going to know where it went.
If the block build process can automatically fetch my included blocks
no matter what directory they are located in then this a lot less of a
concern. Even then, people actually working on the block will have to
realize that block X moved and not keep working on "unstable/X" since
the version used by the build is now in "stable/X". Only moving
blocks on release boundaries would help here, but I'm not sure it
removes the problem.
So, until we have automatic block retrieval I'd vote for a flat structure.
<snip/>
> >
> > The principal argument against putting blocks into directories is that
> > we cannot know now what is the most significant designation of a block.
>
> We certainly know: community support is by far the most significant
> designation of a block.
A stable block that has worked for years and is never in need of
maintenance might be a very valuable contribution. Such things could
fall through the cracks if all you measure is how many people are
working on a block.
--
Peter Hunsberger
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 8:41, Carsten Ziegeler dijo:
> Daniel Fagerstrom wrote:
>>
>> Can't we put the whiteboard code in the trunk as well and let the
>> compile script decide what should be included in the builds based on
>> meta data in the source files ;)
>>
>> --- o0o ---
>>
>> Am I and Reinhard the only ones that are concerned about what the 50+
>> blocks in an unordered lump in Cocoon does for the perception about our
>> project?
>>
>> If we stop whishful thinking and feeling pitty for blocks with few
>> supporters for a while, it is enough to take a look at the SVN log to
>> see that we have our share of more or less abandoned one man shows.
>> There are quite a few blocks that hasn't been touched in any essentail
>> way for a year or more. Blocks where all work have been done by one
>> person, that in some cases haven't been around for long. Blocks that
>> nearly never are discussed on the list.
>>
>> IMO it is an esential service for our users that we in a honest and
>> realistic way tell what we actually, in practicem, with real work,
>> support rather than what we whish we supported.
>>
> Hmm, I thought we already agreed on putting blocks in different
> directories to give a better overview about the state of a block - but
> perhaps that's my weak memory...
Nope. It shows that people mind evolve with the time. This raise often on
the mail list. One month "X" is cool and three months later is'not. Or the
oposite. ;-)
> Anyways, I think we should *not* put all blocks in one directory. Moving
> things with svn is painless.
Just because SVN allow it, does not mean we need to use this feature. ;-)
Best Regards,
Antonio Gallardo.
Re: Supported and unsupported blocks
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> Can't we put the whiteboard code in the trunk as well and let the
> compile script decide what should be included in the builds based on
> meta data in the source files ;)
>
> --- o0o ---
>
> Am I and Reinhard the only ones that are concerned about what the 50+
> blocks in an unordered lump in Cocoon does for the perception about our
> project?
>
> If we stop whishful thinking and feeling pitty for blocks with few
> supporters for a while, it is enough to take a look at the SVN log to
> see that we have our share of more or less abandoned one man shows.
> There are quite a few blocks that hasn't been touched in any essentail
> way for a year or more. Blocks where all work have been done by one
> person, that in some cases haven't been around for long. Blocks that
> nearly never are discussed on the list.
>
> IMO it is an esential service for our users that we in a honest and
> realistic way tell what we actually, in practicem, with real work,
> support rather than what we whish we supported.
>
Hmm, I thought we already agreed on putting blocks in different
directories to give a better overview about the state of a block - but
perhaps that's my weak memory...
Anyways, I think we should *not* put all blocks in one directory. Moving
things with svn is painless.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> Reinhard Poetz wrote:
>
>>
>> This vote shows that at least one committer cares about the block (he
>> calls for a vote) and he has to list good reasons why he thinks that
>> it is stable (community, interfaces and implementation).
>>
>> Of course we can group a several of votes into one voting process to
>> avoid dozens of votings :-p
>
>
> If you are speaking of current blocks, this is backwards. Our policy is
> to require comments only on -1 votes. Therefore, only blocks to be
> marked unstable would require justification.
>
>
What I meant was that the person calling for a vote has to list the reasons why
he has the opinion that the status of a block has changed. If somebody starts a
vote without explaining why a block has reached e.g. "supported", I would vote
-1 and maybe I'm not the only one.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
>
> This vote shows that at least one committer cares about the block (he
> calls for a vote) and he has to list good reasons why he thinks that
> it is stable (community, interfaces and implementation).
>
> Of course we can group a several of votes into one voting process to
> avoid dozens of votings :-p
If you are speaking of current blocks, this is backwards. Our policy is
to require comments only on -1 votes. Therefore, only blocks to be
marked unstable would require justification.
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Antonio Gallardo wrote:
> On Mie, 16 de Marzo de 2005, 10:17, Daniel Fagerstrom dijo:
>
>>Everything can be done in numerous ways.
>>
>>The directory structure is easy to understand, it is what we have
>>discussed at the list for quite a while, it is what Reinhard actually
>>have implemented and above all it moves us forward.
>>
>>There should of course be a metadata file for the block as well and
>>documentation generated from that. But AFAIK no one have started to work
>>on any such documentation functinonallity. So for the moment I think we
>>should focus on the *important* question:
>>
>>Which blocks do we support?
>
>
> Well, this is a hard question. I read all the mails related to this topic
> and still I don't have a decision:
>
> 1-"The blocks used for my company will be supported by me". I guess every
> committer already did that. So I don't see here a problem, but.....
>
> 2-"Blocks not used by 'me', but are interesting or have big potential
> success". This is the hard question. How I can know if a block has
> potential success between people?. Even we know that cocoon has potential,
> but a lot of people don't use it. I hope this illustrate what I have in
> mind.
>
> In my case, in the first fill of the wiki Block poll, I added some blocks
> that I don't need for my work and never used it, but I found interesting
> and already worked on them just for fun. For example, qdox.
>
> In the second raid, I checked other blocks where I already worked outside
> my own interests, just for the community follwing some bugzilla reports
> and I hope I can use some time in the future to support in this way again.
>
> I know we have a problem, people wants to drops some blocks from his own
> POV. But perhaps this blocks are used by other people.
I think this isn't that difficult. If someone wants a block being marked as
"supported" he has to call for a vote. This vote has to be well-grounded:
-----------------------------------------------------------------------------
[Vote] Community support for block xyz
We (committer1, committer2, committer3) are working on block xyz and consider it
as stable. It provides support for bla, bla, bla, ... and comes with an
extensive suite of test cases. The interfaces bla, bla, bla are stable and the
implementation is stable as well and used in many projects.
[ ] mark block xyz as "supported"
[ ] block xyz isn't mature enough
Please cast your votes!
-----------------------------------------------------------------------------
This vote shows that at least one committer cares about the block (he calls for
a vote) and he has to list good reasons why he thinks that it is stable
(community, interfaces and implementation).
Of course we can group a several of votes into one voting process to avoid
dozens of votings :-p
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 10:17, Daniel Fagerstrom dijo:
> Everything can be done in numerous ways.
>
> The directory structure is easy to understand, it is what we have
> discussed at the list for quite a while, it is what Reinhard actually
> have implemented and above all it moves us forward.
>
> There should of course be a metadata file for the block as well and
> documentation generated from that. But AFAIK no one have started to work
> on any such documentation functinonallity. So for the moment I think we
> should focus on the *important* question:
>
> Which blocks do we support?
Well, this is a hard question. I read all the mails related to this topic
and still I don't have a decision:
1-"The blocks used for my company will be supported by me". I guess every
committer already did that. So I don't see here a problem, but.....
2-"Blocks not used by 'me', but are interesting or have big potential
success". This is the hard question. How I can know if a block has
potential success between people?. Even we know that cocoon has potential,
but a lot of people don't use it. I hope this illustrate what I have in
mind.
In my case, in the first fill of the wiki Block poll, I added some blocks
that I don't need for my work and never used it, but I found interesting
and already worked on them just for fun. For example, qdox.
In the second raid, I checked other blocks where I already worked outside
my own interests, just for the community follwing some bugzilla reports
and I hope I can use some time in the future to support in this way again.
I know we have a problem, people wants to drops some blocks from his own
POV. But perhaps this blocks are used by other people.
Best Regards,
Antonio Gallardo.
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Antonio Gallardo wrote:
>On Mie, 16 de Marzo de 2005, 9:59, Daniel Fagerstrom dijo:
>
>
<snip/>
>>The proposed life cycle of block is rather:
>>
>>* You get a cool new idea and create a contributed block.
>>* After a while it might have happened that a number of other developers
>>also have become interested in the block and have started to contribute.
>>At this point someone starts a vote about that the block should become a
>>supported block, and people agree.
>>* After some years it might happen that new technology or something else
>>makes the block less relevant and someone start a vote about deprecating
>>it.
>>
>>
>
>The lifecycle was agreed for the community, the point is if a directory
>structure is the best to implement it. Other people (me included) think it
>can be implemented using the metadata file that all in all every block
>will have.
>
>
Everything can be done in numerous ways.
The directory structure is easy to understand, it is what we have
discussed at the list for quite a while, it is what Reinhard actually
have implemented and above all it moves us forward.
There should of course be a metadata file for the block as well and
documentation generated from that. But AFAIK no one have started to work
on any such documentation functinonallity. So for the moment I think we
should focus on the *important* question:
Which blocks do we support?
/Daniel
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 9:59, Daniel Fagerstrom dijo:
> Antonio Gallardo wrote:
>
>>On Mie, 16 de Marzo de 2005, 8:25, Daniel Fagerstrom dijo:
>>
>>
> <snip/>
>
>>>Am I and Reinhard the only ones that are concerned about what the 50+
>>>blocks in an unordered lump in Cocoon does for the perception about our
>>>project?
>>>
>>>
>>
>>Well, I need to say I am not concerned. Playing with the directory
>>structure is not good. I can see in the future people mails:
>>
>> - O -
>>
>>mail: "I canot find the block 'X' in the 'supported' dir as is stated in
>>the mail 'Y'.
>>reply: "No it was noved to contributted lat week on the SVN"
>>re:reply: "It will be on the "resurected" block the next week
>>
>>
> You are exagerating quite a bit ;)
Yep. I know. But the mails will be there.
> The proposed life cycle of block is rather:
>
> * You get a cool new idea and create a contributed block.
> * After a while it might have happened that a number of other developers
> also have become interested in the block and have started to contribute.
> At this point someone starts a vote about that the block should become a
> supported block, and people agree.
> * After some years it might happen that new technology or something else
> makes the block less relevant and someone start a vote about deprecating
> it.
The lifecycle was agreed for the community, the point is if a directory
structure is the best to implement it. Other people (me included) think it
can be implemented using the metadata file that all in all every block
will have.
Best Regards,
Antonio Gallardo
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Upayavira wrote:
> Reinhard Poetz wrote:
>> Can anyone of you explain to me why it should be harmful following the
>> proposed directory structure? I understand that some of you think that
>> it is useless for you, but some of us (Carsten, Daniel, Bertrand, I,
>> and maybe some others) appreciate this information at directory level.
>
> I personally prefer a flat structure.
>
> We are following a flat structure for our documentation - there we have
> seen that hierarchies can be problematic on the source level.
>
> But we can overlay heirearchies at a navigational level, and we can have
> multiple orthoganal hierarchies covering a set of items in the flat
> structure.
Community support is not another hierarchial level among thousands, it
is *the currency* in open software development.
> It has been said that moving directories around is likely to cause
> confusion - where has my block gone? etc.
That's FUD, the whole lifecycle contributed->supported->deprecated is
likely to take many years (for the few blocks that go through all
three). And each step is a sigificant step in the blocks life and
important for the users and is certainly not based on a sudden whim from
the community.
> Build processes can read the meta info for a block and use it to both
> build documentation specifying which blocks are stable, verified, etc,
> and also package all stable blocks together, all contributed ones, all
> verified ones, or all blocks relating to a particular task, etc.
>
> The principal argument against putting blocks into directories is that
> we cannot know now what is the most significant designation of a block.
We certainly know: community support is by far the most significant
designation of a block.
/Daniel
Re: Supported and unsupported blocks
Posted by Upayavira <uv...@upaya.co.uk>.
Reinhard Poetz wrote:
> Antonio Gallardo wrote:
>
>> On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
>>
>>> So, what about a simple "the majority wins"? wrt to the directory
>>> structure? We do a vote and whatever gets more voices will be done.
>>
>>
>>
>> Good idea! Lets vote about this topic.
>
>
> Can anyone of you explain to me why it should be harmful following the
> proposed directory structure? I understand that some of you think that
> it is useless for you, but some of us (Carsten, Daniel, Bertrand, I, and
> maybe some others) appreciate this information at directory level.
I personally prefer a flat structure.
We are following a flat structure for our documentation - there we have
seen that hierarchies can be problematic on the source level.
But we can overlay heirearchies at a navigational level, and we can have
multiple orthoganal hierarchies covering a set of items in the flat
structure.
It has been said that moving directories around is likely to cause
confusion - where has my block gone? etc.
Build processes can read the meta info for a block and use it to both
build documentation specifying which blocks are stable, verified, etc,
and also package all stable blocks together, all contributed ones, all
verified ones, or all blocks relating to a particular task, etc.
The principal argument against putting blocks into directories is that
we cannot know now what is the most significant designation of a block.
Moving blocks into other directories is likely to be disruptive. Simply
adding another line into the meta-data file isn't likely to be disruptive.
There's my thoughts. Does that help?
Regards, Upayavira
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 10:53, Reinhard Poetz dijo:
> Antonio Gallardo wrote:
>> On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
>>
>>>So, what about a simple "the majority wins"? wrt to the directory
>>>structure? We do a vote and whatever gets more voices will be done.
>>
>>
>> Good idea! Lets vote about this topic.
>
> Can anyone of you explain to me why it should be harmful following the
> proposed
> directory structure? I understand that some of you think that it is
> useless for
> you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some others)
> appreciate this information at directory level.
Upayavira already answered this.
Lets start a vote? need we to discuss more the topic?
Best Regards,
Antonio Gallardo.
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Antonio Gallardo wrote:
> On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
>
>>So, what about a simple "the majority wins"? wrt to the directory
>>structure? We do a vote and whatever gets more voices will be done.
>
>
> Good idea! Lets vote about this topic.
Can anyone of you explain to me why it should be harmful following the proposed
directory structure? I understand that some of you think that it is useless for
you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some others)
appreciate this information at directory level.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
> So, what about a simple "the majority wins"? wrt to the directory
> structure? We do a vote and whatever gets more voices will be done.
Good idea! Lets vote about this topic.
Best Regards,
Antonio Gallardo
Re: Supported and unsupported blocks
Posted by Carsten Ziegeler <cz...@apache.org>.
Ok, I think we can discuss this for ages. Some of us like to emphasize
the state of a block by an equal directory structure, some not.
I think we all agree, that the meta information about a block should
also contain this info.
So, what about a simple "the majority wins"? wrt to the directory
structure? We do a vote and whatever gets more voices will be done.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Antonio Gallardo wrote:
>On Mie, 16 de Marzo de 2005, 8:25, Daniel Fagerstrom dijo:
>
>
<snip/>
>>Am I and Reinhard the only ones that are concerned about what the 50+
>>blocks in an unordered lump in Cocoon does for the perception about our
>>project?
>>
>>
>
>Well, I need to say I am not concerned. Playing with the directory
>structure is not good. I can see in the future people mails:
>
> - O -
>
>mail: "I canot find the block 'X' in the 'supported' dir as is stated in
>the mail 'Y'.
>reply: "No it was noved to contributted lat week on the SVN"
>re:reply: "It will be on the "resurected" block the next week
>
>
You are exagerating quite a bit ;) The proposed life cycle of block is
rather:
* You get a cool new idea and create a contributed block.
* After a while it might have happened that a number of other developers
also have become interested in the block and have started to contribute.
At this point someone starts a vote about that the block should become a
supported block, and people agree.
* After some years it might happen that new technology or something else
makes the block less relevant and someone start a vote about deprecating it.
/Daniel
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 8:25, Daniel Fagerstrom dijo:
> Vadim Gritsenko wrote:
>
>> Tim Larson wrote:
>>
>>> On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
>>>
>>>> Vadim Gritsenko wrote:
>>>>
>>>>> Reinhard Poetz wrote:
>>>>>
>>>>>> I propose to reflect these lifecycle-states in our SVN directory
>>>>>> structure.
>>>>>
>>>>>
>>>>>
>>>>> Why do you think directory structure is required here at all?
>>>>> What's wrong with plain list of all blocks in one directory?
>>>>
>>>>
>>>> IIRC the idea was to give a quick overview of the current status.
>>>> Having a list iwth 50+ blocks makes it more difficult.
>>>
>>>
>>>
>>> This overview can be accomplished in better ways than by inducing
>>> churn in the svn archive as projects change state.
>>
> Moving things in SVN is not that hard.
>
>>>
>>> Why not just make the current state of a block be reflected in its
>>> meta-data and then use this to generate documentation pages with
>>> separate lists of the groups of blocks in different states?
>>
>>
>> And we already have this for stable/unstable blocks - see
>> .../samples/blocks/.
>>
>> Vadim
>
> Can't we put the whiteboard code in the trunk as well and let the
> compile script decide what should be included in the builds based on
> meta data in the source files ;)
>
> --- o0o ---
>
> Am I and Reinhard the only ones that are concerned about what the 50+
> blocks in an unordered lump in Cocoon does for the perception about our
> project?
Well, I need to say I am not concerned. Playing with the directory
structure is not good. I can see in the future people mails:
- O -
mail: "I canot find the block 'X' in the 'supported' dir as is stated in
the mail 'Y'.
reply: "No it was noved to contributted lat week on the SVN"
re:reply: "It will be on the "resurected" block the next week
- O -
And I don't see where is the real block deal when still they have a core
dependency with a cocoon directory structure. I think the "status" of the
block should be orthonal to the place where it is stored. What if we are
going to store some block on sourceforge? Where will be there the "right"
location, etc.
Block status should be included in a meta attributes file.
Best Regards,
Antonio Gallardo.
> If we stop whishful thinking and feeling pitty for blocks with few
> supporters for a while, it is enough to take a look at the SVN log to
> see that we have our share of more or less abandoned one man shows.
> There are quite a few blocks that hasn't been touched in any essentail
> way for a year or more. Blocks where all work have been done by one
> person, that in some cases haven't been around for long. Blocks that
> nearly never are discussed on the list.
>
> IMO it is an esential service for our users that we in a honest and
> realistic way tell what we actually, in practicem, with real work,
> support rather than what we whish we supported.
>
> /Daniel
>
Re: Supported and unsupported blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 16 de Marzo de 2005, 8:57, Carsten Ziegeler dijo:
> Vadim Gritsenko wrote:
>>
>> And I think nobody disagrees with that. Status page (suggested somewhere
>> up the
>> thread) indicating the status of the block, some additional information
>> about
>> the block, etc, will accomplish this even with flat directory structure
>> in SVN.
>>
>> What exactly changing directory structure buys you? If there is clear
>> and
>> structured documentation about the blocks (it can use structure like
>> supported/unsupported/contributed/abandoned/whatever) and similarly
>> structured
>> hierarchy in the sample webapp, what, on top of this, directory
>> structure in SVN
>> gives?
>>
>> I'm not so against moving stuff, but I'm just trying to understand why
>> to move.
>>
> Documenting the state is one thing, but imho just doing this in some
> descriptor isn't very visible. Who reads documentation or looks into a
> meta descriptor? :)
> So, by using a directory structure, it's immediately visible for everyone.
We can generate automatically a forrest page with this info in the same
sense as we generate now the ant build.xml for blocks. It will be pretty
easy to do. In short, this is not an argument for a directory structure.
Best Regards,
Antonio Gallardo.
Re: Supported and unsupported blocks
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
>
> And I think nobody disagrees with that. Status page (suggested somewhere up the
> thread) indicating the status of the block, some additional information about
> the block, etc, will accomplish this even with flat directory structure in SVN.
>
> What exactly changing directory structure buys you? If there is clear and
> structured documentation about the blocks (it can use structure like
> supported/unsupported/contributed/abandoned/whatever) and similarly structured
> hierarchy in the sample webapp, what, on top of this, directory structure in SVN
> gives?
>
> I'm not so against moving stuff, but I'm just trying to understand why to move.
>
Documenting the state is one thing, but imho just doing this in some
descriptor isn't very visible. Who reads documentation or looks into a
meta descriptor? :)
So, by using a directory structure, it's immediately visible for everyone.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Supported and unsupported blocks
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> IMO it is an esential service for our users that we in a honest and
> realistic way tell what we actually, in practicem, with real work,
> support rather than what we whish we supported.
And I think nobody disagrees with that. Status page (suggested somewhere up the
thread) indicating the status of the block, some additional information about
the block, etc, will accomplish this even with flat directory structure in SVN.
What exactly changing directory structure buys you? If there is clear and
structured documentation about the blocks (it can use structure like
supported/unsupported/contributed/abandoned/whatever) and similarly structured
hierarchy in the sample webapp, what, on top of this, directory structure in SVN
gives?
I'm not so against moving stuff, but I'm just trying to understand why to move.
Vadim
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Tim Larson wrote:
>
>> On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Reinhard Poetz wrote:
>>>>
>>>>> I propose to reflect these lifecycle-states in our SVN directory
>>>>> structure.
>>>>
>>>>
>>>>
>>>> Why do you think directory structure is required here at all?
>>>> What's wrong with plain list of all blocks in one directory?
>>>
>>>
>>> IIRC the idea was to give a quick overview of the current status.
>>> Having a list iwth 50+ blocks makes it more difficult.
>>
>>
>>
>> This overview can be accomplished in better ways than by inducing
>> churn in the svn archive as projects change state.
>
Moving things in SVN is not that hard.
>>
>> Why not just make the current state of a block be reflected in its
>> meta-data and then use this to generate documentation pages with
>> separate lists of the groups of blocks in different states?
>
>
> And we already have this for stable/unstable blocks - see
> .../samples/blocks/.
>
> Vadim
Can't we put the whiteboard code in the trunk as well and let the
compile script decide what should be included in the builds based on
meta data in the source files ;)
--- o0o ---
Am I and Reinhard the only ones that are concerned about what the 50+
blocks in an unordered lump in Cocoon does for the perception about our
project?
If we stop whishful thinking and feeling pitty for blocks with few
supporters for a while, it is enough to take a look at the SVN log to
see that we have our share of more or less abandoned one man shows.
There are quite a few blocks that hasn't been touched in any essentail
way for a year or more. Blocks where all work have been done by one
person, that in some cases haven't been around for long. Blocks that
nearly never are discussed on the list.
IMO it is an esential service for our users that we in a honest and
realistic way tell what we actually, in practicem, with real work,
support rather than what we whish we supported.
/Daniel
Re: Supported and unsupported blocks
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Tim Larson wrote:
> On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
>
>>Vadim Gritsenko wrote:
>>
>>>Reinhard Poetz wrote:
>>>
>>>>I propose to reflect these lifecycle-states in our SVN directory
>>>>structure.
>>>
>>>
>>>Why do you think directory structure is required here at all? What's
>>>wrong with plain list of all blocks in one directory?
>>
>>IIRC the idea was to give a quick overview of the current status. Having a
>>list iwth 50+ blocks makes it more difficult.
>
>
> This overview can be accomplished in better ways than by inducing
> churn in the svn archive as projects change state.
>
> Why not just make the current state of a block be reflected in its
> meta-data and then use this to generate documentation pages with
> separate lists of the groups of blocks in different states?
And we already have this for stable/unstable blocks - see .../samples/blocks/.
Vadim
Re: Supported and unsupported blocks
Posted by Tim Larson <ti...@keow.org>.
On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
> >Reinhard Poetz wrote:
> >
> >>I propose to reflect these lifecycle-states in our SVN directory
> >>structure.
> >
> >
> >Why do you think directory structure is required here at all? What's
> >wrong with plain list of all blocks in one directory?
>
> IIRC the idea was to give a quick overview of the current status. Having a
> list iwth 50+ blocks makes it more difficult.
This overview can be accomplished in better ways than by inducing
churn in the svn archive as projects change state.
Why not just make the current state of a block be reflected in its
meta-data and then use this to generate documentation pages with
separate lists of the groups of blocks in different states?
--Tim Larson
Re: Supported and unsupported blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Bertrand Delacretaz wrote:
>
>> Le 16 mars 05, à 09:29, Reinhard Poetz a écrit :
>>
>>> ...Remains the question: What shall we do with and call
>>> "unsupported/unverified" blocks?...
>>
>>
>>
>> Why not put them in a "contributed" area? We'd make no guarantees
>> about them (not even that they compile), and over time they might
>> move elsewhere or be abandoned. More or less like the scratchpad of
>> today.
>>
>> The initial move would be to put as many blocks there as possible,
>> and maybe move them back to "higher ground" later if there is actual
>> support for them in the community.
>
>
> My second search was more successful and I found
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106443770412993&w=2
> which already contains an excellent proposal by Stefano:
>
> +------------------(rebirth)-----------------+
> v |
> -(birth)-> [contributed] ----------(death)---------> [deprecated]
> | ^
> +--(maturity)-> [supported] --(retirement)---+
>
>
>
> So we have following lifecycle states:
>
> - contributed
> - supported
> - deprecated
>
> blocks.
>
> The "verified" status could be orthogonal to these lifecycle-states
> and is an indicator of a (to be definded) block's quality (tested,
> stable interfaces, stable implementation, supported by community, ...)
>
>
> Addtionally I like Betrands idea
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2)
> of a narrative status description:
>
> "Yes - and maybe we shouldn't impose too much structure on this weather
> report, just require that block providers have one "block status"
> documentation page, where they tell people about contract stability,
> API stability, future plans, active contributors and the like."
>
> I think we should provide some structure by providing a template that
> has some mandatory parts and a free text part.
>
> - o -
>
> I propose to reflect these lifecycle-states in our SVN directory
> structure. Additionally we should add the directories "samples" and
> "core".
>
> /cocoon/blocks/contributed
> /cocoon/blocks/supported
> /cocoon/blocks/deprecated
> /cocoon/blocks/core
> /cocoon/blocks/samples
>
> Remains the question, where do "mini-apps" like the querybean fit in?
> In contrary to sample-blocks they have a lifecycle IMO. I'm not sure
> whether a distinction between "functional blocks" and "mini-apps" on
> SVN directory level really makes sense. For now I propose to put
> mini-apps into "contributed", "supported" or "deprecated" and if we
> get swamped with "mini-apps" we can find another solution if it is
> necessary.
>
> WDOT?
>
+1
I agree about all of it. Contributed is more to the point than
unsupported and doesn't have the negative conotation.
/Daniel
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 16 mars 05, à 10:28, Reinhard Poetz a écrit :
> ...So we have following lifecycle states:
> - contributed
> - supported
> - deprecated
> blocks.
+1
> ...The "verified" status could be orthogonal to these lifecycle-states
> and is an indicator of a (to be definded) block's quality (tested,
> stable interfaces, stable implementation, supported by community,
> ...)..
+1
> Addtionally I like Betrands idea
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2)
> of a narrative status description:...
/me has no memory but the archives do ;-)
> ..."Yes - and maybe we shouldn't impose too much structure on this
> weather
> report, just require that block providers have one "block status"
> documentation page, where they tell people about contract stability,
> API stability, future plans, active contributors and the like."
>
> I think we should provide some structure by providing a template that
> has some mandatory parts and a free text part...
+1. One of the mandatory parts should be "automated tests coverage".
> ...I propose to reflect these lifecycle-states in our SVN directory
> structure. Additionally we should add the directories "samples" and
> "core".
>
> /cocoon/blocks/contributed
> /cocoon/blocks/supported
> /cocoon/blocks/deprecated
> /cocoon/blocks/core
> /cocoon/blocks/samples
+1
> ...For now I propose to put mini-apps into "contributed", "supported"
> or "deprecated" and if we get swamped with "mini-apps" we can find
> another solution if it is necessary...
good enough, +1
> WDOT?
Thanks for digging up this info, I'm all +1s as you can see, this looks
good!
-Bertrand
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>> I propose to reflect these lifecycle-states in our SVN directory
>> structure.
>
>
> Why do you think directory structure is required here at all? What's
> wrong with plain list of all blocks in one directory?
IIRC the idea was to give a quick overview of the current status. Having a list
iwth 50+ blocks makes it more difficult.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> I propose to reflect these lifecycle-states in our SVN directory
> structure.
Why do you think directory structure is required here at all? What's wrong with
plain list of all blocks in one directory?
Vadim
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Bertrand Delacretaz wrote:
> Le 16 mars 05, à 09:29, Reinhard Poetz a écrit :
>
>> ...Remains the question: What shall we do with and call
>> "unsupported/unverified" blocks?...
>
>
> Why not put them in a "contributed" area? We'd make no guarantees about
> them (not even that they compile), and over time they might move
> elsewhere or be abandoned. More or less like the scratchpad of today.
>
> The initial move would be to put as many blocks there as possible, and
> maybe move them back to "higher ground" later if there is actual support
> for them in the community.
My second search was more successful and I found
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106443770412993&w=2 which
already contains an excellent proposal by Stefano:
+------------------(rebirth)-----------------+
v |
-(birth)-> [contributed] ----------(death)---------> [deprecated]
| ^
+--(maturity)-> [supported] --(retirement)---+
So we have following lifecycle states:
- contributed
- supported
- deprecated
blocks.
The "verified" status could be orthogonal to these lifecycle-states and is an
indicator of a (to be definded) block's quality (tested, stable interfaces,
stable implementation, supported by community, ...)
Addtionally I like Betrands idea
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2) of a
narrative status description:
"Yes - and maybe we shouldn't impose too much structure on this weather
report, just require that block providers have one "block status"
documentation page, where they tell people about contract stability,
API stability, future plans, active contributors and the like."
I think we should provide some structure by providing a template that has some
mandatory parts and a free text part.
- o -
I propose to reflect these lifecycle-states in our SVN directory structure.
Additionally we should add the directories "samples" and "core".
/cocoon/blocks/contributed
/cocoon/blocks/supported
/cocoon/blocks/deprecated
/cocoon/blocks/core
/cocoon/blocks/samples
Remains the question, where do "mini-apps" like the querybean fit in? In
contrary to sample-blocks they have a lifecycle IMO. I'm not sure whether a
distinction between "functional blocks" and "mini-apps" on SVN directory level
really makes sense. For now I propose to put mini-apps into "contributed",
"supported" or "deprecated" and if we get swamped with "mini-apps" we can find
another solution if it is necessary.
WDOT?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 16 mars 05, à 09:29, Reinhard Poetz a écrit :
> ...Remains the question: What shall we do with and call
> "unsupported/unverified" blocks?...
Why not put them in a "contributed" area? We'd make no guarantees about
them (not even that they compile), and over time they might move
elsewhere or be abandoned. More or less like the scratchpad of today.
The initial move would be to put as many blocks there as possible, and
maybe move them back to "higher ground" later if there is actual
support for them in the community.
-Bertrand
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
Bertrand Delacretaz wrote:
> Le 16 mars 05, à 08:35, Reinhard Poetz a écrit :
>
>> ...I like the connotation of "verified" as well, but I'm not sure if
>> we should reflect this status in our directory system....
>
>
> Actually the "verified" status is probably orthogonal to the other
> classifications.
>
> Could it be an attribute in block.xml?
>
> We could then have "supported/unverified" blocks that we do our best to
> maintain, but without having enough automated tests, and
> "supported/verified" blocks which we feel have enough (successful ;-)
> automated tests to be easily testable by users on their own platforms
> and environments.
Remains the question: What shall we do with and call "unsupported/unverified"
blocks?
I can't help myself but I have the impression that the whole "block status
thing" isn't well-thought-through ... I remember that we had the discussion ages
ago and we have already found a good solution. Any pointers?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 16 mars 05, à 08:35, Reinhard Poetz a écrit :
> ...I like the connotation of "verified" as well, but I'm not sure if
> we should reflect this status in our directory system....
Actually the "verified" status is probably orthogonal to the other
classifications.
Could it be an attribute in block.xml?
We could then have "supported/unverified" blocks that we do our best to
maintain, but without having enough automated tests, and
"supported/verified" blocks which we feel have enough (successful ;-)
automated tests to be easily testable by users on their own platforms
and environments.
-Bertrand
Re: Supported and unsupported blocks
Posted by Reinhard Poetz <re...@apache.org>.
David Crossley wrote:
> Bertrand Delacretaz wrote:
>
>>How about adding another condition: a block can only have "supported"
>>status if we have automated tests for all its critical functions?
>>
>>This might make a big difference in the accountability of supported
>>stuff in our releases.
>
>
> That is a great idea. Then rather than calling them "supported"
> we can call them "tested" or "verified". Much better connotation.
I like the connotation of "verified" as well, but I'm not sure if we should
reflect this status in our directory system. IMHO the release of a block can be
verified but I'm not sure if a block in SVN can be verified. Think of a block
that is verified and then it is refactored or a major enhancement is added. Does
it still meet all requirements (tested, peer-reviewed, ...) afterwards? Maybe,
but maybe not. If not, do we move it into another directory, although the last
release was verified?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Supported and unsupported blocks
Posted by David Crossley <cr...@apache.org>.
Bertrand Delacretaz wrote:
> How about adding another condition: a block can only have "supported"
> status if we have automated tests for all its critical functions?
>
> This might make a big difference in the accountability of supported
> stuff in our releases.
That is a great idea. Then rather than calling them "supported"
we can call them "tested" or "verified". Much better connotation.
--David
Re: Supported and unsupported blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 15 mars 05, à 10:14, Reinhard Poetz a écrit :
> ...Where shall we draw the line between "supported" and "unsupported"?
> Is it really the "two committers rule" that I applied above?...
How about adding another condition: a block can only have "supported"
status if we have automated tests for all its critical functions?
This might make a big difference in the accountability of supported
stuff in our releases.
-Bertrand