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

[Kevin Fenzi]

On Wed, 22 Sep 2010 22:21:33 +0200
Till Maas <opensource at till.name> wrote:

> 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.

I won't re-hash the rest of the thread here, but I think the
observation here is that "Obvious" or "easily fixable" bugs would be
apparent after 12-18months. If there's some obvious bug that affects a
lot of people, it would stand to reason a lot of people would see it
and someone would report it. 

> | 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.

You can change the default... 3 is just what was thought of for
default. You could set it to 1 or 2. 

> 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.

Yes, it should be the same as whats in effect now. 
Fixed. 

> 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

I don't know that there are practical advantages, I think it's a
implementation detail. I'd be fine to making it allow after +1 for non
critical path updates. Could you file a RFE on bodhi for that?
(please cc me?)

> > 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.

But it's not. It depends on the upstream. Many have "stable" branches
where THEY backport fixes and security issues. So, It would still be
"maintainers MAY need to backport fixes if their upstream has no stable
branch to follow, is unwilling to help them backport, etc"

> | 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.

I split that out into a new section with "more likely to grant
exception" and "less likely to grant exception". 

See what you think?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100925/7e0c6c90/attachment.bin