trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reindl Harald <h.rei...@thelounge.net>
Subject Re: [PROPOSAL] New release process
Date Mon, 12 Aug 2013 20:18:59 GMT


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


Mime
View raw message