Noel J. Bergman wrote:
As you suggest, we want development to happen actively within source
control, so that people can see the changes as they happen.
This has not been my impression: I received "alerts" every time I
committed something without discussing first.
I always said that we could revert but it is better to see changes as
they are created, expecially when a change is composed by many "step by
step" commits.
The fetchmail
code might have been a good example of when to use a branch, since it was
relatively isolated, and would have been easy to merge in afterwards.
I already imagine how many mailing list messages I would have seen if I
simply started a new "sandbox/fetchmail-refactoring" folder and started
my 2 hours commit session there.
Steve
wasn't saying that the changes were bad, he was saying that the changes were
substantial, and without having good testing coverage, they are very risky
to replace code in trunk that is generally considered to be working.
"Unlike when I refactored it, it isn't broken and no new features are
added so we are not satisfying any user requirements. "
"In making these changes, without even a safety net of unit tests, we
are destabilising a component for no more than a matter of style. To me,
this doesn't seem wise. There are no obvious benefits that outweigh the
risks."
My english is not good, but I don't interpret it as "+1 if you add unit
tests, -0 otherwise"... I get it as a -1 without explicit vote.
I also wrote something really clear: "If I understand your words you
are: -1 to apply the code for a 2.4 release but you don't apply a veto
if the release will be 3.0 or if we add unit tests, is it right? "
No reply is not a fast solution. 3 days have passed and I forgot 50% of
the things I needed to understand to refactor Fetchmail. This is all
time lost either way.
James is a great project but sometimes we take to long
Yes. And one of the things that held us up for a long time was making
changes that blocked our ability to get good releases out the door. I'd
like to learn from that, and avoid a repeat.
--- Noel
If this is referred to anything happened in the last year I'm interested
going deeply, otherwise it is old stuff and ASF is made by people and
not by past scenarios.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
