On Thu, May 6, 2010 at 5:34 PM, Aaron Bentley <aa...@canonical.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, ... > I bring this up because Soyuz is currently in the middle of redesigning > the build system, and this is therefore a good opportunity to bring more > similarity to our systems. The Code Import system is also a candidate > for convergence, but the Code team isn't currently redesigning it. > > AIUI, part of the redesign of the build system involves creating a > Buildjob table with many fields that are similar to the Job table. I > propose that the buildjob table should hold only fields that are not > generally relevant to jobs, plus a reference to the Job table. This may > entail adjusting the Job table to better fit the build system's needs.
Hi Aaron, I created the following a few weeks ago for that exact reason: https://bugs.launchpad.net/bugs/570939 "Replace BPJ and SPRBJ with IBuildFarmJob.job" The new IBuildFarmJob model will certainly have many fields similar to the Job table, and as we spoke on the phone the other day, I hope we can replace those fields simply with a reference to the job (as in the above bug). But it isn't as straight-forward yet as simply switching the fields as the other temporary tables mentioned in the above bug reference the job already and are deleted (along with the job) after the queued build job is processed. The current refactoring is (IMO), a big step towards being able to do what you've suggested, but it's aim is to generalise the builds (which will always sit on top of services.Jobs), without touching the current queuing infrastructure which links to the job in strange ways (and deletes them afterwards). That said, another intermediate option that might allow us to simply use something like IBuildFarmJob.services_job (and remove the relevant fields from IBuildFarmJob) without affecting the current queuing infrastructure might be to simply to ensure that when the current queue records are deleted after the build finishes that we just don't delete the job. Julian? William? > > This will give us a common namespace for builds and jobs, so that we can > look them up the same way, and make it easier to display them together. > It will also give us common representations and vocabulary for those > data that are common. > > As time goes on, I expect the systems will come to depend on each other > more. For example, when doing Recipe builds, we could catch problems > earlier by having an initial Job that ran the recipe, before handling > the actual package generation off to a Build. Having overviews that > include both systems will become important. > > Aaron > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvi4WsACgkQ0F+nu1YWqI03RACfYfmbTQujNvqPZvuDVzsY8caQ > GkwAmgOt8wnQ7I+Q21OceXRDjzvDaWR1 > =NSi6 > -----END PGP SIGNATURE----- > > _______________________________________________ > Mailing list: https://launchpad.net/~launchpad-dev > Post to : launchpad-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~launchpad-dev > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
