Hmm, I think I'll pipe up for just a minute on this, so please excuse any unwanted commentary...
Daniel, although I can't speak for everyone, I must tell you that I really appreciate the fine job you have been doing in contributing to the discussion and development of hypermail on this list. I don't think you need to worry that all the changes you introduced will go for naught, since Kent has announced that he is considering them. But since there were a *lot* of changes made in that time, it is understandable (to me anyway) if not all of them get integrated into the Landfield beta right away.
It sounds to me like Kent is taking pains to ensure the quality of each release by reviewing a lot of new code personally. Under the circumstances particular to this project, I think that is a good idea, even though it takes some extra time.
Since Kent seems to be ready and willing to bear this burden of integration, I don't think it is particularly critical to have super-frequent beta releases. As you must know from experience, each beta release represents a certain amount of work just to document, test, and package the distribution. Plus, having a high number of beta versions out there makes tracking changes and problems that people report more complex. So even though you are quite good at publishing very frequent beta releases, Kent's approach of producing fewer but more carefully planned beta releases is just as effective, IMHO.
Daniel, I know you didn't want to fork the hypermail baseline. But that is exactly what happened when you released your own unofficial beta. (I am glad that you did it because it kept things rolling and progress was indeed made.) So it should be expected that there would be a period of time in which some of your betas will have features (and possibly bugs) that have not yet been introduced to the latest Landfield beta.
Kent, do you have any estimate for when we can expect your next beta release?
--Byron
On Fri, 18 Dec 1998, Kent Landfield wrote:
> 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 08:51:37 PM GMT
This archive was generated by hypermail 2.2.0 : Thu 22 Feb 2007 07:33:50 PM GMT GMT