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

Re: Deep Freeze coming for Fedora 7 (and cvs branching coming too)



On Wed, May 16, 2007 at 02:37:06AM +0530, Rahul Sundaram wrote:
> 
> We have packaging guidelines today to help maintainers know how to 
> package software and having a common understanding on what is required. 

Those guidelines (except for very specific points like license) help
having best practices, but may be ignored if in a specific situation it
doesn't make sense, or it adds too much burden.

For example I don't follow the guideline about asking FESCo for static
libs because in general I know better and I don't want to make those
people lose their time. For the changelog entries it is the same. And
there are certainly other examples.

> We have a large collection of packages now and regressions are quite 
> high. We need good QA guidelines. Simply relying on trust and best 
> judgment on everything to individual maintainers doesn't scale well and 
> is rather naive. 

It is not what I am saying. It would be very nice to have good QA
guidelines. It would be a mistake to force maintainers against their 
best judgement.

> Have you looked at how many major regressions we have 
> for every release?

Not precisely.

> If it is a important security or bug fix you can push it directly but on 
> all other occasions it is very helpful if you could give some chance for 
> people interested in testing to look at the update and check if there 
> are any issues. 

Indeed. That is sensible best practices.

> Exceptions can go through release engineering/QA team. 

I don't think this is useful. The maintainer will always know better
(with the knowledge of the QA guidelines) and in case he doesn't know 
he should be able to ask by himself.

> Updates in the general case would get pushed to updates-testing first 
> and automatically move to general updates repo after a small amount of 
> time. 

But it should be possible for the maintainer to chose to push it to the
repo immediatly based on his best judgement. In the cases when he did a
mistake, somebody with the right powers could still remove the package
but I am sure that this would be very rare. If it is not rare then we
are not selecting the maintainers enough.

> The maintainer can choose to extend the period or pull the 
> package. It shouldn't be a significant additional burden at all.  I will 
> work with Will Woods to write down more specific details.

--
Pat


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