[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Proposed and major updates policy

Warren Togami wrote:

Gilboa Davara wrote:

I second that.
The lack of FC package update policy is a real pain in the back side.
The KDE 3.5.x release backlash was just an example of why such a policy
must be set.

IMHO, the vast majority of updates have been no problem. KDE however has been a bit problematic in particular. Upgrading such a large group of packages is reckless especially when done without testing. Unfortunately, I am afraid some developers do not test new updates before pushing.

If a clear policy is in place there would be more accountability. Without this, the decision to push updates directly is entirely in the hands of the relevant package maintainers who might just skip the testing repository even when it is generally required.

I believe we don't need any strict policy like "a week in testing" repository because the majority of updates are really no problem. We should however say "test it and be sure it works, and if you are less sure put it in testing". Also bigger updates like an entire new KDE release definitely must go into testing.

Requiring ALL updates to go into the testing repository will unnecessary slow down progress.

I didnt claim that all updates need to be pushed to the testing repository however if there are exceptions then the rationale behind those exceptions should be better communicated and in case of general guidelines, better documented. Security fixes for might directly go into updates repository while major revisions of packages should go through updates-testing repository is a simple enough policy to enforce for example. I dont for a moment believe that all potential issues or regressions in updates would be caught in the updates-testing repository however there is a potential to have less issues when the testing repository is used by testers who might provide better feedback. The problem is not necessarily what we do but a communication gap in why we do it , the way we do it.

Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]