Re: Possible bug in 'unset' builtin

[Eduardo A . Bustamante López]

> > [19:24] < dualbus> for every fix that Chet does, he introduces like 2 bugs.
> > Nice way of keeping himself busy
> 
> That points to the importance of having a good, comprehensive test suite.
> It's difficult to test the interaction between features otherwise.

I apologize for my comment :-) I sometimes do not acknowledge the amount of
effort that you put into bash. It's amazing, and I'm very grateful for that.

I do believe that the tests are not good enough though. The reasons:

1. They're slow (I do not know how this could be fixed)
2. They're not automated (you have to eyeball them to see if there are false
positives)
3. There is not enough coverage (though this is easy to fix, with enough
effort)
4. They're not taken with enough seriousness (I ran these in freebsd and
openbsd, and as of this date, multiple unicode tests are failing). IMO the
tests should be run at least for linux/bsd before pushing the code to the
public repository.

BTW, I found this the other day:

    3. We can (and do) run the projects as we wish. We are under no obligation
    to make our source code available in a public distributed source code
    repository of any kind. Should we choose to do so, we get to make the
    choice of version control system to suit ourselves, and use it in the way
    we find most convenient.

(from here: http://www.skeeve.com/fork-my-code.html)

I know that you have some sort of home-made issue tracker, and that you also
use some sort of home-made VCS.

This has been discussed many times in the past, so I'll just repeat myself to
the point of being boring:

Having a public issue tracker and using git properly can make our lifes
easier (by "our" I mean the people that are suscribed to the list that have
some superficial knowledge of the source and that could help you reviewing
patches and also troubleshooting issues). The reasons:

* A public tracker allows us to check the status of open tickets, so that we
can concentrate our efforts on stuff that has not received enough attention.
With the current closed model, we don't know if you've already worked on
something, which means we'd just be wasting efforts.

* git has lots of nice features that work only if you follow the model of "one
logical change per commit". This means that each bug fix, each new feature, ...
have their own commit. This is easier to follow than to try to tear apart the
mega-snapshot-commits that come with multiple changes in one commit.

* The issues in the issue tracker could be linked inside the commit messages,
to have some sort of historic reference for the changes.


Now, for the tests part: have you checked mksh's test suite? It's nice. I was
thinking of extending it and try and run it for bash.


Sorry for my rude comment up there, and thanks for your work in bash.

-- 
Eduardo Bustamante
https://dualbus.me/