Closed
Bug 933152
Opened 11 years ago
Closed 5 years ago
Investigate putting update properties to a separate bag
Categories
(Release Engineering Graveyard :: Applications: Balrog (backend), enhancement, P3)
Release Engineering Graveyard
Applications: Balrog (backend)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: nthomas, Unassigned)
Details
(Whiteboard: [lang=python])
The release blobs contain information about the update files, and about the properties of updates, eg detailsURL, actions. In some cases we will need to tweak the update properties for some subset of builds (eg show whatsnew page for pl locale only), which will require duplicating the release blob and an extra rule. This may be a little cleaner if we separate out the properties to a separate json blob. We'd still have two (or more) rules, but they'd differ in the property blob/bag and matching conditions only.
Comment 2•9 years ago
|
||
I got to thinking about this a little bit while thinking about bug 1245941. I think we're likely to end up with a solution there that looks something like:
xml = "<updates>"
xml += "<update ......>"
for blob in blobs:
xml += blob.getXML()
xml += "</update>"
xml += "</updates>"
...which made me realize that most (all?) of the "properties" are part of the <update> line. With that being the case, it may make sense to use a separate object for those (maybe in a separate table, maybe stored as actual db columns rather than json(!)), and just grab the xml from it. Doing so may also mean that we could stop passing "updateQuery" to the release blobs, which has always beens sort of a hack.
This is mostly from the top of my head, so there's probably lots of holes in it.
Reporter | ||
Comment 3•9 years ago
|
||
It would be useful (for me anyway) to enumerate the current and near-future use cases, to make sure we're maintaining flexibility. In particular, to not end up in a situation where multiple blobs contain overlapping info that should appear in <update ....>.
It seems to me we have
* firefox updates - the original use case, where we probably only have a single blob in play. Parameters like detailsURL, actions etc are separable; appVersion and co I'm not sure about as they belongs with the specific release
* gmp updates - multiple blobs, but bare <addons> in xml with no params
* system updates - <from bhearsum import systemaddons.context>, same as gmp ?
Updated•8 years ago
|
Whiteboard: [lang=python]
Comment 4•5 years ago
|
||
(In reply to Nick Thomas [:nthomas, PTO until 13 January] (UTC+13) from comment #3)
It would be useful (for me anyway) to enumerate the current and near-future
use cases, to make sure we're maintaining flexibility. In particular, to not
end up in a situation where multiple blobs contain overlapping info that
should appear in <update ....>.It seems to me we have
- firefox updates - the original use case, where we probably only have a
single blob in play. Parameters like detailsURL, actions etc are separable;
appVersion and co I'm not sure about as they belongs with the specific
release- gmp updates - multiple blobs, but bare <addons> in xml with no params
- system updates - <from bhearsum import systemaddons.context>, same as gmp ?
Do you think this has been sufficiently addressed by the updateLine work in AppRelease blobs, and SuperBlobs? It feels like this hasn't come up in quite awhile.
Flags: needinfo?(nthomas)
Reporter | ||
Comment 5•5 years ago
•
|
||
Yes, I think so. Lets WONTFIX this.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(nthomas)
Resolution: --- → WONTFIX
Updated•5 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•