[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