REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Till Maas]

On Tue, Sep 21, 2010 at 03:47:04PM -0600, Kevin Fenzi wrote:

> I'd like to ask for feedback and helping cleaning up an updates policy
> draft page: 
> 
> https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
> 
> How can we clarify the language or the layout of the page to be more
> clear? Are there places that it could be more like the existing package
> update howto page? Could we be more detailed about what bodhi enforces
> and whats just good practice? 

This here sounds strange:
| The update rate for any given release should drop off over time,
| approaching zero near release end-of-life; since updates are primarily
| bugfixes, fewer and fewer should be needed over time.

This essentially says that after 12 or 18 months all software in Fedora
is bug free and does not need any updates. This is a very strange
assumption. E.g. why do we stop supporting the software after it became
totally stable? IMHO this claim cannot reasonably be made.

| All  critical path updates MUST get one +1 karma from a proventester
| and +1 karma from another user before going stable.
| All non critical path updates MUST either reach the prescribed karma
| level for that update

Why is the barrier for non critical path updates higher than for
critical path updates? E.g. with the default karma threshold of 3, two
+1 karma points would not be enough.

Also is this really what you propose for critical path updates? E.g. for
the Package update acceptance criteria this was proposed, but
implemented was a net karma sum of 2 with at least one +1 from a
proventester.

Also can someone please explain the practical advantages of requiring
the autokarma threshold to approve the ability to push a non critical
path update to stable instead of just requiring a net karma sum of 1?
I asked for this several times on the Update Policy ticket but did not
get any answer:
https://fedorahosted.org/fesco/ticket/351#comment:55

> Are there other exceptions cases that could be covered that you can
> think of?

| Exceptions
[...]
| If upstream does not provide security fixes for a particular release,
| and if backporting the fix would be impractical,

If not back porting is an exception, then something in the policy should
say that back porting is now expected from packagers.

| Things to consider:
| Is this a "leaf" package? Would ABI/API change? Does the User Interface
| change?

IMHO it would be better to really say what is the good answer to allow
changes, e.g. for the first question it is yes, for the others it is no.
And more information for unexperienced packagers to know what is a
"leaf" package and how to determine ABI/API changes would be better.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100922/524e0d32/attachment.bin