use of whiteboard in forrest

[Tim Williams <wi...@gmail.com>]

Can someone describe the intended use of the whiteboard in our svn? 
Is it a committers playground for project-related stuff?  I'm unclear
when it should be used.
Thanks,
--tim

Re: use of whiteboard in forrest

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
> Can someone describe the intended use of the whiteboard in our svn? 
> Is it a committers playground for project-related stuff?  I'm unclear
> when it should be used.

You know, this is a really good question. I don't know that we have ever 
actually defined what it is used for. I'll tell you what *I* use it for:

Often I build basic code (usually plugins) that fits a very specific 
requirement but is not polished enough in the sense of being easily 
configurable to adaption for other use cases. I therefore put this code 
in the whiteboard in the hope that someone will find it useful and 
enhance it.

However, now that plugins are versioned I don't know that this is a 
legitimate use. Since if a plugin is usable it should be released as a 
0.1 or even a 0.1-dev

A second use I make of the whiteboard is if I am experimenting with a 
way of implementing something. This can be seen with the Daisy plugin 
where I am not yet convinced that my approach is the correct approach 
and I need to play around a little. Another example of this is 
forrest:views which may change their interfaces before going into trunk.

This second usage would be replaced if we decide to go with my SVN 
reorganisation proposal since each plugin will have its own trunk and 
branches.

Perhaps we should use this thread to decide how we should use 
Whiteboard. I have noticed that it becomes a kind of "graveyard" for 
half finished code if it is not carefully managed.

Ross

Re: use of whiteboard in forrest

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> On Sat, 2005-08-27 at 14:51 +0100, Ross Gardler wrote:
> 
>>David Crossley wrote:
>>
>>>Thorsten Scherler wrote:
>>>
>>>
>>>>c) refactoring of "old" code into a new version which would break the
>>>>usability of the old code while refactoring.
>>>
>>>
>>>I think that would be better done in a branch.
>>
>>
>>+1
> 
> 
> Actually I was referring to your example of refactoring the Daisy
> plugin. I have chosen different wording I have to admit.

The "refactoring" of the Daisy plugin is a good example of code that 
should be done in a branch. I broke some functionality of the 0.1 plugin 
during this refactoring whilst I worked out how it should be done. In 
this case it was done in the locationmap branch because it used the 
locationmap. If I'd done it in core then it would not have always been 
releasable.

If it had been a straight refactoring (tidying of code) I would agree 
with you though.

NOTE: If we agree to move all plugins out into a separate repo module we 
will be able to branch individual plugins.

> IMO branches should only be used if necessary. Refactoring code not
> always have to be done in branches. If they are components that can be
> capsuled then they should be refactored in "incubation". That is more
> efficient (I do not have to check out a whole branch).

Plugins cannot have a version in whiteboard/incubation and one in the 
core - their names would clash. This is another good reason to move 
plugins into their own repo, we can then branch just that plugin code 
and not the whole tree.

> Core code normally do not allow that, another good reason to try to make
> the core as small as possible. 

+1

Ross

Re: use of whiteboard in forrest

[Thorsten Scherler <th...@apache.org>]

On Sat, 2005-08-27 at 14:51 +0100, Ross Gardler wrote:
> David Crossley wrote:
> > Thorsten Scherler wrote:
> > 
> >>c) refactoring of "old" code into a new version which would break the
> >>usability of the old code while refactoring.
> > 
> > 
> > I think that would be better done in a branch.
> 
> 
> +1

Actually I was referring to your example of refactoring the Daisy
plugin. I have chosen different wording I have to admit.

IMO branches should only be used if necessary. Refactoring code not
always have to be done in branches. If they are components that can be
capsuled then they should be refactored in "incubation". That is more
efficient (I do not have to check out a whole branch).

Core code normally do not allow that, another good reason to try to make
the core as small as possible. 

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: use of whiteboard in forrest

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> Thorsten Scherler wrote:
> 
>>c) refactoring of "old" code into a new version which would break the
>>usability of the old code while refactoring.
> 
> 
> I think that would be better done in a branch.


+1

Ross

Re: use of whiteboard in forrest

[David Crossley <cr...@apache.org>]

Thorsten Scherler wrote:
> c) refactoring of "old" code into a new version which would break the
> usability of the old code while refactoring.

I think that would be better done in a branch.

-David

Re: use of whiteboard in forrest

[Thorsten Scherler <th...@apache.org>]

On Fri, 2005-08-26 at 12:28 -0400, Tim Williams wrote:
> Can someone describe the intended use of the whiteboard in our svn? 
> Is it a committers playground for project-related stuff?  I'm unclear
> when it should be used.
> Thanks,
> --tim

In lenya we call it sandbox which sounds like your playground. ;-)

The whiteboard should be renamed because its name is missleading. I
would rename it to incubator. Funny that http://incubator.apache.org/
has a tab "Whiteboard" which actually leads the user to the incubator
wiki (which makes a lot of sense when you are thinking about that
name). ;-)

The main purpose of the whiteboard is code incubation. 
a) some code may be not finally finished but should be in the rep.
Sometimes this code have known bugs that needs fixing before it can go
out of this incubation.
b) some new feature may be bug free but still need some more community
support around it. We want prevent that components are getting "one-man"
shows which makes them hard to maintain in the future.
c) refactoring of "old" code into a new version which would break the
usability of the old code while refactoring.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)