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)

Product:
Release Engineering Graveyard
Component:
Applications: Balrog (backend)
Type:
enhancement

Tracking

(Not tracked)

Status:
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.
mass priority change after component move
Priority: -- → P3
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.
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 ?
Whiteboard: [lang=python]

(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)

Yes, I think so. Lets WONTFIX this.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(nthomas)
Resolution: --- → WONTFIX
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.