Suggested "combined tree" conditions for success

[Andrew Bartlett]

On Sun, 2008-09-07 at 22:46 +0200, Kai Blin wrote:
> On Saturday 06 September 2008 21:32:24 Volker Lendecke wrote:
> > On Fri, Sep 05, 2008 at 07:07:22PM +0200, Stefan (metze) Metzmacher wrote:
> > > > We need to discuss how to handle the remaining
> > > > duplicates from the old Samba3 and Samba4 trees. I'm
> > > > looking forward to suggestions on how to improve the
> > > > migration guide as well.
> > >
> > > I like the concept, but let us (me) redo the
> > > git-filter-branch thing so that each new commit has a
> > > reference to the old sha1 in it.
> >
> > Find the newly converted trees on
> >
> > http://git.samba.org/?p=vl/samba.git/.git;a=summary
> 
> And the newly generated merge tree at:
> http://gitweb.samba.org/?p=kai/samba/franky.git;a=summary
> 
> If people are fine with this tree, I'd propose we switch development to this 
> tree.

I'm downloading the tree now, but I think there are a few things we
should get straight, to ensure we gain a benefit from the upheaval.
Without changing our development practices, I don't see how this move
(which I fully support) will change anything. 

Therefore, I suggest that this cannot be a success without the following
conditions being met.  (and as we wish this project to be a success,
that we agree to abide by these).


That we have a defined goal release (in Samba3 release terms, as it has
a predictable timeline) that we expect to use the combined tree.

That a combined build system exist, such that in a reasonable manner, a
developer can build both Samba3 and Samba4, and run 'make test' that
uses binaries from both.  

That both Samba3 and Samba4 be built as part of this build system by
default.  If Samba4 critically depends on a system component not
available, that only then is Samba4 (or some Samba4 components) not
built.  (Samba3 is expected to build at all times, simply because it has
historically required less from the system).

That there be an option such as --enable-developer which requires that
both trees be built.  Developers will be expected to use this option at
all times.

That the goal is not to create a single release (at this stage), but to
integrate technology.  As such, builds of Samba3 and Samba4, producing
similar user-visible binaries to current practice etc be available.  

That 'make test' must pass against the combined work before commits, and
if (for whatever reason, developers being human) a change causes
breakage, even if the change 'fixes' a test, that 'make test' must be
made to pass again.  (eg, a more strict torture test must come with a
fix for both file server implementations, or a very good reason
documented for a new test exemption). 

That we work towards a common set of IDL again, and Samba3 use PIDL at
runtime for developers (at least) to ensure that IDL changes propagate
correctly.

That provided key functionality is not lost, changes are well tested,
and sensible user upgrade paths are available, that replacing code in
either branch with new or ported 'in common' code is strongly encouraged
(and the explicit purpose of the exercise). 

That Python and Perl be an acceptable languages for implementation of
Samba infrastructure (build/test system etc) and installed scripts. 


How does that sound?
(I don't want to bog us down with rules, but I'm also very wary of the
possible different expectations in this area). 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080908/c4ecd335/attachment.bin