Hi Hannes.
Let's see if we can summarize and answer your points -
[Tests] Tests are needed, us Guides know this, you're preaching to the choir. The community should continue to supply tests, and some will be used to approve releases. We won't use tests we don't have. If someone compiles, as has been suggested, a test package on SM, it might help.
[Status - everyone should know where each release stands. Could be solved with a bug/issue DB] You're right. We need such a tool, but - we need more urgently a fix tracking tool, to make sure we don't lose work that people submit - fixes are higher priority than bugs, because people become more upset when you lose their changesets than when you ignore their bugs.
We're planning to make such a tool, but we haven't made much progress in that, either. We could really use some help from the community with either of them.
About reporting status - Actually, in the Linux community, there's a guy that simply follows the discussions, Linus and gets updates from other developers, and maintains a list of patches/issues, and where in the pipeline they are (planning coding testing in - sort of like the list I made for refactorings). He updates this list and posts it publically every so often. This could be done once a month. As you say, it would help everyone immensely, by keeping us all on the same page and showing us exactly what's stuck. If anyone from the documentation project or at all is volunteering to provude such a status report on a regular basis, that'd bee a meaningful contribution to the community.
[You want a near perfect release for 3.4] Your objections have been noted, the bugs have been rated as non-critical, and a release will be issued at Doug's convinience. Fixes for the bugs that have been proposed will be reviewed and passed into 3.5a quite soon after the release of 3.4.
[You fear that 3.4 will last a long time because there's no explicit plan for 3.5] One will be made, after 3.4 is laid to rest, with the participation of the community, as you've been told by both Craig and I before. Your fears are probably unfounded - we have spoken about 3.5 as a probably second short release to get the process optimized. You're welcome to find this on the squeakfoundation archives, where all discussions on this topic reside.
[focus] We don't at all focus solely on schedule issues, to say this is to ignore the distinguishable amounts of verbiage us Guides have been generating, some of us more than others, on completely other topics <embarrassed grin>. But actually, our sole page of real hard policy, which is linked off the release plan page, is "the lifecycle of a release" page, which you should read, because it's concerned with quality, and it is that that we're attempting to follow.
Daniel
Hannes Hirzel hannes.hirzel.squeaklist@bluewin.ch wrote:
Now a question everybody who is looking at your work would come up with:
Are these goals met and if yes by which criteria is this evaluated. You have put five points on this list. What do you have to say about them at the end of February?
Postponing an issue is fully a viable option if there are important new reasons coming up. This has to be discussed and communicated.
And: A list of open issues and major known bugs is surely a useful tool for guiding a development process.
I do not see any links on the above mentioned pages.
In the SqC area for various reasons Dan Ingalls used to be the "development process" (chief programmer approach). Because of his long experience he just took care of a lot of things. In the post SqC area the process should be made more explicit. We have all these nice tools and communication aids (mailing lists, Swikis / even world wide phone calls are accessible for many) - why not use them?
I'm hoping that this stimulates you to not soley focus on schedule issues. I really recommend you to (re)read the excellent write-up by Daniel Vainsencher about the nature of releases http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from today).
Regards and happy Squeaking!
Hannes
P.S. My emphasis for having a proper (not perfect!) 3.4 release is motivated by my fears it might be the base for further development for a rather long time. This is fed by the fact that on the release plan (http://swiki.squeakfoundation.org/squeakfoundation/79) there is no single sentence about 3.5 not to speak of 3.6 and 3.7.
Daniel Vainsencher wrote:
... [Status - everyone should know where each release stands. Could be solved with a bug/issue DB] You're right. We need such a tool, but - we need more urgently a fix tracking tool, to make sure we don't lose work that people submit - fixes are higher priority than bugs, because people become more upset when you lose their changesets than when you ignore their bugs.
We're planning to make such a tool, but we haven't made much progress in that, either. We could really use some help from the community with either of them.
I put together a swiki page awhile ago (which I just updated a bit) with some initial thoughts on how such a tool might work:
http://swiki.squeakfoundation.org/squeakfoundation/86
Feel free to add comments at the end of the page. I'm planning to start working on this as soon as 3.4 is released, but if anyone else is interested in helping out with this, that would be great.
- Doug Way
squeak-dev@lists.squeakfoundation.org