Michael Wechner wrote:
> Andreas Hartmann wrote:
>> Michael Wechner wrote:
>>
>> [...]
>>
>>>> How can we solve this problem?
>>>
>>> by listening to each other and not just doing
stuff with high
>>> potential of breaking things without discussing
it beforehand. This
>>> is what really destroys a community.
>>
>> IMO with a CTR policy
>
> what exactly do you mean by CTR
commit then review
> (there are many acronyms out there and
> maybe we want to clarify this first)
>> every committer should decide when a change should
>> be discussed. Sometimes the decision can be wrong -
for instance, I have
>> recognized that I should have discussed some of my
recent changes before-
>> hand. But then a discussion can follow, and changes
can be reverted.
>
> some changes cannot be reverted that easily. For
instance if someone is
> changing the content model
> and some people upgrade and spend a lot of time on
this, and then it
> will be reverted, what do you think
> how many poeple will be frustrated in the end. And then
it might change
> again ...
I understand your concern. I see no way to solve it with the
current
situation (trunk in production use), therefore I agree that
we have to
be careful until there is a release. In the future, I hope
we won't have
this situation anymore.
>> I think it is important how the community handles
such a situation.
>>
>> "Breaking things" is not always a bad
thing, sometimes a change just
>> shows
>> where problems exist (e.g., a change to the
repository layer might show
>> where the layer was bypassed).
>
> one can break things locally and then discuss it with
others.
> This is one of the reasons why local workspaces are a
great thing.
> I agree that one cannot share the local findings so
easily, but this one
> of the reasons why we have
> the sandbox
>
>> Even the perception if something is
>> "broken" can depend on the point of
view. E.g., IMO things are really
>> broken if principles like SoC or IoC are violated,
or antipatterns occur.
>
> I wouldn't call this broken
OK
> and I think it's important that we agree
> what a term means.
+1
Maybe the term "broken" should be entirely
avoided. We should use the
terms which apply to the actual problem:
- functional problem
- quality problem
- usability problem
- ...
>> Functional bugs can be fixed, I don't consider
them real problems
>> (at least in an unstable branch).
>
> it depends on the siutation.
>>
>> I share Thorsten's concerns about the community.
>>
>> Some ideas how to improve it from my point of view:
>>
>> - Stronger participation in discussions, reacting
to proposals.
>> Even a "+-0" or "Interesting,
but I have no idea" is great.
>
> yes, this would be nice, but I am afraid these things
will always slip
> through sometimes
> (for instance some people might be on vacation or it is
weekend or they
> have too much else to do and don't find
> the time to work through the backlog)
Sure, not everyone will always comment a proposal. But, in
general,
I think there could be more participation in discussions.
>> People should feel encouraged to express their
ideas on the list.
>> I have to admit that I'm rather discouraged,
which unfortunately
>> resulted in unannounced commits.
>
> why are you discouraged?
Sometimes I have the feeling that discussions either tend to
become
endless and lose focus, become to emotional and personal, or
that
there is a lack of interest.
Yes, that shouldn't lead to the situation that discussions
are
avoided. I sometimes dealt with this by lowering my
"discuss before
commit" threshold, but I agree that the better way
would be trying
to improve the quality and effectiveness of discussions. Any
ideas
how to achieve this are appreciated ...
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache
Lenya
http://www.wyona.com
http://lenya.apache.org
andreas.hartmann wyona.com andreasapache.org
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org
|