[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Bugs against the Essen branch
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2010-09-23 17:53:20
Message-ID: AANLkTiktYtr0nbY+wkjKjumyscGYePXrpR4Z5N6pUq_o () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Sep 23, 2010 at 6:39 PM, Pierre Stirnweiss <
pstirnweiss@googlemail.com> wrote:
>
> Hmmm
>>
>> I think I can help the testers enough so that they can test both the
>> branch
>> and trunk. The workflow will be such that they test the branch, and for
>> the
>> bugs that they actually find, they will test trunk too.
>>
>> For bugs in that are in both, there is no problem. Just report it against
>> trunk, and when it is solved there it will be synced with the branch and
>> everybody is happy.
>>
>> The problem are those bugs that exist in branch but not in trunk. I don't
>> think NEEDMOREINFO is appropriate here because we already have all the
>> information. LATER would make more sense since it will move to something
>> else
>> later when the branch is discontinued. Or it will get fixed, when it will
>> be
>> resolved anyway.
>>
>>
> This could probably work, provided that the subsequent bug triage of the
> "branch specific" bugs are taken care by the people who worked on that
> branch.
>
> However, I have to confess a bit of an uneasy feeling lately:
>
> For me being part of/joining a community means you become a citizen of that
> community. Every communities have explicit and/or implicit rules, which
> every citizen should apply/adhere to. Exeptions are foreseen but normally
> only in cases where it is of benefit to the whole community (well at least
> that is the theory).
> In open source communities, these rules are for the vast majority adhered
> to by "gentelman agreement" (nobody forces anyone to speak about the "KDE
> Software Compilation 4.5" instead of "KDE 4.5", one just adhere to the new
> PR rule).
> The same goes for several other rules like release schedules, code
> style,...
>
> It seems lately that we are more and more looking to accomodate our rules
> to fit the needs of our "commercial interest" contributor:
>
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.
> - our API does not fit a yet unreleased project of Nokia, let's pay some of
> the contributors to just change the API the way we want without having to
> clarify in detail the use case.
> Yes, it was discussed during a sprint where everybody of the community
> was invited. However, not everybody could attend and the resulting design
> was not presented to the community at large with the grounds for changing
> the API. The changes were (if I understood properly, so correct me if I am
> wrong here) done, discussed and approved under the sponsorship of Nokia.
> Given the people involved, I have no doubt that the design is sound and will
> improve KOffice. However, the process seems to me like first class citizens
> doing stuff among themselves, which the second class citizens just have to
> accept as good face value.
>
The problem is that even with completely open projects the API doesn't fit
often. I have seen several occurrences where someone fixed something in
flake and it completely broke Krita. So I often feel that Krita is a second
class citizien when it comes to flake. The problem is that nobody has a
complete overview. The are huge differences in terms of usecases between
e.g. FreOffice and Krita, so you have to accept usecases that don't make any
sense to you. Everyone strives to make the API as clean as possible, but at
the same time we have to make compromises to fit the needs of other people.
- the bug reporting workflow does not fit our workflow of development in a
> separate branch during freeze, let's accomodate the bug reporting workflow.
>
> Even if individually they all seem pretty harmless with quite a minimal
> impact on the community, the overall behaviour seems to imply that there are
> two types of citizens now: the ones who adhere to the community's rules and
> the ones who can bend the rules when it suits them. I am not very easy with
> this. It gives me more and more the feeling that KOffice is moving from "a
> community project with welcomed commercial interest contributions" to "a
> commercial interest project with welcomed community contribution".
>
> I recognise the value to the project of having such a big commercial player
> like Nokia. And I am very thankfull of the contributions they have made so
> far (both in terms of code and sponsorship).
> However, I think in any community, no matter how big one's contribution to
> the community is, one should adhere to the principles of that community. I
> hope I am over-reacting/over-interpreting things, when I feel a trend to
> accomodate our rules/principles only to suit one member's agenda.
>
> I just had to put this out of my chest, because I feel less and less at
> ease with all this.
>
> Pierre
>
>
[Attachment #5 (text/html)]
<div class="gmail_quote">On Thu, Sep 23, 2010 at 6:39 PM, Pierre Stirnweiss <span \
dir="ltr"><<a href="mailto:pstirnweiss@googlemail.com">pstirnweiss@googlemail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; \
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im"><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;">Hmmm<br> <br>
I think I can help the testers enough so that they can test both the branch<br>
and trunk. The workflow will be such that they test the branch, and for the<br>
bugs that they actually find, they will test trunk too.<br>
<br>
For bugs in that are in both, there is no problem. Just report it against<br>
trunk, and when it is solved there it will be synced with the branch and<br>
everybody is happy.<br>
<br>
The problem are those bugs that exist in branch but not in trunk. I don't<br>
think NEEDMOREINFO is appropriate here because we already have all the<br>
information. LATER would make more sense since it will move to something else<br>
later when the branch is discontinued. Or it will get fixed, when it will be<br>
resolved anyway.<br>
<div><div></div><br></div></blockquote></div><br></div>This could probably work, \
provided that the subsequent bug triage of the "branch specific" bugs are \
taken care by the people who worked on that branch.<br> <br>However, I have to \
confess a bit of an uneasy feeling lately:<br> <br>For me being part of/joining a \
community means you become a citizen of that community. Every communities have \
explicit and/or implicit rules, which every citizen should apply/adhere to. Exeptions \
are foreseen but normally only in cases where it is of benefit to the whole community \
(well at least that is the theory).<br>
In open source communities, these rules are for the vast majority adhered to by \
"gentelman agreement" (nobody forces anyone to speak about the "KDE \
Software Compilation 4.5" instead of "KDE 4.5", one just adhere to the \
new PR rule).<br>
The same goes for several other rules like release schedules, code \
style,...<br><br>It seems lately that we are more and more looking to accomodate our \
rules to fit the needs of our "commercial interest" contributor:<br> \
</blockquote><div><br>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><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><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><blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, \
204, 204); padding-left: 1ex;">- our API does not fit a yet unreleased project of \
Nokia, let's pay some of the contributors to just change the API the way we want \
without having to clarify in detail the use case.<br> Yes, it was discussed during a \
sprint where everybody of the community was invited. However, not everybody could \
attend and the resulting design was not presented to the community at large with the \
grounds for changing the API. The changes were (if I understood properly, so correct \
me if I am wrong here) done, discussed and approved under the sponsorship of Nokia. \
Given the people involved, I have no doubt that the design is sound and will improve \
KOffice. However, the process seems to me like first class citizens doing stuff among \
themselves, which the second class citizens just have to accept as good face \
value.<br> </blockquote><div><br>The problem is that even with completely open \
projects the API doesn't fit often. I have seen several occurrences where someone \
fixed something in flake and it completely broke Krita. So I often feel that Krita is \
a second class citizien when it comes to flake. The problem is that nobody has a \
complete overview. The are huge differences in terms of usecases between e.g. \
FreOffice and Krita, so you have to accept usecases that don't make any sense to \
you. Everyone strives to make the API as clean as possible, but at the same time we \
have to make compromises to fit the needs of other people.<br> <br></div><blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, \
204, 204); padding-left: 1ex;">- the bug reporting workflow does not fit our workflow \
of development in a separate branch during freeze, let's accomodate the bug \
reporting workflow.<br> <br>Even if individually they all seem pretty harmless with \
quite a minimal impact on the community, the overall behaviour seems to imply that \
there are two types of citizens now: the ones who adhere to the community's rules \
and the ones who can bend the rules when it suits them. I am not very easy with this. \
It gives me more and more the feeling that KOffice is moving from "a community \
project with welcomed commercial interest contributions" to "a commercial \
interest project with welcomed community contribution".<br>
<br>I recognise the value to the project of having such a big commercial player like \
Nokia. And I am very thankfull of the contributions they have made so far (both in \
terms of code and sponsorship).<br>However, I think in any community, no matter how \
big one's contribution to the community is, one should adhere to the principles \
of that community. I hope I am over-reacting/over-interpreting things, when I feel a \
trend to accomodate our rules/principles only to suit one member's agenda.<br>
<br>I just had to put this out of my chest, because I feel less and less at ease with \
all this.<br><font color="#888888"><br>Pierre</font><br> <br></blockquote></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