Suggested "combined tree" conditions for success

[Kai Blin]

On Monday 08 September 2008 09:25:20 Andrew Bartlett wrote:

> > If people are fine with this tree, I'd propose we switch development to
> > this tree.
[...]
> 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's certainly doable. Karolin has the final word on this, of course, but I 
guess that 3.4 would be branched off the combined tree. There's probably no 
technical reason not to release 3.3.0 from the combined tree, apart from the 
fact that the v3-3-test branch already was branched off.

> 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.

Jelmer was working on that one, but probably put it on hold until the merged 
tree was finished. I agree this is the very next step.

> 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).

If I understood Jelmer correctly, his current patchset proposed in his "Allow 
building Samba 4 inside the Samba 3 build process" already does this.

> 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.

This might be problematic on build farm hosts that don't have python but run 
with --enable-developer. Personally I don't see why I'd ever go back to only 
building S3 or S4 if I can build both by a single "make"

> 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.

I don't know what the required build system magic would be here, but I had the 
impression the plan was to:

1) Get the trees merged, allowing to build an unchanged S3 from source3/ and 
an unchanged S4 from source4/

2) Get a common build system set up, where "make samba3" builds S3, "make 
samba4" builds S4 and use that as opposed to building from the respective 
source directory.

3) Start consolidating the technology currently duplicated in S3 and S4

For the folks playing around with Franky, step 2) would likely include a "make 
franky" that builds Franky. But I don't see any conflict of interest there. 
After all integrating the technology is a core part of the Franky design as 
well.

> 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).

I think as soon as "make" in the merged directory builds S3 and S4, "make 
test" needs to run the S3 and S4 tests. Every other behavior sure would 
confuse the heck out of people.

> 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.

Looking at the work gd put into this for netapi and others, I think this step 
is a given, just to make his life easier. I'll gladly subscribe to this.

> 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).

Full ack.

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

I don't mind, but I figure this might be a problem for some of the hosts we 
have in the build farm.

> 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).

Most of this seems just explicitly stating sane development practices, so I 
don't expect this will bog down people alot (apart maybe from the time a 
combined "make && make test" run will take).

Personally, I'm just waiting for the combined build system to hit so I can 
start converting over the utilities I'm working on.

Cheers,
Kai

-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.
-------------- 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/27c22119/attachment.bin