commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Monitoring iterative algorithms
Date Wed, 10 Aug 2011 18:21:26 GMT
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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> Overall, thank you. The comments were good.
>
> -Greg
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message