PATCHES: Release Suggestion

[okuyamak at dd.iij4u.or.jp]

Dear Joe,

I think the following point is the key. So I only reply to here.

>>>>> "JD" == Joe Doran <joed at pc-ltd.co.uk> writes:
>> 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".
JD> I agree that cleanup is an issue with all code, but even patches can
JD> play a part. If good it could be part of a rewrite. It is often seen
JD> that it is possible to port backwards from say HEAD functionality, why
JD> not the other way round. Look at the code base and see an improvement.

Why not the other way around?  Because what you're saying requires
locking.

HEAD->release direction requires locking. release version have to be
locked for a moment. This is because you can't create patch against
"currently changing" code. But since 'release' is something that
already being freezed, this is quite easy.


Same with other way around. release->HEAD requires HEAD development
to be stopped for a moment.

And we all know that once HEAD is being locked, we have many things
we'd like to add/modify/delete into HEAD, which entire code is quite
same for released version too.  As result, what we'll have is not
'snap locking for a moment', but long time of stop adding new
functionality, and goes for quality checking.

So, once release->HEAD patching is being started, HEAD will not
start moving again, until cleanup is over, as result.


I think what you're feeling about samba code and what I'm feeling
about samba code is quite alike. Only, you believe that locking will
not cause more than small time of locking, while I feel this locking
will require nearly half year. And every time new function is added,
the time will get longer ( for things will get more and more tangled ).

best regards,
---- 
Kenichi Okuyama at Tokyo Research Lab, IBM-Japan, Co.