*Please* change the subject line if you change the topic of a thread.  
Thanks.

On 14.08.2009, at 04:01, Keith Hodges wrote:

> Bert Freudenberg wrote:
>> On 13.08.2009, at 21:57, Simon Michael wrote:
>>>
>>> Also, would you prefer to see this report on-list or in mantis ? I
>>> thought mantis was still a mandatory part of our process, but today
>>> I'm hearing not. If it's optional, I might start reporting quick
>>> issues to the list using the debugger's great mail out bug report
>>> feature.
> Actually, last I saw from a board member on irc is that mantis is on  
> its
> way out.

Firstly, Board members are free to speak their mind. We usually make  
it clear in writing when something is a decision by the Board.

Secondly, Ken stated that "Mantis is falling out of favor", which  
seems an accurate description of how our community uses the bug  
tracker. Wish it was different, but it somehow is at odds with the way  
this community works.

(I should also point out that IRC is a second-grade medium in our  
community. So it's good you bring that to the attention of the mailing  
list. I think the discussion you refer to starts at 09:29:02 here: http://tunes.org/~nef/logs/squeak/09.08.13 
  )

> Logical considering that we just got the technical side of the
> process of using mantis to manage fixes working. How about we invest  
> in
> actually organising people to use mantis properly.

Good idea. Try to convince people. We tried. As Ken wrote on IRC, "I'm  
tired of fighting this issue after several years now".

>> I guess you misunderstood. Mantis is still where to report bugs.
>>
>> But if a core developer notices a small bug and can fix it right  
>> away,
>> he can just do so. Formerly, he would have to open a Mantis bug and
>> attach a changeset.
> Exactly this should be mandatory

This is a valid proposal. Who does support it? Who is against?

Nothing is set in stone, ideas for better processes are always  
welcome. So far the trunk is still an experiment, we'll see how it goes.

>> Now he can simply
> Please define simply - consider what an average squeak user has to do
> differently now as compared to the original situation.

Core developer:
1. Fix bug.
2. Commit changed package to trunk.

Non-core developer:

1. Fix bug.
2. Commit changed package to inbox.
3. Open Mantis report.

This assumes users are using the trunk image. If not, you can still  
attach changesets to mantis, so it's about the same as before.

> Before all I needed was a little changeset generated from my own  
> working image.

How about a poll: Who actually uses changesets for daily development?

I have the impression that use of Monticello has overtaken changesets  
by far. Many newer developers are not comfortable with changesets at  
all. Making a changeset from a MC package is still not trivial.

> Other forks of squeak can browse the list of documented fixes and pick
> out any that they might also like to adopt, and when they do they can
> generate their documentation automatically.
>>

We need to produce this list for a release, indeed. But why not from  
trunk commit logs?

> From the community that invented extreme programming this is  
> embarrassing


Actually, Squeak development in the last two years felt glacial. I  
have the impression that people like the trunk model because it is way  
more agile, not less.

Many people like Squeak because it allows them to be way more  
productive than in any other tool. So the processes that best fit that  
mind-set do not require external tools. This is what made the old  
update stream attractive - you prepared a changeset and submitted it  
without ever having to switch away from Squeak. And this is what makes  
the trunk attractive.

The idea of relying on external tools, web sites, shell scripts etc.  
is only slowly catching on, if at all. This is the unixy open-source  
way, true, but just look at the sorrow state of Squeak packages in the  
major distributions. Not too many community members come from that  
background. This is what I suspect is the reason this mindset not more  
widely supported here.

- Bert -