cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Supported and unsupported blocks
Date Wed, 16 Mar 2005 15:45:15 GMT
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
>


Mime
View raw message