[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Bugs against the Essen branch
From: Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date: 2010-09-23 18:07:50
Message-ID: AANLkTi=3LN_fz-qwsiKPXuDwOXpmgzfjTsTnUtcO11xL () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> 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
[Attachment #5 (text/html)]
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: \
0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: \
1ex;"><div class="gmail_quote"><div>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.<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt \
0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: \
1ex;">- our release schedule does not fit with Nokia's, let's \
create a branch so they can continue to develop features.<br>
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.<br>
</blockquote></div><div><br>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.<br> </div></div></blockquote><div><br>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.<br> \
<br>Pierre<br></div></div><br>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic