> I have said before and I'll say again. I am trying to get that type of
> setup in place but it takes both free time and money to set it up and
> support it long term, neither of which I've had much of lately.
I didn't say you need a CVS-server running, I understand that is a job to setup and maintain.
It would be enough with a tar-package once a week or so, while intensive development is in progress.
> I have not removed anything here. I am going to put out a stable version
> that had a great deal of work and testing done to it.
You're gonna make a stable version without dynamic strings? How?
> I am looking to make hypermail much more modular so that it is easier to
> do unit level testing. The unit level tests will be available on on the
> web site soon. Via unit testing I've found some really nasty bugs while
> adding more robustness.
That sounds like a great idea, indeed.
> And that is a good deal of the problem. You made too many changes
> everywhere for me to take the time to do that at this point. Some I like,
> some I don't understand why they were done. I need to study the changes
> and we need to discuss a bit before I just merge them in.
I'd really like that and would gladly explain all my changes and what I think hypermail needs. I would also explain why hypermail needs the big changes and why it won't be stable until we have dynamic buffers all over. Now why can't we make a branch of the development and let the current version go towards a 2.0 release while us others can focus on developing it further and aim at a 2.1 release further on?
I have no plans of forking the progress and I know I have this dicussion in vain because I know what this looks like in the eyes of the normal person of this list. They trust you and your view, while I've only popped in and distributed a series of unstable betas.
The only thing you risk is that I get bored by the management of the project and abandon it. Which isn't much to lose of course.
> We seem to have different ideas as to what you were trying to accomplish
> while I was out.
I think we have different ideas of good and bad coding practises too. I miss discussions of what we should do and don't. If we continue not having discussions, how could anyone else but you know what to do and how to do it?
> Hypermail is a well used tool that needs a bit more stability than rapid
> prototype development efforts generally have.
Why? People that want maximum stability shouldn't run beta versions at all. And if we think betas should be more stable than they are now, why don't release them as alphas then?
> I need to rethink the beta designation I've been placing on releases. It
> has seriously confused people.
How?
> I do appreciate the efforts you've made and I am not trivializing them
> but there are more issues here... I'm starting to think we may need to
> have a hypermail-dev mailing list for truly alpha development. That way
> alpha versions that should run under controlled, non-production test
> environments could be passed around without confusing the list at large
> as to what is the most stable version to run in a production environment.
I think you're missing a big point of open source development here: release often and to the public. That allows anyone that wants to contribute to the development cycle to download and try new experiment versions, they can mail us the bugreports or they can (attempt to) fix the bugs and mail us the patches. We shouldn't limit the amount of developers more than we need. Its better to be strict about what patches to allow from (unknown) developers.
Yes, we should offer "stable" versions too.
--
Daniel Stenberg - http://www.fts.frontec.se/~dast
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Received on Mon 21 Dec 1998 09:39:41 AM GMT
This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT