commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Monitoring iterative algorithms
Date Wed, 10 Aug 2011 15:52:02 GMT

> 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.

Yes, because the feature is new: It will probably mostly add code, not
replace something existing which itself could evolve during the branch

It was just a (maybe unnecessary) warning.

> > 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. That's a risk that the developer always faces in these instances.

To be fair, it was not a "community" request; it was a request from me. [See
the discussion in the archives, if you are interested ;-).]
Basically, my position was that CM should focus on math code; for _nothing_
else should it try to reinvent the wheel. In this instance this clashed with
the current policy of not depending on external libraries.

The same problem arises with logging.
And with monitoring: If there would already exist a good (pure-Java) solution
somewhere, it should be re-used, not re-implemented.

> I don't quite see how that's argues against frequent feature branching.

It was just an example of unnecessary work because the decision was made
without regards to the branch code. It was a policy-based decision (no
external library).

> 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
> > 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.
> Not sure what you mean.

Of course, I'm not trying to prevent you from working on a branch. I just
said that I wouldn't recommend it myself. Also because it will require
people to explicitly check out your branch and they might not do it in a
timely fashion so that it might become so out of date that you'll have to do
more work on it to keep in sync with the evolving trunk etc.

This would not be a problem if "lazy consensus" were always working. As far
as I'm concerned it did not work for redesigning the use of exceptions. Cf.
the exception debate that goes on since issue MATH-195.
[As an example of "sticking to old ways".]


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message