Am 12.08.2013 21:56, schrieb Leif Hedstrom: > I think the fixed dates is a very minor issue in comparison to the > compatibility ideas. > I personally think it's a step in the wrong direction (the rest of the > OpenSource world > is moving towards agile methodologies)
from the users and admins point of view the agile methodologies are wrong not in all case sbut in many for a webbrowser it's more or less fine because the rapid development of HTML5 and all sorts of client-side tech wired with server-side apps and this is still hard enough in case of server-software agile is not that fine because depending on the whole infrastructure you maintain as admin you need fixed schedules for planning and not collide 5 critical updates at the same time - so i am perfectly happy if i know "twice a year there are releases i need to care about, any update between is a 100% security fix and nothing else" for the relevant pieces ____________________________ that's why i can live with Fedora in production even if it is not that dedicated server-distribution - last week i rolled out F18 and my schedule is to rollout F19 in 2014/01/10 what i noted in my calendar 5 weeks ago 2013/11/01 my workstation and my homeserver are upgraded 2013/11/08 both workstations of our second tech are upgraded the server packages are still prepared in a testing-VM including ATS 3.3.5 if there are no problems i consider ATS 3.4/4.0 even for F18, if not it is rolled out in Jannuary in the meantime the two people responsible for software-development and maintainance are on F19/MariaDB/PHP5.5 for regular work ____________________________ until 2014/01 i can be sure there is not coming a incompatible update except them i want to roll out for internal reasons this is how you survive a leading-edge distribution with relative high upgrade pressures over the year on around 25 machines, if you can expect every random day a bigger update of one of the pieces you are responsiule for you would not get very old :-) if there would be less incompatible config and format changes in the whole opensource world and way too often changes for the sake of the change rapid and agile releases would be easier to handle but that needs time, work and coordination most are not willing to do self expierience, our cms is automatically rolled out and db-schemes applied many times a year to some hundret websites, but in this case the time spent for 100% predictable update sis worth because it would eat much more time to roll them out manually and prepare needed changes by hand - doing so would mean no longer be able to do agile development by only two people and make it also impossible to use a leading-edge distribution with rapid cycles
signature.asc
Description: OpenPGP digital signature
