Ok, for this week, I would like to look at ideas for improving security updates.

From the ideas container we have:

1. allow security updates to go direct to stable.

2. ask QA to commit to testing security updates

3. allow timeout for security updates before going to stable.

I'm against item 1. We have run into several security updates in the past that have broken things in a worse way than the fixes they are trying to provide. I might be in favor if we had a way to see "severe" or remote exploitable only or the like.

I'll ask QA about 2. Perhaps we could have a simple set of tests for security updates: check CVEs if any are right. Check basic functioning, etc.

I think 3 may be reasonable, as long as the package is not critical path. Pushing a security update after a week is poor, but better than not pushing it at all.

Additionally, we currently depend on the Red Hat security team folks to file security bugs and maintainers to deal with them. Would it be worth using Fedora Engineering Services or some new group to try and go and fix issues that were not fixed by maintainers?

Isn't #3 with 'a week' the same as the current policy?

The current is the same as for any other update: 1 week if non critpath, and never if critpath. I guess this idea is saying "timeout even for critpath updates".

<nod> "timeout even for critpath" was what was intended when I mentioned the idea here:

http://lists.fedoraproject.org/pipermail/devel/2010-November/145991.html

ideas 1 and 2 were not approved. idea 3 was approved.
Will ask about implementation.

Another update at todays 2011-01-05 meeting:

Non crit path security updates should be allowed to go direct to stable.
Will look at filing bodhi tickets for these items.

This week I would like to pull these two from the ideas container:

• reduce timeout for non critpath from 7 to 3 days.

This would reduce the time for non crit path packages to 3 days before a maintainer could decide to push it to stable (without needing karma).

Personally, I think this is too short, as it could take almost a day for an update requested to go to testing to get into a push, then another 8 or so hours for it to push out, then another N hours to hit mirrors. So that would leave the testing time down to around a day or so, which is pretty short.

• change default autokarma to 2 or 1.

This would change the default in bodhi to 1 or 2 karma needed for non critpath updates to promote to stable. Currently this value is 3, and many maintainers leave it that way.

Pros: would allow lighter testing of packages that don't want it.
Cons: might result in less testing in cases where it would have gotten more if it had been set at 3.

Both these ideas were rejected at this time.

This week I would like to discuss:

1. have being sponsored into packager add you to proventester as well.

This would increase our pool of trusted testers. We could have maintainers read/agree to the proventester guidelines when they are sponsored into packager.

1. allow maintainer's to +1 their own updates

Pros: A maintainer may well be a great person to test their update.
Cons: didn't they test it before they submitted it? Can they use this to 'game the system' and get their update direct to stable?

I support both policies, as mentioned in discussions on -devel lists.

For #2, my idea for this is that the maintainer +1ing their own update would serve as the maintainer officially declaring that they had actually tested the package. We would document this, and specify that they should test the actual build of the package that made it into Koji, not some locally-built analog. If anyone were to 'game the system', this system ought to show it up; if a maintainer +1ed an update which was clearly broken, and can't provide a reasonable explanation of why, their privileges to +1 updates could be revoked. This is the same sanction we have for proventesters, after all.

It may be reasonable to exclude critpath updates from this policy.

My 2 cents:

1. sounds good, +1

2. +1 if a) the karma is at least +2, the submitters feedback must not be the only one and b) it is no applied to critpath.

We decided for #1:

AGREED: Send email to packagers noting proventesters group and how to join and ask interested folks to join. Additionally, add note to maintainers join doc about it. (nirik, 17:54:54)

kylem is going to take those tasks.

We decided for #2:

AGREED: the proposal to allow maintainer's to +1 their own updates is rejected. (nirik, 18:03:14)

ok. This week, I would like to grab from the ideas container:

1) allow anon karma to count. Or allow it to count less (.5).

This would allow people who are being anonymous for whatever reason to have some feedback into the karma total, possibly increasing testing.

2) enforced min number of days in testing for some updates?

