From koffice-devel Thu Sep 23 18:07:50 2010 From: Pierre Stirnweiss Date: Thu, 23 Sep 2010 18:07:50 +0000 To: koffice-devel Subject: Re: Bugs against the Essen branch Message-Id: X-MARC-Message: https://marc.info/?l=koffice-devel&m=128526532504966 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0321146520==" --===============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.

And Krita people have respected/endured t= he step backs because being part of a community is not limited to "whe= n 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 incl= udes Nokia because I still consider Nokia as a fair community player) to co= me 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 ru= le always for the same that I have a problem. This is why I express this ea= rly: I do not yet have a problem, however it is starting to itch a bit, so = better clarify things now.

Pierre

--0015174be392e3650a0490f12378-- --===============0321146520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============0321146520==--