15 Oct
2014
15 Oct
'14
3:01 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
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
> 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 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ+jDEACgkQLaxZSoRZrGHsywDcD38UaCcDMgu8WzV3yJAi+fMT
p9T0p6dP17+OXwDfR+NuOyVbdBjqFaZtQpDDwv8sth8UTl67/YOK0w==
=DQcG
-----END PGP SIGNATURE-----