Draft of branch maintainence and release plans....

[David Lee]

On Tue, 2 Jul 2002, Gerald (Jerry) Carter wrote:

> Here are the plans for getting 3.0 ready for release and the 
> maintainence plans for SAMBA_2_2.  Comments welcome.

Thanks for the news: it is useful to know this sort of thing.

> Roadmap to 3.0
> --------------
> 
> The following features are planned for inclusion in 3.0.
> This list was compiled based on previous promises during 2.2
> development and believed future directions of Samba
> [...]

Could I add a few things for consideration? 

Note the word "foundation" in what follows. Most items have such a
structural foundation aspect as a pre-requisite to building the actual
functionality.  To a first approximation, I'm assuming that the foundation
work can only be done by the Samba Team.  (Is this a fair assumption in
the items listed?)  Once that is done, then the rest of us can then
contribute the further building work.


panic action
------------

Some months ago we had a discussion about "panic action", and agreed on
the desirability of improving the default behaviour, so that, if
reasonably possible, it would automatically attempt to invoke a debugging
program to dump a backtrace into that smbd's own log file.

And in the last few days, this list has seen another example of a
sys.admin. who (like me and many others of us) would have been able to
benefit if a default debug/backtrace had been in place. 

I think Andrew Bartlett had identified an issue to do with diverting the
output into the log file, which would need attention.  It would be useful
if that foundation aspect could be put in place by the Team (Andrew B?).
Then others of us could look at detecting (autoconf?) and scripting for
various debugging tools.


event mechanism
---------------

Around 17th June we had a discussion about generalising the central loop
of "smbd" to that other devices (e.g. "/dev/smb/<n>") could be read etc. 
One example would be so that write(1) and wall(1) could be used and the
data translated into WinPopup.  This example has been proven in
demonstration, but Jeremy, understandably, wants this foundational event
mechanism to be tightened before we build anything on it.


session exec
------------

In various contexts, including a "make home directory" discussion in
recent days, and earlier discussions about write(1) (see above), Andrew B. 
has mentioned the possibility of a "session exec" as a foundation for such
work.  Such a foundation would, I understand, also allow the "finger" 
problem to be fixed (e.g. the exec script invoking some external agency to
be built to create/delete/mange/whatever "/dev/smb/<n>").




OK?

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :