[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:23:52
Message-ID: AANLkTin_FgMnge92qLUAoArdjPq6mG6+a1j2mpBpp0nC () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Sep 23, 2010 at 7:59 PM, Cyrille Berger <cberger@cberger.net> wrote:
> On Thursday 23 September 2010, Pierre Stirnweiss wrote:
> > 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,...
>
> First of all, our rules are a living body meant to accomodate the
> contribution
> of everybody. And make sure that everybody can work efficiently. So when a
> rule
> does not fit, we try to find a solution that work for everyone. And I think
> we
> have reached a satisfactory conclusion.
>
> > It seems lately that we are more and more looking to accomodate our rules
> > to fit the needs of our "commercial interest" contributor:
> >
> > - 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.
>
> I don't understand this... We are moving to git for its "easy" branching
> capabilities, and yet, the people who are the most supporting are opposing
> our
> current branch... It is going to get worse in the future...
>
I have never understood the moving to git as meaning: we will not have
periods "when it is good if everybody could dedicate time into make koffice
more stable" anymore.
>
> > - 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.
>
> Seriously, the change has follow one of our usual path, it has been posted
> for
> review on this list, and Thomas woke up a month later when Boudewijn added
> some documentation to it. In other word, the patch has followed an
> establish
> KDE and KOffice process, in other word, *no* rule has been bend for that
> patch !
>
Once again, it is not a question of Boudewijn ot Thomas. It is not even a
problem with this particular instance on its own. Every drop of water is
just a drop on its own. However, at one point the pot is overfilled. As far
as I am concerned, it is far from being the case. I, however, wanted to
express, very early, an itch I have, that I hope is just circumstantial and
not a trend. I just want to make the relevant people aware of the itch.
>
> > - 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 think we now have found a workflow that satisfy everybody, open bug
> reports
> are for trunk, Nokia testers will also test against trunk, and the bug for
> the
> branch are marked for later. And yes, obviously, it will be up to Nokia
> testers to unmark those bugs when trunk will be opened and if there bug is
> reopened.
>
Same as above.
>
> > 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.
>
> I can fully understand that. We have here two different cultures working
> together, with different agenda. But as far as I am concern, despite a few
> rough edges, Nokia is doing the right thing with their involvement in
> KOffice
> (and other open source projects, ie Qt and even Gnome). We can't really
> complain that they want to work within our community, in the open, usually,
> when it comes to commercial engagement, open source projects complain that
> everything is done behind closed doors, for instance, when Apple forked
> webkit, all their development was behind closed doors, how Sun/Oracle is
> keeping a closed grip on OOo, Canonical forking Gnome... While Nokia is
> working in open, within our community, their sponsored developers are
> commiting many fixes to trunk, doing testing using our tools.
>
> So yes, we need to workout our rules for this to work, but in those cases,
> it
> is more new rules, or clarification of old rules.
>
This is exactly my purpose in raising the subject. I have spoken with Mani
and am sure that all the people involved (commercial or not) genuinly want
to make this a working community. There is indeed a difference in culture
involved here. Hence the need for early discussion. When several cultures
meet in the same community, communication is key to success.
Me raising the subject was never intended as a critic against Nokia, quite
the contrary. If I really thought that Nokia was not genuine when they said
they want to be part of the community, I wouldn't even have spent 10 seconds
writing the mail. I would just have dropped the whole thing and moved along.
Pierre
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Thu, Sep 23, 2010 at 7:59 PM, Cyrille Berger <span \
dir="ltr"><<a href="mailto:cberger@cberger.net">cberger@cberger.net</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">On Thursday 23 September 2010, \
Pierre Stirnweiss wrote:<br> > For me being part of/joining a community means you become a \
citizen of that<br> > community. Every communities have explicit and/or implicit rules, \
which<br> > every citizen should apply/adhere to. Exeptions are foreseen but normally<br>
> only in cases where it is of benefit to the whole community (well at least<br>
> that is the theory).<br>
> In open source communities, these rules are for the vast majority adhered<br>
> to by "gentelman agreement" (nobody forces anyone to speak about the \
"KDE<br> > Software Compilation 4.5" instead of "KDE 4.5", one just \
adhere to the new<br> > PR rule).<br>
> The same goes for several other rules like release schedules, code<br>
> style,...<br>
<br>
</div>First of all, our rules are a living body meant to accomodate the contribution<br>
of everybody. And make sure that everybody can work efficiently. So when a rule<br>
does not fit, we try to find a solution that work for everyone. And I think we<br>
have reached a satisfactory conclusion.<br>
<div class="im"><br>
> It seems lately that we are more and more looking to accomodate our rules<br>
> to fit the needs of our "commercial interest" contributor:<br>
><br>
> - our release schedule does not fit with Nokia's, let's create a branch so<br>
> they can continue to develop features.<br>
> Yes it's open source and nobody can force anybody to work on something he<br>
> is not interrested in. But then, why do we bother with a release schedule<br>
> and freeze periods,.... In my mind, those things are there because it is<br>
> good practice in the community to try to concentrate your time and effort<br>
> during these periods at solving problems. Nobody forces you to, but then<br>
> again, nobody forces you to leave your seat in the bus to the old person,<br>
> it is just something you do.<br>
<br>
</div>I don't understand this... We are moving to git for its "easy" \
branching<br> capabilities, and yet, the people who are the most supporting are opposing \
our<br> current branch... It is going to get worse in the future...<br></blockquote><div><br>I \
have never understood the moving to git as meaning: we will not have periods "when it is \
good if everybody could dedicate time into make koffice more stable" anymore.<br> \
</div><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>
> - our API does not fit a yet unreleased project of Nokia, let's pay some of<br>
> the contributors to just change the API the way we want without having to<br>
> clarify in detail the use case.<br>
> Yes, it was discussed during a sprint where everybody of the community<br>
> was invited. However, not everybody could attend and the resulting design<br>
> was not presented to the community at large with the grounds for changing<br>
> the API. The changes were (if I understood properly, so correct me if I am<br>
> wrong here) done, discussed and approved under the sponsorship of Nokia.<br>
> Given the people involved, I have no doubt that the design is sound and<br>
> will improve KOffice. However, the process seems to me like first class<br>
> citizens doing stuff among themselves, which the second class citizens<br>
> just have to accept as good face value.<br>
<br>
</div>Seriously, the change has follow one of our usual path, it has been posted for<br>
review on this list, and Thomas woke up a month later when Boudewijn added<br>
some documentation to it. In other word, the patch has followed an establish<br>
KDE and KOffice process, in other word, *no* rule has been bend for that patch \
!<br></blockquote><div><br>Once again, it is not a question of Boudewijn ot Thomas. It is not \
even a problem with this particular instance on its own. Every drop of water is just a drop on \
its own. However, at one point the pot is overfilled. As far as I am concerned, it is far from \
being the case. I, however, wanted to express, very early, an itch I have, that I hope is just \
circumstantial and not a trend. I just want to make the relevant people aware of the itch.<br> \
</div><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>
> - the bug reporting workflow does not fit our workflow of development in a<br>
> 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<br>
> impact on the community, the overall behaviour seems to imply that there<br>
> are two types of citizens now: the ones who adhere to the community's<br>
> rules and the ones who can bend the rules when it suits them. I am not<br>
> very easy with this. It gives me more and more the feeling that KOffice is<br>
> moving from "a community project with welcomed commercial interest<br>
> contributions" to "a commercial interest project with welcomed community<br>
> contribution".<br>
<br>
</div>I think we now have found a workflow that satisfy everybody, open bug reports<br>
are for trunk, Nokia testers will also test against trunk, and the bug for the<br>
branch are marked for later. And yes, obviously, it will be up to Nokia<br>
testers to unmark those bugs when trunk will be opened and if there bug is<br>
reopened.<br></blockquote><div><br>Same as above.<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;"> <div class="im"><br>
> I recognise the value to the project of having such a big commercial player<br>
> like Nokia. And I am very thankfull of the contributions they have made so<br>
> far (both in terms of code and sponsorship).<br>
> However, I think in any community, no matter how big one's contribution to<br>
> the community is, one should adhere to the principles of that community. I<br>
> hope I am over-reacting/over-interpreting things, when I feel a trend to<br>
> 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<br>
> ease with all this.<br>
<br>
</div>I can fully understand that. We have here two different cultures working<br>
together, with different agenda. But as far as I am concern, despite a few<br>
rough edges, Nokia is doing the right thing with their involvement in KOffice<br>
(and other open source projects, ie Qt and even Gnome). We can't really<br>
complain that they want to work within our community, in the open, usually,<br>
when it comes to commercial engagement, open source projects complain that<br>
everything is done behind closed doors, for instance, when Apple forked<br>
webkit, all their development was behind closed doors, how Sun/Oracle is<br>
keeping a closed grip on OOo, Canonical forking Gnome... While Nokia is<br>
working in open, within our community, their sponsored developers are<br>
commiting many fixes to trunk, doing testing using our tools.<br>
<br>
So yes, we need to workout our rules for this to work, but in those cases, it<br>
is more new rules, or clarification of old rules.<br></blockquote><div><br>This is exactly my \
purpose in raising the subject. I have spoken with Mani and am sure that all the people \
involved (commercial or not) genuinly want to make this a working community. There is indeed a \
difference in culture involved here. Hence the need for early discussion. When several cultures \
meet in the same community, communication is key to success.<br> Me raising the subject was \
never intended as a critic against Nokia, quite the contrary. If I really thought that Nokia \
was not genuine when they said they want to be part of the community, I wouldn't even have \
spent 10 seconds writing the mail. I would just have dropped the whole thing and moved \
along.<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