PATCHES: Release Suggestion

[Joe Doran]

Kenichi wrote:-

> What you're saying is to create extreame number of branches.  This
> itself is possible. We well have many branches that work.  But how
> do we put them togather? Who manages differences between each

I would see a patch exist against an existing public release be it 2.0.7
or next 2.2 when released as you say..

> We are sure that we need more people who can look at patch, attach
> it to "current" code ( we need it to be "current" for patch might
> stand on older "public" version ).


That way the code base is a stable existing one. IOW patches against
development versions is another issue all togather. I agree that the
development branches move so quickly that it would be very difficult to
keep track of. There are a lot of people who use the released versions
of samba who in their own environment spot a bug or feature that does
not work correctly. This expertise is being missed. How many minor but
yet useful modifications are being made to the code which are not being
fed back into the chain.

 
> 
> For "more coder"... well, I rather would like to say
> "Stop adding new functions, clean up what you're standing on, for
>  foundation is dirty and muddy now.
>  If we could clean them up, now we can focus on what's on
>  foundation. Once we're done with foundation, we can even build
>  Tower of Babel, or orbit elevators if we want".
> 

I agree that cleanup is an issue with all code, but even patches can
play a part. If good it could be part of a rewrite. It is often seen
that it is possible to port backwards from say HEAD functionality, why
not the other way round. Look at the code base and see an improvement.

 
> But ... well, at least, Jeremy believe that cleanup is not in high
> priority... all I can say is "add more people", though senior at IBM
> says that this will never works in book "Mythical Man Month".

Maybe delegate, look at the way modular sections could be handled. Build
a tree of developers. If a core set of developers controlled the code
and its integration, then other less committing developers could develop
and contribute for the lead on a part of a project.

Joe.