I don't give you many points for that reasoning. There are always any number of outstanding issues; the amount is only meaningfully limited by a set time frame.

For example, I have in this forum for quite some time ago said that I consider fixing the resolver a prerequisite for a release. Now that's a fair amount of work and I haven't had the inclination to do it. A release can't be held indefinitely because of that, so it's good and well that one is done with a broken resolver anyway. If it were to be done within, say, a month then it could be worth waiting for it, otherwise not. Thus a todo list always have to be set in relation to a suggested deadline.

I'd like to know about a release date at least a week or two in advance. Then I can give you a list of issues I consider embarrassing and/or easy enough to fix before then.

Btw, you contacted me only two days ago about writing a note about sslfile in CHANGES. Maybe you consider two days as an unacceptably long response time so you thought I've just ignored it. I didn't, but I'm unfortunately not always very prompt to answer.

/ Martin Stjernholm, Roxen IS

Previous text:

2004-05-06 02:22: Subject: Pike 7.6

---

You are smart enough to understand that when the tree has been forked and the shrinking todo list reaches zero items there will be a release. I have asked _several_ times in this very forum if there were any outstanding issues anyone wanted to fix before release. The issues mentioned has been dealt with (discussed and dismissed or solved).

/ Martin Nilsson (räfsfiskal)

Huh? I didn't object to that you've made a CHANGES file. It's of course a good effort for which we're all grateful.

Rather I expressed some consternation that I didn't get more than two days to respond to that specific request for help. I've actually yet to read the CHANGES file, and in at least 7.4 I had a fair bit to add to it. It would have been nice to get some time to look it through first; as it is it seems there was two days between the main content and the release in which to do that (assuming that one follows the checkins on a daily basis to be even aware of it, of course).

The main problem with being caught by unexpected releases is that there might be mistakes and silly stuff there that we suddenly have to provide compatibility for.

/ Martin Stjernholm, Roxen IS

Previous text:

2004-05-06 03:59: Subject: Pike 7.6

---

I really don't know what to say. The changes in SSL was made in october, and that's not two days away. It hasn't really been a secret that I worked on a CHANGES file (traditionally the last thing done before a release), since I've asked for contributions more generally several times in different forums (11314702, 11544320). Since there's been no volunteers stepping in I've read through all cvs log messages in Pike from end of 2002. My message was a last attempt to get some additional information before wrapping up.

/ Martin Nilsson (räfsfiskal)

I see nothing wrong with any of this, except that it could have been communicated before the release.

(That reminds me that I forgot to write anything about your certificate changes...)

/ Martin Nilsson (räfsfiskal)

Previous text:

2004-05-06 05:35: Subject: Re: Pike 7.6

---

I understand the desire to get a release "out the door", but in this case, I tend to agree with mast. There were a number of items on my personal todo list, some of which are at present, half complete. Some of them were small, others large (like the tutorial book.) Now, had I known exactly when a branch was going to occur, I could have planned accordingly. I realize that an attempt was made to say, "hey, we're planning on branching sometime soon", but deadlines that don't have dates attached to them don't get my attention, and I'm sure I'm not the only one.

Next time around, I'd like to see a release plan with actual dates. The schedule should include a date for a new feature freeze, at which point all new functionality should be committed, as well as the actual target branch date. These dates should be formally proposed/announced at least a month in advance of the deadlines. Having dates rather than amorphous timeframes allows all of us to coordinate changes and plans. These sorts of "planning" documents should be posted to the website as well, because a) it's a handy reference, b) it helps promote that mystical communication everyone is always griping about, and c) not everyone follows this forum.

As to the comments about having to build release notes, I proposed a solution to that a month ago. At that time, no one voiced an opinion either way. Having a change log that was updated as noteworthy changes get made would make this task simple, if not unnecessary.

Any thoughts?

Bill

/ Brevbäraren

Marcus Agehall suggested that we should write a "feature plan" or something like that and put it on the webpage. My views for the next version of Pike (which I suggest be 8.0):

- Embeddable. - Easy to build on windows. - Smaller. - Documented and "stable" C interface.

/ Martin Nilsson (räfsfiskal)

Previous text:

2004-05-06 05:35: Subject: Re: Pike 7.6

---

