Image, 5. 12.

[Sebastian Kügler]

On Tuesday, December 06, 2011 11:40:02 Aaron J. Seigo wrote:
> > I read in this list about
> > the plan to have an "always stable master", testing bigger changes in
> > branches and only merging back to master when they work. Of course the
> 
> we have to test those branches. they don't become stable on their own. so 
> while we may end up with an "always stable master", our team will likely
> be  using the integration branch which will not always be stable. so
> people outside the team will be more insulated from these effects, but we
> won't. it's the price of being on the devel team :)

I'm actually putting patches that aren't yet in master into packages in 
KDE:Active:Devel, in order to test them. Right now, there's the editbubble 
stuff in the Balsam packages, for example. This is necessary to actually get 
code tested. It's inevitable that it also leads to breakage once every so 
often, but if it didn't, we didn't need to test in the first place.

I've explained this to Kim a while ago when she asked why my computers are 
always "broken". It's because I develop software, if the software was complete 
/ bugfree / finished, I wouldn't work on it. In our special case, there's a 
big overlap between what we use daily and what we work on, that's positive 
because we eat our own dogfood, but can be annoying if you just want to be a 
user for a while. I have separate tablets for that, one is running PA1, 
another one is running development snapshots. That makes it easy to compare 
and gauge progress, but also gives me a usable device when I need. (There's of 
course always this nagging feeling that many bugs are already fixed when you 
run stable, but that's just the price to pay for stability -- it's not 
bleeding edge.

It's like asking a painter why he stares at unfinished paintings all day long.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9