[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Bugs against the Essen branch
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2010-09-23 17:59:11
Message-ID: 201009231959.11969.cberger () cberger ! net
[Download RAW message or body]

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...
 
> - 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 !
 
> - 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.

> 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.

-- 
Cyrille Berger
_______________________________________________
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]