The buildd code should be removed from the Launchpad tree

[Julian Edwards]

The buildd code currently lives in lib/canonical/buildd in the Launchpad tree.

It should be a separate branch in the launchpad-buildd project instead and licensed under GPLv2.

[Jelmer Vernooij (jelmer)]

What's blocking this other than the fact that ./debian/rules copies in lib/canonical/launchpad/daemons/tachandler.py ?

Would it be bad to ship launchpad-buildd with a copy of tachandler.py ?

[Julian Edwards (julian-edwards)]

It ought to be a separate package, ideally. It's used in quite a few places.

[William Grant (wgrant)]

Jelmer, that was the main issue before Translations came along with their new-fangled test thingies. Now there are a few lp.* imports:

tests/test_generate_translation_templates.py:from lp.testing.fakemethod import FakeMethod
tests/test_generate_translation_templates.py:from lp.code.model.directbranchcommit import DirectBranchCommit
tests/test_generate_translation_templates.py:from lp.testing import TestCaseWithFactory
tests/test_generate_translation_templates.py: :return: a fresh lp.code.model.Branch backed by a real bzr branch.
tests/harness.py:from lp.services.osutils import remove_tree
tests/test_translationtemplatesbuildmanager.py:from lp.testing import TestCase
tests/test_translationtemplatesbuildmanager.py:from lp.testing.fakemethod import FakeMethod

[LaMont Jones (lamont)]

Actually, tachandler.py broke badly (at least from lp-buildd's perspective) and got a cleaned-up shiny copy of it's own, sitting next to tachandler.py in the same wrong-for-packaging directory, just so that lp-buildd has a file to copy in and use for itself.

The clean solution is to move the file into lp-buildd, and get out of the tree entirely.

The code is not rolled out as part of LP rollouts, is really a separate tree of code that happens to be glommed onto the side of the existing (unrelated) code base we call "launchpad"

[Robert Collins (lifeless)]

Sorry Lamont, I don't quite follow; can you expand on what you mean?

[Francis J. Lacoste (flacoste)]

Escalated via the ISO/LP call.

[Robert Collins (lifeless)]

The things copied in now are 'readyservice.py' which we use to indicate when daemons are ready. Its extremely shallow and (possibly) only needed during testing. If its only needed during testing we could inject that into an external package during lp test runs and have not present in the buildd code itself.

[Robert Collins (lifeless)]

Constraints:
 - we need to be able to run buildd's during lp tests
 - we need to have the readyservice stuff available in lp for multiple lp daemons (of which the in-test buildd is just one)
 - buildd changes need to be able to be done independently of the lp change-test-deploy cycle
 - lp needs to be testing against the latest deployed buildd (not latest developed buildd - because the deploys are done async) Or something - this may need a little nuance

[LaMont Jones (lamont)]

Those constraints all make sense. An additional reality today is that the lp change-test-deploy cycle does not actually deploy buildd code to any of the builders. Both deployments are done completely independently from the other.