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
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
