Le 10/08/2011 16:30, Greg Sterijevski a écrit :
Gilles,
I think we do agree on most points:
For very-limited functionality, this could be an option. The big drawback
is that, if it takes time to implement, the merge with the "official"
branch
may not be trivial. [IIUC, Ted suggested that "git" was superior to "svn"
in making this less of a pain.]
Yes, smaller, "snap on" features are probably best addressed this way. The
issues with merging a feature branch into trunk are well known. The more
things a feature touches, the more merge conflicts present themselves.
However, in the context of monitoring iterative algorithms the merge should
be manageable. There are a lot of these types of minor to medium intensity
feature needs in math commons.
We already used branches and we can use them again.
Gilles is perfectly right, it is difficult to maintain them and this
becomes more and more difficult as time passes. Short-lived branches are
OK, long-lasting branches are a nigthmare. I remember the pain prior to
release 2.2, which is on a branch. Synchronizing what we wanted from
trunk and removing it again after having found unexpected problems was
really difficult.
For functionality that encompasses a large part of the library, or a design
change, or a policy change, it will be even more difficult, even if your
proposal fits the initial bill as discussed on the ML.
I've attempted one such experiment. You could search the archive for
"cal10n". [Another project by Ceki Gulcu. Oops ;-).] I was asked to create
a
"sandbox" branch; I did all the proof-of-concept coding. In the end,
nobody[1] checked out that branch for actual testing and the proposal was
rejected because none of its merits could redeem the supposedly fundamental
flaw of being (optionally) based on an external library (although that had
been made very clear on the ML, also during a very long discussion).
So, for me, never again! And I wouldn't dare advise it to anyone.
Shame on the community in this case. If the community requests a feature and
you do the work for no reason, that's an indictment of the participants and
organizer.
Please, have a look at the archives.
That's a risk that the developer always faces in these instances.
I don't quite see how that's argues against frequent feature branching.
Practically, given the low human resources (w.r.t the amount of code) in CM,
I think that evolving the code together on a single branch is better.
I think if we clean up the log jam that the discussions sometimes generate,
we can maximize the effectiveness of the human resources.
As for the cost of branching, it is almost trivial. svn copy https://fromurl
https://tourl
The cost of branching is trivial. The cost of merging back is huge.
Nevertheless I totally agree with you, and I've said many times on this
list,
that
* we should not expect to solve all problems in one ultimate design
* we should release more often
* we should not stick to old ways
Who could argue against these points? I am only advancing the argument that
a branch allows for trying more new ideas. As for sticking to the old ways.
I'm puzzled. There is nothing wrong with branches and committers can use
them. What Gilles says and I agree is that people should be aware of it
that the merge part can be difficult. So they should be prepared to do it.
Luc
Not sure what you mean.
In my opinion, discussions should serve to solve real problems of a
software
library: bugs, design inconsistencies, efficiency improvements (in that
order).
Regards,
Gilles
[1] Please correct me if I'm wrong, and I apologize if so.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Overall, thank you. The comments were good.
-Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
