Re: [OctDev] Functions in the core

[Jaroslav Hajek]

On Mon, Apr 13, 2009 at 1:15 AM, Daniel J Sebald <address@hidden> wrote:
> Jaroslav Hajek wrote:
>>
>> 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).
>
> The Hg model of development is fine.  But I would say, watching Octave
> development over several years, that the switch to Hg has brought more
> "bugginess".  I've been watching for months now to jump in and grab a
> version that seems fairly stable,

The stable releases should be fairly stable. Except 3.0.4, which was a
disaster, but an accident.

> but patches come at a quick rate and
> people are reporting bugs on those patches just days afterward.
>

Yes, that's what I like about it. That's one of the strongest points
of free software.

> In the past, John kept bugs low such that a release could be made at almost
> any time and in fact John created versions quite often.

Unfortunately, it seems John now has less time than in the past.

> But if we are switching to a mode where code moves in fast and bugs are left
> for others to find, then that release schedule/policy that John has followed
> will result in what Carlos suggests.  Stable code with less features is
> better than the opposite.
>

Says who? I use the development branch due to new features. When I
find a bug, I fix it (or someone else does), update code, rebuild and
the bug is gone.

>
>>> 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.
>
> John reviews, but you'll also notice that he does the difficult job of
> finding an fixing bugs in those patches.  Look how many times he's said "I
> applied your patch, but I changed..."
>

No question John is a great programmer and maybe the only person who
understands the whole code of Octave, but I don't think he did
anything more magical with the patches than we all do.
I assure you I don't intentionally leave bugs in 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.
>
> Well, things like SourceForge make that easier.  Rather than a mailing list
> there is a patch-list where people can go to try the patch.  It's usually
> someone labelled a "developer" which means "overseer", i.e., they try the
> patch and if there are any problems report back to the patch # that
> something doesn't work.
>

Feel free to propose using any mechanism to improve testing of Octave.
Just to clarify what I meant - it does not matter much where the
patches can be found. The thing is that working with repos is easier
than working with standalone patches, and that's what mercurial is
best designed to do.
Trying a new feature in the development repo is, for me, as easy as
"hg pull -u; make -j2".



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