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
Attachment:
pgpxwDuiBnRci.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