Some updates get enough karma to automatically go to stable before ever even landing in testing. Should we enforce some min amount of time in testing before allowing this. Sometimes in a rush to get something tested and in stable, the testing doesn't have the coverage it should.

Also, Kyle: Any news on the tasks in the last comment?

I will ask Luke about various things related to item 1 and we will revisit next week.

Item 2 was rejected at this time.

We would like to defer the "anon users karma counts" issue until bodhi 2.0.

The two ideas from the container this week:

1) reduced karma requirement on other releases when one has gone stable.

Rationale: When a update has been tested and pushed to stable in one Fedora release, those changes may well be exactly the same for another. Allow some reduced karma or timeout for packages where one branch has already gone stable.

2) aggregated karma across the releases for the same package version.

Rationale: Similar versions of a package could duplicate testing, even over other releases. Allow a package to have a karma for all releases and when thats high enough they can all be pushed to stable.

I can't make it today, so my votes are here.

Replying to [comment:16 kevin]:

The two ideas from the container this week:

1) reduced karma requirement on other releases when one has gone stable.

Rationale: When a update has been tested and pushed to stable in one Fedora release, those changes may well be exactly the same for another. Allow some reduced karma or timeout for packages where one branch has already gone stable.

+1

Rationale: even if behaviour in different Fedoras could be different, there is huge number of updates even security, which are in F-n-1 testing repo for a long time.

2) aggregated karma across the releases for the same package version.

Rationale: Similar versions of a package could duplicate testing, even over other releases. Allow a package to have a karma for all releases and when thats high enough they can all be pushed to stable.

+0

Other policies are forcing manual testing in all branches, this doesn't make sense with previous policies.

Both these items were declined at this time.

We have conflicting/outdated info in the wiki now:
https://fedoraproject.org/wiki/Updates_Policy mentions that packages in a release pre-beta only need to spend 3 days in updates-testing, however there is no sign of that at
https://fedoraproject.org/wiki/Package_update_acceptance_criteria

I suggest we delete Package_update_acceptance_criteria from the wiki and do a redirect to Updates_Policy, otherwise we'll have to maintain two pages.

BTW: Ticket to implement this in bodhi: https://fedorahosted.org/bodhi/ticket/587

I've done the redirect.

Up this week:

1. Change FN-1 to just security and major bugfix. Nothing else allowed.

2. require testing only for packages where people have signed up to be testers.

Replying to [comment:21 kevin]:

Up this week:

1. Change FN-1 to just security and major bugfix. Nothing else allowed.

-1, maintainers know their packages best, so they are the best people to decide whether update is needed/wanted or not.
2. require testing only for packages where people have signed up to be testers.
+1, it makes sense to test only packages, which have testers. At the moment we have a lot of updates even security, which are hanging there. This is true even for packages in critical path, which is really sad.

Both these ideas were declined at this time.

For this week:

1. enforced min number of days in testing for some updates

Rationale: Some packages, even critical path should be required to have a higher level of testing. Things such as kernel, dbus, udev, etc. Require them to stay X days in testing.

1. updates that only modify the spec could have a lower requirement. (ie, to fix a packaging issue, no changes in the upstream software).

Rationale: Minor fixes should be easier to test, and shouldn't require as much karma or time in testing.

Replying to [comment:24 kevin]:

For this week:

1. enforced min number of days in testing for some updates

Rationale: Some packages, even critical path should be required to have a higher level of testing. Things such as kernel, dbus, udev, etc. Require them to stay X days in testing.

-1 fixing really annoying or security bugs will be even slower

1. updates that only modify the spec could have a lower requirement. (ie, to fix a packaging issue, no changes in the upstream software).

Rationale: Minor fixes should be easier to test, and shouldn't require as much karma or time in testing.

0 fixing "only spec" could mean many things.

These 2 suggestions were declined at this time.

ok, we don't see any further policy issues we wish to address from the ideas container, so we are going to close this out for now.

If anyone has further improvements for the updates process, file new tickets for them.

Thanks!