-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224

>>> In the worst case, I think it would be a good idea to at least create a
>>> temporary "development branch" where patches can be pushed while the
>>> hard freeze is in place for v14.0.0. After v14.0.0 is released, the
>>> changes made can be merged into the main trunk.
>>>
>
>> I am afraid that with the branches is the same as with the tags - after
>> creating on the server branch synchronizes to users, but after remove on
>> the
>> server users will have to worry about removing branch == all the users
>> themselves. This is not good. Therefore, I am not a fan of temporary
>> branches
>> on the server.
>
> The temporary branch would be just for us developers, not for the main
> users, to be able to comtinue development. And given that we are just 5
> people, I tihnk it would be managable.
> Nevertheless I would still prefer to branch as you described in option 2
> earlier today.
>
>
> Tim, I don't know how the build farm works internally, but perhaps the
> following idea could be useful.
> - create a file with the list of all modules that should be built. For
> each module indicate whether to build against the current source in the
> master branch or against a particular GIT hash in a particular branch.
> - modify the build process to read the file above and checkout the proper
> branch and commit for each module, then build the module
> In this way, when we want to build "standard" nightly build packages, we
> just say to build againast the current source and master branch
> When we want to build a specific image (for example RC1, RC2, v14.0.0 and
> later versions) we use a different index file which contains the correct
> information for such build. This would also to build different "versions"
> any time we want.
>
> Just an idea, as I said I do not know the internal mechanisms of the build
> farm.
> Cheers
>   Michele

As I alluded to before while these things are certainly possible the sheer
size of TDE (well over 150 separate GIT repositories) tends to make
temporary anything impractical--I spend more time setting it up, managing
it, and tearing it down than any time saved in between.

There are limits to what I can do with the build farm due to Debian
requiring monotonically increasing version numbers.  Likely there would
need to be a separate R14 PPA that tracks the "master" of the R14 branch;
this is not feasible at this time due to the sheer size of the R14 archive
and paucity of financial support.  Look at it this way--if we started
doing things like this (multiple 30GB PPAs of the same project at slightly
different code revisions) on the free public Launchpad system we would be
restricted very rapidly if not kicked off entirely.  PPAs on Launchpad are
only 2GB in size for a reason--it gets very expensive very fast to scale
out, and no one is directly paying for the space they use in Launchpad. 
Same applies here. :-)

I am working on the new site right now, so I probably won't be tracking
this discussion closely.  I'll come back to it once RC1 is out, so please
don't finalize anything in my absence.

Thanks!

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iFYEARELAAYFAlQ+jDEACgkQLaxZSoRZrGHsywDcD38UaCcDMgu8WzV3yJAi+fMT
p9T0p6dP17+OXwDfR+NuOyVbdBjqFaZtQpDDwv8sth8UTl67/YOK0w==
=DQcG
-----END PGP SIGNATURE-----