You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That documentation is written like a live document, more or less playing
the role of a bug tracker with open questions and future work. This
doesn't fit a documentation page, so I've removed most of those entries,
and corrected what I could so that at least the technical information in
that page is correct. This still needs an overhaul to better fit modern
documentation standards.
($2^{128}$ is the maximum number producible by the `md5` function.)
70
+
A computer being in the testing set is determined as follow:
71
+
* Compute a random number based on the following seed: (*package name* + *package version* + *machine id*).
72
+
* Distribute uniformly that random number between 0 and 100.
73
+
* Check whether that number is below `Phased-Update-Percentage` and if yes, include the update.
82
74
83
75
This algorithm requires only the package record and the machine ID to execute
84
76
and is fairly fast so shouldn't slow down the time to calculate the list of
@@ -89,101 +81,10 @@ package and version at a particular threshold. It does vary based on package
89
81
and version though, so that the same set of users aren't always the ones that
90
82
find the regressions.
91
83
92
-
### Unresolved questions
93
-
94
-
* Is the algorithm correct?
95
-
* What do we want to call the new field?
96
-
* What should update manager do if there is another version of the package available and the algorithm answers no for the latest? e.g. security update and newer package in -updates. If it won't install the -updates version, should it install the -security? Probably.
97
-
* If update manager pops up once a week does it make the phased updates rather useless?
98
-
* Assuming that the default is one week, and there is a fairly uniform distribution on which day of the week that is, we will find that the actual percentage of people with the update installed lags the set number fairly significantly. How much depends on how promptly people install the updates. If everyone installs as soon as the popup happens the update will take about a week longer than the ideal curve to fully propagate, but a majority of people will have the update installed by the time it reaches 100% on the server side.
99
-
* We can't know exactly what the current percentage is, only guess based on the phase of the update.
100
-
* When pausing an update the phase should be bought down to 0 to prevent others installing it, and then increased back up, or jumped to the previous value.
101
-
* Given that the phase doesn't control the percentage of machines with the update installed very strongly, and the "open weekly" default for non-security updates provides some sort of phasing, the main thing this scheme provides is the ability to pause an update without deleting it from -updates. Is that worth the effort?
102
-
* Combining phased updates with an option in update-manager to still only show non-security updates (combined with a change to calculate that based on whether the updates will be shown for the particular machine) makes sense to balance our control in pushing out updates, with the users desire to not be bothered by update prompts every day.
103
-
* Given that it is machine based someone with multiple machines will see the updates at different times. Is that too confusing? Should there be a way to turn it off (opt in to testing)?
104
-
105
-
## Archive
106
-
107
-
On the server side the new `Phased-Update-Percentage` field needs to be
108
-
populated when we want to phase an update.
109
-
110
-
Launchpad will insert this into the package record. It therefore needs to know
111
-
what value to insert. Where should it be stored in Launchpad?
112
-
113
-
An API will be added to Launchpad to set the value, and it will be controlled
114
-
by `ubuntu-sru` (ubuntu-archive?).
115
-
116
-
I think that this should be akin to component/section/priority overrides: that is, it should be a column on `BinaryPackagePublishingHistory` and it could most easily be set by adding another optional parameter to `BinaryPackagePublishingHistory.changeOverride`. This will have the effect of creating a new publication for the package, so it will be beneficial not to change the value too often (perhaps once a day or so); but in order to get the LP archive publisher to generate a new Packages stanza a new publication is necessary anyway, so this is true regardless. `BinaryPackagePublishingHistory.changeOverride` is restricted to ubuntu-archive. --`cjwatson`
117
-
118
-
A script will then be run to set these values. When a package is pushed into -updates
119
-
the script will start to increase the percentage over time, using some
120
-
to-be-defined function of the age of the package, and possibly the urgency.
121
-
122
-
There will be an override to that aging that will allow `ubuntu-sru` to pause the
123
-
script for a particular package that can be used when there are suspected
124
-
regressions. Once it has been decided what to do the package can either be
125
-
superseded in updates, in which case the process will start again for the new
126
-
version, or the roll-out will be continued.
127
-
128
-
## Opting out
129
-
130
-
Pre-release versions of Ubuntu should be opted out of phased updates by default.
131
-
132
-
[The "Updates" panel of the Contributor Console](https://wiki.ubuntu.com/ContributorConsole#updates)
133
-
should let testers opt out of phased updates post-release, or opt in to phased
134
-
updates pre-release (to test the phasing mechanism itself).
135
-
136
-
### Unresolved questions
137
-
138
-
* Where should the information be stored in Launchpad?
139
-
* Who should be allowed to change the value?
140
-
* How should the process be paused for a particular package?
141
-
* What should the roll-out curve look like?
142
-
143
-
## Further development
144
-
145
-
* An automatic link could be added from the error tracker to the roll-out script
146
-
so that it pauses propagation if there is a spike in crashes with the new
147
-
version.
148
-
149
-
Replace that heading with headings for each thing you’re changing or specifying.
150
-
151
-
Checklist:
152
-
153
-
1. Have you reviewed the bug reports for the relevant package? (Yes, this may
154
-
take an hour or two. But you might be able to fix multiple bugs with a
155
-
well-designed change.)
156
-
157
-
1. If any user interface is involved, is it fully described? Include any
158
-
wire frames or mock-ups.
159
-
160
-
1. Have you had any new user interface, or new visible text, reviewed by a
161
-
designer? (Or if you are a designer, have you had it peer-reviewed?)
162
-
163
-
1. Is the change accessible? (For example, have you specified accessible labels
164
-
for any graphic-only elements?)
165
-
166
-
1. How will users learn the new way of doing things? Describe any help pages
167
-
required, and any changes to the Ubuntu Web site or installer slideshow.
0 commit comments