Image, 5. 12.

[Thomas Pfeiffer]

> -----Original Message-----
> until we declare the software "complete", then yes, from time to time more
> significant changes will happen and those kinds of changes bring chaos and
> breakage.

Depends on the definition of "breakage". I don't see some bugs here and there as breakage. But when I boot my device and it greets me with a crash of some main component or I cannot start any application, that is "breakage" for me.
I'm not a developer so I don't know the details, yet I've seen at least product (the one my former employer made) that significantly reduced this kind of breakage by doing critical stuff in branches.
That software was never bug-free (not even after releases) and it had many many bugs before the final large testing phase prior to each release, but things were only merged into the main branch when their respective developers deemed them "ready for testing".

> 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 :)

That's what I meant by "Of course the exposure to more testing in master will likely uncover additional minor issues". Yes, stuff needs to be tested and since we don't have a dedicated QA team, we all have to do it.
Yet some of the things that caused "chaos and breakage" were things that simply did not seem finished yet, not in the sense of "Oh, there are still bugs in there" but in the sense of "I'm still working on that so it cannot work as expected yet". 
My impression might be wrong here, so correct me if it is.

I don't have a problem with testing stuff at all. But I would like to test stuff that the developer thinks is finished. He cannot guarantee it's bug-free, so everybody on the team has to test it, of course. But the most obvious problems (like crashes during startup) could already be found by the one who developed something before a larger audience tests it, no?

> there was definitely some overly blown concern expressed and it was felt
> by
> some of the developers. and i'm not pointing fingers at individuals here,
> this
> is a team dynamic that we all need to improve together.

Agreed, that should never happen. It's a community project so it should be fun for everybody.
As for myself: If anybody ever feels offended by anything I say or write, please tell me right away. This is never intentional and can surely be clarified easily. I'm a big fan of openness and honesty and have no problem with admitting mistakes.

I think Plasma Active brings new challenges because of the tight integration of designers and UX people into the development process.
I don't know how the process of working with people like Nuno or Celeste is, maybe we could learn from them?
For Fania and me at least, the situation of being tightly integrated into a community project is rather new.
I have worked with the Amarok and Calligra teams before, but the process there was different. Mostly I gave them suggestions, either I or they made mockups of what they should look like and then I waited for the next beta - or even release - to see how they turned out. Not because the developers wanted it that way but simply because I did not want to learn how or invest the time to compile the applications after every change. This allowed me to always use "finished" software, but at the cost of not being able to correct anything if things did not turn out exactly the way I had envisioned them.

Designers and UX people should be integrated as early as possible in the development process so we are on the right path.
On the other hand, we are like executives: We want to see and touch things. We want to play with them. And for this, they have to at least sort of work. They can have issues here and there, but they need to work well enough so we can at least imagine how well they work for a user.

This is why I like Scrum: After every sprint, I have a "potentially shippable product increment" that I can test. It's not a finished product, but those things that are in there work.

I am sure we will find ways that work for everybody though and hope that nobody gets me wrong.

Cheers,
Thomas