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

[From: Jeremiah Foster]

On Nov 3, 2009, at 12:16, Andrew Flegg wrote:

> On Tue, Nov 3, 2009 at 08:43, Marius Vollmer  
> <marius.vollmer at nokia.com> wrote:
>> ext Jeremiah Foster <jeremiah at jeremiahfoster.com> writes:
>>
>>> 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
>>
>> Nitpick: 1.0 -> 1.1 might well be a bug fix release as well.  Also, I
>> think that many packages in Extras are native and don't use a "Maemo
>> revision" in their version.  Or did we redefine the meaning of the  
>> part
>> of a version after the dash?
>
> Agreed. -maemo0 to -maemo1 is supposed to be a Maemo-specific change
> or a packaging change (AIUI). Native packages (such as Hermes,
> Attitude etc.) don't have that suffix and use a traditional x.y.z
> numbering scheme.
>
> Minor bug fixes increment 'z', new features increment 'y' and major
> milestones increment 'x'.
>
> So, according to this the packages interface would need a heuristic to
> detect a change in just the least significant part of the number.
>
> Something like, in Perl:
>
>  my ($base, $lsb) = $oldVersion =~ /^(.*?)(\d+)$/;
>  my $minor = $newVersion eq $base.($lsb + 1);
>  &resetPackageKarma() unless $minor;
>
> This'd handle:
>   2.0          ->  2.1
>   2.0.0        ->  2.0.1 (but not 2.0.0 -> 2.1.0)
>   2.0.0-maemo1 ->  2.0.0-maemo2 (but not -> 2.0.1-maemo1)
>
> Thoughts?

This is what I had in mind but skipped on elaborating in an effort to  
keep things as clear as possible. I think this solution is excellent  
and perhaps we can implement it if there is consensus?

Jeremiah