On Thu, Sep 23, 2010 at 6:39 PM, Pierre Stirnwei=
ss
<psti=
rnweiss@googlemail.com> wrote:
Hmmm
I think I can help the testers enough so that they can test both the branch=
and trunk. =A0The 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. =A0Just report it agains=
t
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. =A0I don&=
#39;t
think NEEDMOREINFO is appropriate here because we already have all the
information. =A0LATER would make more sense since it will move to something=
else
later when the branch is discontinued. =A0Or it will get fixed, when it wil=
l be
resolved anyway.
This could probably =
work, provided that the subsequent bug triage of the "branch specific&=
quot; 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, whic=
h 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 t=
o by "gentelman agreement" (nobody forces anyone to speak about t=
he "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 ou=
r rules to fit the needs of our "commercial interest" contributor=
:
I don't think that is just a "commercial&quo=
t; problem. Inside KOffice we have several groups like corporate or non-cop=
orate 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 Kri=
ta team doesn't have a strict review process and everyone can commit, r=
eviews are only done if someone feels that it needs a review. In general th=
is 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 p=
roblem when the different development models clash.
=A0
- our re=
lease schedule does not fit with Nokia's, let's create a branch so =
they can continue to develop features.
=A0 Yes it's open source and nobody can force anybody to work on someth=
ing he is not interrested in. But then, why do we bother with a release sch=
edule 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 effo=
rt 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 sc=
hedules. Inside KOffice we have a big imbalance of development power and ap=
plication 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 w=
e can't all move at the same speed, so branches are a necessary evil.
=A0
- our AP=
I 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 clar=
ify in detail the use case.
=A0 Yes, it was discussed during a sprint where everybody of the community =
was invited. However, not everybody could attend and the resulting design w=
as not presented to the community at large with the grounds for changing th=
e API. The changes were (if I understood properly, so correct me if I am wr=
ong here) done, discussed and approved under the sponsorship of Nokia. Give=
n the people involved, I have no doubt that the design is sound and will im=
prove KOffice. However, the process seems to me like first class citizens d=
oing stuff among themselves, which the second class citizens just have to a=
ccept as good face value.
The problem is that even with completely open project=
s the API doesn't fit often. I have seen several occurrences where some=
one 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 o=
f 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 b=
ug reporting workflow does not fit our workflow of development in a separat=
e 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 a=
re two types of citizens now: the ones who adhere to the community's ru=
les and the ones who can bend the rules when it suits them. I am not very e=
asy with this. It gives me more and more the feeling that KOffice is moving=
from "a community project with welcomed commercial interest contribut=
ions" to "a commercial interest project with welcomed community c=
ontribution".
I recognise the value to the project of having such a big commercial pl=
ayer like Nokia. And I am very thankfull of the contributions they have mad=
e so far (both in terms of code and sponsorship).
However, I think in an=
y 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-rea=
cting/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