(→updates types: new section) |
|||
| Line 42: | Line 42: | ||
* By default the end-user is notified once in a fortnight for regular updates and daily for security updates. | * By default the end-user is notified once in a fortnight for regular updates and daily for security updates. | ||
** ''This may fall into other policy than Package update policy?'' | ** ''This may fall into other policy than Package update policy?'' | ||
== updates types == | |||
Which package update types should be allowed/disallowed? bugfixes, enhancements, new upstream versions, brand new packages, ... -- [[User:Kparal|Kparal]] 17:09, 5 March 2010 (UTC) | |||
Revision as of 17:09, 5 March 2010
workflow more readable
Numbered list or some flow diagram could make the workflow section more readable. -- Kparal 13:31, 18 February 2010 (UTC)
- Flow diagram done. -- Kparal 16:52, 5 March 2010 (UTC)
mandatory or discretionary?
Let the policy be mandatory or discretionary? Can the package maintainer override the policy on will? -- Kparal 14:20, 18 February 2010 (UTC)
- Kparal: Current discussions suggest this should be a mandatory policy. But of course there must be possibilities to gain an exception (shortened waiting time for highly important updates, etc).
security updates QA check
Even if security updates don't follow Package update policy, we should make sure we check them at least after their release. -- Kparal
critical path packages
Should critical path packages be treated slightly differently from other packages? In what way? -- Kparal
important hot-fix exception
There may be cases when the update is not security fix, but it repairs severe regression/breakage and it is needed to land in updates as soon as possible. Should we offer a possibility to ask for exception and shorten the time required in updates-testing to e.g. 3 days (or even 0 days?). QA ACK should still be needed (to ensure the package is installable etc). The exception would be granted or refused by RelEng team, after considering if the update is really critical. -- Kparal
Example on exceptions process -- jlaska
time spent in updates-testing
Adamw noted that it could be very interesting to query Bodhi for past time experience. How long it usually takes to accumulate most of the positive/negative feedback? Is it in the first few days? Does substantial number of comments appear after the first week? If we can answer those question, we can then set the required time in 'updates-testing' much better. -- Kparal 12:24, 2 March 2010 (UTC)
policy for QA ACK decisions
Similarly to RelEng placeholder in the Workflow section, there might exist a document documenting rules for QA to accept/reject an update. This policy would then be implemented by Package update acceptance test plan. -- Kparal 11:48, 5 March 2010 (UTC)
update release schedule
This topic is related, but should probably be part of a separate policy and not directly included in this one. It has been moved from the draft into this discussion page.
- The 'updates-testing' repository is updated continuously, it is refreshed for every package update.
- The 'updates' repository is updated regularly once a week for regular updates and continuously for security updates.
- Will that help us improve quality by having updates as a weekly "pack" (with possible interactions and collisions, etc) instead of continuous stream of single updates? If QA can't leverage this, then it can be a daily push or a continuous push.
- By default the end-user is notified once in a fortnight for regular updates and daily for security updates.
- This may fall into other policy than Package update policy?
updates types
Which package update types should be allowed/disallowed? bugfixes, enhancements, new upstream versions, brand new packages, ... -- Kparal 17:09, 5 March 2010 (UTC)