Suggested "combined tree" conditions for success

[Stefan (metze) Metzmacher]

Kai Blin schrieb:
> 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.

you can already start, you just need to rebase
(or git format-patch && git am) when the final branch is ready...

metze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20080908/7d0d3caa/signature.bin