--===============0321146520==
Content-Type: multipart/alternative; boundary=0015174be392e3650a0490f12378
--0015174be392e3650a0490f12378
Content-Type: text/plain; charset=ISO-8859-1
> I don't think that is just a "commercial" problem. Inside KOffice we have
> several groups like corporate or non-coporate developers but also the teams
> for the individual applications. Every group tries to find a set of rules
> that works for them. For example the Krita team doesn't have a strict review
> process and everyone can commit, reviews are only done if someone feels that
> it needs a review. In general this has been worked very good for the Krita
> team. On the other hand we have a quite strict review process on things like
> flake. Of course this causes problem when the different development models
> clash.
>
>
>> - our release schedule does not fit with Nokia's, let's create a branch so
>> they can continue to develop features.
>> Yes it's open source and nobody can force anybody to work on something
>> he is not interrested in. But then, why do we bother with a release schedule
>> and freeze periods,.... In my mind, those things are there because it is
>> good practice in the community to try to concentrate your time and effort
>> during these periods at solving problems. Nobody forces you to, but then
>> again, nobody forces you to leave your seat in the bus to the old person, it
>> is just something you do.
>>
>
> Same problem here. Different groups want different schedules. Inside
> KOffice we have a big imbalance of development power and application
> readiness. Inside the Krita team we sometimes wished to have our own
> schedule, but we are bound to the KOffice one. We have to accept that we
> can't all move at the same speed, so branches are a necessary evil.
>
And Krita people have respected/endured the step backs because being part of
a community is not limited to "when I benefit from it". So far it is the
second freeze in a row that is bypassed. I have no problem with any member
of the community (and that includes Nokia because I still consider Nokia as
a fair community player) to come once in a while and say: "look guys, I have
a problem with such and such, can we make an exception". It's when
exceptions become a rule always for the same that I have a problem. This is
why I express this early: I do not yet have a problem, however it is
starting to itch a bit, so better clarify things now.
Pierre
--0015174be392e3650a0490f12378
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I don't think that is jus= t a "commercial" problem. Inside KOffice we have several groups l= ike corporate or non-coporate developers but also the teams for the individ= ual applications. Every group tries to find a set of rules that works for t= hem. For example the Krita team doesn't have a strict review process an= d everyone can commit, reviews are only done if someone feels that it needs= a review. In general this has been worked very good for the Krita team. On= the other hand we have a quite strict review process on things like flake.= Of course this causes problem when the different development models clash.=
=A0- our release schedule does not fit with Nokia's, let's c= reate a branch so they can continue to develop features.
=A0 Yes it's open source and nobody can force anybody to work on someth= ing he is not interrested in. But then, why do we bother with a release sch= edule and freeze periods,.... In my mind, those things are there because it= is good practice in the community to try to concentrate your time and effo= rt during these periods at solving problems. Nobody forces you to, but then= again, nobody forces you to leave your seat in the bus to the old person, = it is just something you do.
Same problem here. Different groups want differ= ent schedules. Inside KOffice we have a big imbalance of development power = and application readiness. Inside the Krita team we sometimes wished to hav= e our own schedule, but we are bound to the KOffice one. We have to accept = that we can't all move at the same speed, so branches are a necessary e= vil.