Re: [OctDev] Functions in the core

[Jaroslav Hajek]

On Fri, Apr 10, 2009 at 12:45 PM, Thorsten Meyer <address@hidden> wrote:
> Jaroslav Hajek wrote:
>>
>> Maybe we differ slightly in the view of the development archive. IMO
>> these are just patches that can easily be reverted. I didn't even yet
>> add the functions to the build process, so that they won't be
>> installed if someone uses a snapshot - they're just there for
>> development testing. So I don't really regard my act as true addition.
>> The discussion you call for has just started :)
>>
>> I don't basically object to a policy that the main archive should be
>> regarded as a more sacred place. But as I have explained earlier, IMO
>> this significantly clashes with the policy of having a linear archive,
>> which makes parallel development for a longer time quite difficult.
>> So, if that's going to happen, I think we should allow merges. I'll
>> then happily use my experimental repo for most of my development.
>> For instance, I've added a couple of new functions (and extended some)
>> without discussing with anyone, mostly for use in other functions. I
>> hope this is OK, at least nobody complained. Anyone is certainly free
>> to raise objections to any of my patches.
>>
> I think we should really come to a common understanding about how the
> development archive is meant to be used and how "sacred" it is.
>
> About sacredness: the faster the development of octave advances and the more
> contributors we have, I think, the more difficult it will get the avoid that
> experimental, uncomplete or inconsistent changes accumulate in the development
> archive.

I see no reason why they should accumulate, unless the corresponding
developer is reluctant to clean up after himself. They will certainly
happen (and they do happen).

> Once this happens, it could be quite tedious (and not much fun at all)
> to clean it up again. So I personally would prefer to have clear and rather
> strict rules about what is allowed to go into the development archive.

Personally, I felt the ability to push directly to savannah hg as
important boost for my contributions, because I no longer needed to
wait until someone, usually JWE, reviewed and approved my patches.
When I eventually realized that there was generally very little
opposition to my patches, and that I was able to respond to
suggestions quickly, I eventually started pushing most patches
straight away except for fundamental changes.
It seems to me quite easier to say "get the latest tip to try the
stack arrays optimizations" instead of "get revision XXX and apply
patches YYY.1, YYY.2 and YYY.3 from my previous mails to try the stack
arrays optimizations". At least the first option is much easier for
people to actually give it a try.
Developing in separate experimental repo, such as those generously
provided by Thomas Weber, would be comparably easy to try for anyone
(you just clone and build), but it's much harder to manage if merges
are not allowed (see the previous discussions).

> About merges: I don't think that I fully understand what this issue is about,
> mostly because I don't have any experience with merging large development 
> trees.
> Only, I keep reading that distributed version control systems like mercurial
> make merging much less painful than with older tools. Anyway, this seems to be
> about how the development archive can be kept "clean" while at the same time 
> not
> hindering the development of exciting new features and performance 
> improvements
> in octave too much. So what's the best tradeoff between those two aims?

I dunno. I think a linear mainstream repo is OK when the policy is
relaxed - most development will then happen in this repo. Accepting
merges allows more convenient development in parallel repos, and
therefore facilitates imposing a more strict policy for the main repo.
But combining the linear requirement with a strict policy IMHO hingers
the development pace. That's going back to the situation when JWE
needed to review and physically apply all patches.

Right now, I try to honor the linearity, so I develop everything in
small chunks and push them as soon as they're ready, fixing things up
later if problems arise. Right now I can address issues quickly, so I
don't see this as a big problem, but that may change.

All that's just my personal viewpoint, of course.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz