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
_______________________________________________
maemo-developers mailing list
[email protected]
https://lists.maemo.org/mailman/listinfo/maemo-developers
