[maemo-developers] QA process = bug fixing disincentive?

[From: Jeremiah Foster]

On Nov 2, 2009, at 15:42, Riku Voipio wrote:

> ext Jeremiah Foster wrote:
>> On Nov 1, 2009, at 11:02, Henrik Hedberg wrote:
>>
>>
>>> Martin Grimme wrote:
>>>
>>>
>>>> resetting Karma on a new version leads to one very bad issue, IMHO:
>>>>
>>>> Developers of packages with some Karma will hold back bugfix- 
>>>> updates
>>>> until the unfixed version has reached extras.
>>>>
>>
>> This is a real problem that will have to be addressed.
>
> What need is a way to split bugfix changes and new major versions.

I think this is an excellent way to distinguish between between those  
apps that need karma reset and those that don't. There are a variety  
of mechanisms to do this, all from setting a simple flag somewhere in  
the changelog as suggested or even allowing part of the version string  
to change and not truncate karma.

To beat the horse dead;

	foo_1.0-1maemo0  -> bug fix -> foo_1.0-1maemo1 = All karma retained
  	foo_1.0-1maemo0  -> feature -> foo_1.1-1maemo0 = Karma set to zero	

>
> 1) We must encourage developers to provide bug fixes often and be able
> to deliver them quickly to endusers

+1

> 2) New major versions still need QA testing - against regressions.  
> Even
> more than bugs endusers hate when things that used to work stopped  
> working.
>
> Now, I think it is impossible to automatically detect if a upload is
> bugfix or "major" upgrade. Thus, we have to trust the developer to set
> the major-/bugfix upgrade flag correctly somewhere ( debian/ 
> changelog, a
> menu item in the package promotion ui or whatever ).

I think we should be trusting the developers.

> The question then comes, can we trust the developers to do the right
> thing and not abuse the "minor upgrade" to shove in any package with
> shorter quarentee and less votes?

I don't see any other solution than trusting the developer and having  
a QA process. If the QA finds a bug, the dev has to fix it. Once it  
passes QA, we have to trust that the developer is working with the  
system, not against it.

Jeremiah