On 3.11.2015 02:13, Kevin Kofler wrote: > 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. +1 again. If you are not comfortable with updating e.g. every day, just schedule the cron job to do it weekly/monthly instead of daily. It is end-user's choice, there is not need to delay updates on distribution's side. Petr Spacek >> 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
