| 2010-03-10 15:10:06 |
Michael Nelson |
bug |
|
|
added bug |
| 2010-03-10 15:14:05 |
Michael Nelson |
soyuz: assignee |
|
Michael Nelson (michael.nelson) |
|
| 2010-03-10 15:27:55 |
Michael Nelson |
soyuz: status |
Triaged |
In Progress |
|
| 2010-03-11 10:30:24 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we need to make sure we can present them in a similar way. |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way.
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID
for example. With the time we've got for 10.03, I think this is the only viable option for the first-cut.
But longer term, we've chatted about this within Soyuz and would like to instead go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) |
|
| 2010-03-11 10:34:03 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way.
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID
for example. With the time we've got for 10.03, I think this is the only viable option for the first-cut.
But longer term, we've chatted about this within Soyuz and would like to instead go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way.
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID
for example. With the time we've got for 10.03, I think this is the only viable option for the first-cut.
But longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT? |
|
| 2010-03-11 10:34:08 |
Michael Nelson |
soyuz: status |
In Progress |
Triaged |
|
| 2010-03-11 10:34:14 |
Michael Nelson |
soyuz: assignee |
Michael Nelson (michael.nelson) |
|
|
| 2010-03-11 16:40:29 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way.
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID
for example. With the time we've got for 10.03, I think this is the only viable option for the first-cut.
But longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT? |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way.
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID
for example. With the time we've got for 10.03, I think this is the only viable option for the first-cut.
But longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
See http://launchpadlibrarian.net/40805850/build-related.png
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT?
|
|
| 2010-03-15 17:48:10 |
Julian Edwards |
soyuz: milestone |
10.03 |
10.04 |
|
| 2010-03-22 09:58:27 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way.
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID
for example. With the time we've got for 10.03, I think this is the only viable option for the first-cut.
But longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
See http://launchpadlibrarian.net/40805850/build-related.png
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT?
|
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way. (Note: I'm taking the discussion of whether we actually want to merge Binary and Recipe builds in the one list to the dev list).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID, or something in the code domain:
/~person/path_to_branch/+builds
for example.
Longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
See http://launchpadlibrarian.net/40805850/build-related.png
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT?
|
|
| 2010-03-22 17:25:13 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way. (Note: I'm taking the discussion of whether we actually want to merge Binary and Recipe builds in the one list to the dev list).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID, or something in the code domain:
/~person/path_to_branch/+builds
for example.
Longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
See http://launchpadlibrarian.net/40805850/build-related.png
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT?
|
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way. (Note: I'm taking the discussion of whether we actually want to merge Binary and Recipe builds in the one list to the dev list, and/or have a SPRBuild's url in the ppa context).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID, or something in the code domain:
/~person/path_to_branch/+builds
for example.
Longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
See http://launchpadlibrarian.net/40805850/build-related.png
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT?
|
|
| 2010-03-26 13:31:14 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to present them in a similar way. (Note: I'm taking the discussion of whether we actually want to merge Binary and Recipe builds in the one list to the dev list, and/or have a SPRBuild's url in the ppa context).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So currently, the traversal for build in a PPA context is:
/~person/+archive/ppaname/+build/build_ID
with the searchable builds at :
/~person/+archive/ppaname/+builds
So we cannot currently present the SPRecipeBuilds together, but would need:
/~person/+archive/ppaname/+sourcebuild/build_ID, or something in the code domain:
/~person/path_to_branch/+builds
for example.
Longer term, we've chatted about this within our Soyuz team call and would like to (eventually) go with the "One data entity per class", with a separate table for IBuildBase, so that a soyuz (Binary)Build would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
See http://launchpadlibrarian.net/40805850/build-related.png
It would be great to get agreement (or disagreement!) from other interested people: wgrant, jtv, BjornT?
|
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to have a general way to present a list of different types of builds in the context of a PPA (or a Builder).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So the traversal for builds in a PPA context is:
/~person/+archive/ppaname/+builds
but this presents binary builds only (as historically they were the only type of build).
To enable other types of builds (such as SPRecipeBuilds) to be included in such plurals, we've chatted about this within our Soyuz team as well as with other LP devs:
https://lists.launchpad.net/launchpad-dev/msg03032.html
and would like to go with a "One data entity per class", with a separate BuildFarmJob table, so that a soyuz PackageBuild would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
The current build-related tables with their relation ships can be seen here:
See http://launchpadlibrarian.net/40805850/build-related.png
After discussion, William proposed the following as the new organisation of builds:
http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model.png
|
|
| 2010-04-12 13:40:50 |
Michael Nelson |
branch linked |
|
lp:~michael.nelson/launchpad/db-build-generalisation-db-changes |
|
| 2010-04-12 13:41:19 |
Michael Nelson |
branch linked |
|
lp:~michael.nelson/launchpad/506292-binarypackagebuild-rename |
|
| 2010-04-12 14:51:54 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to have a general way to present a list of different types of builds in the context of a PPA (or a Builder).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So the traversal for builds in a PPA context is:
/~person/+archive/ppaname/+builds
but this presents binary builds only (as historically they were the only type of build).
To enable other types of builds (such as SPRecipeBuilds) to be included in such plurals, we've chatted about this within our Soyuz team as well as with other LP devs:
https://lists.launchpad.net/launchpad-dev/msg03032.html
and would like to go with a "One data entity per class", with a separate BuildFarmJob table, so that a soyuz PackageBuild would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
The current build-related tables with their relation ships can be seen here:
See http://launchpadlibrarian.net/40805850/build-related.png
After discussion, William proposed the following as the new organisation of builds:
http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model.png
|
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to have a general way to present a list of different types of builds in the context of a PPA (or a Builder).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So the traversal for builds in a PPA context is:
/~person/+archive/ppaname/+builds
but this presents binary builds only (as historically they were the only type of build).
To enable other types of builds (such as SPRecipeBuilds) to be included in such plurals, we've chatted about this within our Soyuz team as well as with other LP devs:
https://lists.launchpad.net/launchpad-dev/msg03032.html
and would like to go with a "One data entity per class", with a separate BuildFarmJob table, so that a soyuz PackageBuild would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
The current build-related tables with their relation ships can be seen here:
See http://launchpadlibrarian.net/40805850/build-related.png
After discussion, William proposed the following as the new organisation of builds:
http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png
|
|
| 2010-04-15 20:28:06 |
Ursula Junque |
soyuz: assignee |
|
Michael Nelson (michael.nelson) |
|
| 2010-04-15 20:28:12 |
Ursula Junque |
soyuz: status |
Triaged |
Fix Committed |
|
| 2010-04-15 20:28:17 |
Ursula Junque |
tags |
wellington |
qa-needstesting wellington |
|
| 2010-04-16 08:47:54 |
Michael Nelson |
soyuz: status |
Fix Committed |
Triaged |
|
| 2010-04-16 08:48:59 |
Michael Nelson |
tags |
qa-needstesting wellington |
wellington |
|
| 2010-04-16 08:53:12 |
Michael Nelson |
branch unlinked |
lp:~michael.nelson/launchpad/506292-binarypackagebuild-rename |
|
|
| 2010-04-27 21:52:12 |
Michael Nelson |
soyuz: milestone |
10.04 |
10.05 |
|
| 2010-05-19 08:14:24 |
Michael Nelson |
branch unlinked |
lp:~michael.nelson/launchpad/db-build-generalisation-db-changes |
|
|
| 2010-05-31 06:36:36 |
Michael Nelson |
soyuz: milestone |
10.05 |
10.06 |
|
| 2010-06-15 07:42:42 |
Michael Nelson |
branch linked |
|
lp:~michael.nelson/launchpad/536700-present-packagebuilds-in-ppa-context |
|
| 2010-06-15 07:42:59 |
Michael Nelson |
branch linked |
|
lp:~michael.nelson/launchpad/536700-present-packagebuilds-in-ppa-context-2 |
|
| 2010-06-22 08:15:08 |
Michael Nelson |
soyuz: status |
Triaged |
Fix Committed |
|
| 2010-06-22 08:15:30 |
Michael Nelson |
tags |
wellington |
qa-ok wellington |
|
| 2010-06-22 08:16:38 |
Michael Nelson |
description |
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to have a general way to present a list of different types of builds in the context of a PPA (or a Builder).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So the traversal for builds in a PPA context is:
/~person/+archive/ppaname/+builds
but this presents binary builds only (as historically they were the only type of build).
To enable other types of builds (such as SPRecipeBuilds) to be included in such plurals, we've chatted about this within our Soyuz team as well as with other LP devs:
https://lists.launchpad.net/launchpad-dev/msg03032.html
and would like to go with a "One data entity per class", with a separate BuildFarmJob table, so that a soyuz PackageBuild would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
The current build-related tables with their relation ships can be seen here:
See http://launchpadlibrarian.net/40805850/build-related.png
After discussion, William proposed the following as the new organisation of builds:
http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png
|
Note: the soyuz aspect of this bug is complete, but other apps will need to update to the new db-schema before their builds will appear.
Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to have a general way to present a list of different types of builds in the context of a PPA (or a Builder).
Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")
So the traversal for builds in a PPA context is:
/~person/+archive/ppaname/+builds
but this presents binary builds only (as historically they were the only type of build).
To enable other types of builds (such as SPRecipeBuilds) to be included in such plurals, we've chatted about this within our Soyuz team as well as with other LP devs:
https://lists.launchpad.net/launchpad-dev/msg03032.html
and would like to go with a "One data entity per class", with a separate BuildFarmJob table, so that a soyuz PackageBuild would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.
This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).
The current build-related tables with their relation ships can be seen here:
See http://launchpadlibrarian.net/40805850/build-related.png
After discussion, William proposed the following as the new organisation of builds:
http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png
|
|
| 2010-07-07 07:02:46 |
Michael Nelson |
soyuz: status |
Fix Committed |
Fix Released |
|
