Michael Catanzaro wrote:
> Yeah, that's the clear disadvantage. The service pack approach
> sidesteps that problem: everything still goes out, just not so soon, so
> everything spends plenty of time in testing. All the bugs still get
> fixed, just not as fast.
And that's "better" HOW?
> (This also solves the problem of maintainers releasing individually
> -good updates too frequently.)
What problem? "too frequently" according to whom? I don't see any problem
here, and I think updates (especially bugfixes) cannot be frequent enough.
> The counterargument is that we keep seeing major version updates that
> violate our existing updates policy.
This means the policy is broken, not the updates. I am glad that we are not
following that policy to the letter, that's the only reason the system works
at all! We need to encourage pushing new versions unless there is a good
reason not to, including, but not limited to:
* incompatibility with existing data (including documents, config files,
savegames, etc.),
* feature regressions (including deliberately removed features and features
missing from a rewrite),
* major UI changes (but a menu item moving to some other place is harmless),
* new bugs (known in advance or found during testing) unless outweighed by
the bugs that are fixed,
etc. If none of the above hold, then why would we not let the users benefit
from the new features in the new version of the package? Upstream clearly
considers it stable or they would not have released it as such.
> Who if not a neutral party charged with upholding that policy should have
> the final say? Some maintainers who clearly haven't read it?
I have read it. I just don't interpret it as being in contradiction with my
updates. See e.g. Routino, which only went from 2.7.3 to 3.0 because it
added a shared library (which in turn allows building new versions of
applications such as qmapshack). The changes to the routing software itself
are minor and almost entirely bugfixes. It is also compatible with databases
from 2.7.3. (I NEVER push an update of Routino that is NOT database-
compatible!) I don't see any reason why the update would be a problem.
> If we have another party approving updates, then it's the maintainer's
> job to write an argument in favor of releasing the update: a quick
> summary of what the fix is and the regression potential. If the update
> gets rejected, the maintainer might really be wrong! and if not would
> have to try again to explain better. I think this would be good
> regardless of whether or not we do updates packs.
I think this would just be added bureaucracy and a royal PITA. Bodhi is
already painful enough as it stands!
If you keep making it harder for packagers to do their job, you will find
yourself losing packagers rapidly.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
