release prioritization

Daniel Vainsencher danielv at netvision.net.il
Fri Feb 28 22:07:50 UTC 2003


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 at 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.



More information about the Squeak-dev mailing list