I understand the desire to get a release "out the door", but in this case, I tend to agree with mast. There were a number of items on my personal todo list, some of which are at present, half complete. Some of them were small, others large (like the tutorial book.) Now, had I known exactly when a branch was going to occur, I could have planned accordingly. I realize that an attempt was made to say, "hey, we're planning on branching sometime soon", but deadlines that don't have dates attached to them don't get my attention, and I'm sure I'm not the only one.

Next time around, I'd like to see a release plan with actual dates. The schedule should include a date for a new feature freeze, at which point all new functionality should be committed, as well as the actual target branch date. These dates should be formally proposed/announced at least a month in advance of the deadlines. Having dates rather than amorphous timeframes allows all of us to coordinate changes and plans. These sorts of "planning" documents should be posted to the website as well, because a) it's a handy reference, b) it helps promote that mystical communication everyone is always griping about, and c) not everyone follows this forum.

As to the comments about having to build release notes, I proposed a solution to that a month ago. At that time, no one voiced an opinion either way. Having a change log that was updated as noteworthy changes get made would make this task simple, if not unnecessary.

Any thoughts?

Bill

/ Brevbäraren

The problem as I see it, is that it is hard for people (outside of Linköping) to know what to work towards.

And to know what's going on... If it's this hard to discuss things on this list, could we at least get a monthly resumé or something?

/ Mirar

Previous text:

2004-05-06 07:48: Subject: Re: Pike 7.6

---

Since Martin dropped my idea here, perhaps I should explain myself a bit more...

I think that Pike is a very pleasent language with lots of features. Most of the time, missing features are added as needed. This has worked fairly well (and still does).

The problem as I see it, is that it is hard for people (outside of Linköping) to know what to work towards. I feel that we need to structure our efforts a bit so that everyone will know the major goals for the next release. There are plenty of good coders on this list and many of us could pitch in a few lines on one of the goals instead of developing some personal project.

I would like to see some discussion here about the goals. I want to keep the discussion about what should and shouldn't be set as a goal on this list and once a goal has been set, it should be stated on the pike-site.

Once the goals are put on the Pike-site, I would also like to see that each goal gets a more detailed description. Take the suggested goal "embeddable" for example. There was a discussion about it a few weeks ago. It would be nice to have a page with pros and cons of different solutions, pointers to interesting reading etc. Of course, it is possible to search the mailarchive every time, but wouldn't it be practical to document stuff on a webpage to and keep the list for discussions? When I was in Linköping a week ago, I discussed ways of making Pike embeddable with Martin and he suggested a very simple scheme for a first version. That would be perfect to put on a page as a startingpoint for someone to try.

/ Marcus Agehall (Scanian)

On Thu, May 06, 2004 at 10:10:02AM +0200, Mirar @ Pike developers forum wrote:

And to know what's going on... If it's this hard to discuss things on this list, could we at least get a monthly resumé or something?

The problem with ML is that information get lost, at least, it is not visible at once, and grepping is a bit difficult (there are no keywords or categories attached to the messages).

Something like WiKi would be a bit better (for general ideas and summaries), and something like "Feature requests list" (probably, with rating of importance) would be nice too.

My 2 ct :)

Regards, /Al

I'd be glad to help out with these sorts of things...

On Thu, 6 May 2004, Mirar @ Pike developers forum wrote:

...

The problem as I see it, is that it is hard for people (outside of Link�ping) to know what to work towards.

And to know what's going on... If it's this hard to discuss things on this list, could we at least get a monthly resum� or something?

/ Mirar

If we announce some fix date for a version bump, new version fork in the repository or release date for said version, and circumstances would have it we missed that deadline -- would the announce still be worth anything and better than how we did it this time? After all, this situation will occur again, and we could easily have thrown out some date when starting to wrap up things a few weeks or a month ago when Nilsson initiated the release process.

I think the main reason a set date never surfaced was that we know very well release dates are possibly the biggest lies that exist, especially so for as loosely driven projects as Pike. It's also a possibility that a missed release date (either too late or, should some consensus be reached that we are done a week before, early) would have us lose some certain amount of credibility. (Which we supposedly do either way, in not firmly setting down the foot, stomping in a Deadline.)

Personally I'm really glad that we got a fork and release in the first place; those things don't magically happen of their own accord. Surely they can happen differently, but if we do try something else, it would be nice to know in advance how people would react to events that will certainly take place.

/ Johan Sundström (Achtung Liebe!)

Previous text:

2004-05-06 05:35: Subject: Re: Pike 7.6

---

I understand the desire to get a release "out the door", but in this case, I tend to agree with mast. There were a number of items on my personal todo list, some of which are at present, half complete. Some of them were small, others large (like the tutorial book.) Now, had I known exactly when a branch was going to occur, I could have planned accordingly. I realize that an attempt was made to say, "hey, we're planning on branching sometime soon", but deadlines that don't have dates attached to them don't get my attention, and I'm sure I'm not the only one.

Next time around, I'd like to see a release plan with actual dates. The schedule should include a date for a new feature freeze, at which point all new functionality should be committed, as well as the actual target branch date. These dates should be formally proposed/announced at least a month in advance of the deadlines. Having dates rather than amorphous timeframes allows all of us to coordinate changes and plans. These sorts of "planning" documents should be posted to the website as well, because a) it's a handy reference, b) it helps promote that mystical communication everyone is always griping about, and c) not everyone follows this forum.

As to the comments about having to build release notes, I proposed a solution to that a month ago. At that time, no one voiced an opinion either way. Having a change log that was updated as noteworthy changes get made would make this task simple, if not unnecessary.

Any thoughts?

Bill

/ Brevbäraren

I'm not suggesting that the release date be set in stone; in fact, it should be arrived at after consultation with developers. The problem is that if you don't at least set a date and strive to stick with it, things that should get done before a release never do. Sure, nobody likes a slipping release date, but if there's a good reason for it, that has to count for something. The important thing is that there's a goal to work toward. If I have something that I just can't get in before the "feature freeze", I should speak up and if necessary have the dates changed. In these cases, release dates are set for developers (rather than end user release dates ala windows) so that they can prioritize to get the things done that need to be done.

--- CUT HERE --- Example conversation:

You: I was thinking that we should think about getting a release done, as we're coming up on finishing most of the goals of this release (<-- predicated on the idea that there's a release plan.) I'd like to propose a feature freeze for 25th of May. Does this sound doable?

Random developer: I think I need a few extra days to finish up some of the work I was doing on project X. Can we push it out to the 30th?

Me: I think I need an extra month to finish up my Butterfly counting module. How about it.

You to random developer: OK, what you're working on is important to be finished.

You to me: That's a relatively minor project and isn't critical for a release. It'll have to wait.

You: Based on feedback, we're going to shoot for a feature freeze for the 30th of May. I'll add this to the development plan page on the website and will send a reminder as we get closer to the appointed day.

--- CUT HERE ---

As you can see, this doesn't need to be a stifling or overbearing thing. It's just good communications. I know I keep harping on these seemingly silly topics, but in order to get outside developers to participate, these are the kinds of things that _need_ to happen. Maybe there's a need for a development coordinator that handles things like release planning and coordination with external developers. I'm willing to help out, but it doesn't seem like there's any interest in that sort of thing.

Bill

I can't speak for mast, but there were a few minor things I wanted to do to make the work I did (on ssl in particular) seem "complete". It's not a big deal, I can either add them to a future release of 7.6 or wait for 8.0

I'll take notes and keep track of this stuff if anyone wants to start listing items...

To start things off, I'll add my big item:

- Add callback for SSL module to inform calling application of faults in certificate chain and allow calling application to override faults.

Bill

On Thu, 6 May 2004, Mirar @ Pike developers forum wrote:

Seeing this and a lot of discussions about it, I have to ask:

Is there a problem with Pike 7.6.6 that needs to be fixed?

Make a release plan for the next Pike 7.6 now?

/ Mirar

Straight off my head I can think of this small stuff:

o Fix compat for SSL.sslfile (basically retaining the old one in the 7.4 tree). o Fix the remaining issues with the reporting of module load errors. This should also include getting up a basic framework for a visible hierarchy of exception objects. There are some names in the Error module already but it's not certain that that interface is a good one to stick to. o Adapt the Shuffler to the new backend interface. o Remove the support for multiple backends through the old backend interface.

/ Martin Stjernholm, Roxen IS

Previous text:

2004-05-06 17:59: Subject: Pike 7.6

---

Seeing this and a lot of discussions about it, I have to ask:

Is there a problem with Pike 7.6.6 that needs to be fixed?

Make a release plan for the next Pike 7.6 now?

/ Mirar