[squeak-dev] Trunk now Toolbuilderized ;-)

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

Not at all.

> Wish it was different, but it somehow is at odds with the way this
> community works.

You obviously don't build much in the way of actual working images from
squeak 3.10. I think that this is the problem, the board and Andreas'
gang is currently populated with people don't actually use squeak 3.10
for anything serious, so they are not aware of the tools that are being
used and how they are being used.

Mantis is in favour, and has been more in favour ever since fixes were
loadable automatically from Installer. Mantis is the only way of
reporting a fix and getting it discussed and making it loadable in all
images that needed in order to make a fix and a dependent package
available to the widest possible audience. It works very well indeed for
that purpose.

Not only that it works for everyone, not just those working on a
release. Fixes availability on mantis frees people from any dependence
upon the/any release team schedule.

There has been a lot of contribution from folks like Nicolas Cellier and
others, that is right there.

> (I should also point out that IRC is a second-grade medium in our
> community.

Again I disagree. IRC is a first grade medium, and those of us who have
used it for discussing release team issues have been able to have actual
discussions to make decisions and come to conclusions while talking to
the relevant people.

It is only since people started using squeak-dev
and lots of uninvolved and uninformed people enter the fray that things
have gone noticably diluted and pear shaped. This is exactly what
happened in the 3.9 days, and at that time the victim was Marcus. It was
well known that the release team needed to be protected from the open
lions den that is squeak-dev, and this is why the release mailing list
exists. Those who don't learn from history are....

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

No you didn't try. Trying involves actually doing something. Count the
number of emails on squeak-dev on the subject, particularly the ones
after the automation mechanism was completed. What you have done is
undermine all existing work that has already been carried out by telling
people it isn't necessary. Now mantis is going to languish in an
indeterminate state that is not useful to anyone, because mantis is not
actually part of any process whereas it has been for several years.

I cant try to convince people of anything, because you have told them
that "trunk" is the way to go, I cant compete with, nor should I have
to, nor do I want to compete with Andreas. However Andreas isn't putting
himself in the position to work with anyone, he is overriding everyone else.
If he was truly running an experiment, then it would be bounded, and
would not trash everything else that is and has been worked on.

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

No they aren't. Previously ideas used to require written proposals,
discussion and approval. Now there is no procedure left, it has been
undermined.
You already have a proposal for better processes that you approved, but
you removed that approval without due process, and in doing so you
undermined any future decision that the board makes.

The board now makes decisions, in one sitting, without consultation, and
they can be entirely contrary. Therefore no one can make a proposal any
more, because it is a worthless concept.

> So far the trunk is still an experiment, we'll see how it goes.

This is complete double speak, ask Andreas if he sees it as an experiment.

It hasn't been publicised as "an experiment", its certainly hasn't been
a "no impact" on existing procedures experiment. This was announced as

"THE NEW Process", as in the Definite article, that is not experimental
language. The irony being that what is called "the process" isn't a
process at all.

If you want to do experiments, how about a poll or even an email to the
community to ask what kind of experiment would be useful. There are
plenty of projects that you could do in "trunks" notice the plural, I
can think of 5 off the top of my head. But you must do each innovation
separately, and without mixing everything together. Innovations must be
for existing images and squeak users not, some as yet experimental image.

Rio (replacement for FileDirectory) and Logging are examples of this
that might be ready for integration.

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

Why would anyone be using the trunk image for their daily development?

> 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?

For daily development, I doubt if many people manage MC packages of the
squeak kernel in their repositories. I do however upload fixes to the
kernel to mantis, and load them into my other images from there on a fix
by fix basis.

> I have the impression that use of Monticello has overtaken changesets
> by far.

Not for fixing the kernel. If this was true then why are people working
on things like DeltaStreams.

> Many newer developers are not comfortable with changesets at all.
> Making a changeset from a MC package is still not trivial.

Again people dont use MC for managing the kernel in their working images.

>> 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?

What use would that be to anyone? You cant load a fix from a trunk log,
it doesn't come with any documentation or code.

>> From the community that invented extreme programming this is embarrassing
> Actually, Squeak development in the last two years felt glacial.

Then you haven't been tracking the developments which have happened.

> I have the impression that people like the trunk model because it is
> way more agile, not less.

But you are assuming that nothing happened, The truth is lots happened.
Major issues that plagued the squeak community were addressed and fixed,
although the majority are in a loadable form. Squeak is much much more
usable now than it was 3 years ago, simply because you can load a
complex package like Magma or Seaside in a one liner. Innovations which
were only available in one version of squeak, are now available in
several versions of squeak.

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

And as we had already established - prone to incremental expansion, when
the stated goal was the opposite.

We need the image to reduce and together with that we need tools for
loading the things we have removed back in again. Actually we need these
tools first, prior to removing stuff. Squeak now has those tools but you
aren't using them as part of the process, so in actual fact we are going
backwards.

> you prepared a changeset and submitted it without ever having to
> switch away from Squeak. And this is what makes the trunk attractive.

The "trunk" is a choice made by the board to create another image, which
is "a fork" from the previous image. Apparently we are now told that "it
is only an experiment", except it is unmanaged and unmanageable.

Previously we expected to have to take a mature approach to development
with people to conceive implement and test innovations prior to
integration. With tools to support the process we can continuously test
an innovation everywhere that it is used. The ability to do this
requires a lot of investment up front, but once you have it, you are
ready to take on the actual enormity of the task.

You will not be able to replace the need for actual vision, actual
leadership, actual management, and actual testing with a bunch of random
undocumented commits to "trunk".

regards

Keith

>     Again I disagree. IRC is a first grade medium, and those of us who
>     have
>     used it for discussing release team issues have been able to have
>     actual
>     discussions to make decisions and come to conclusions while talking to
>     the relevant people.
>
>
>
> Nothing other than a store-and-forward messaging system is suitable
> for a global process whose participants are volunteers.  IRC is
> real-time and so simply doesn't function across time zones, and
> doesn't function across participants extra-project time constraints.
>  Keith, get real.

IRC works fine for that, you read the days' discussions and catch up.
You post questions that others answer when they wake up.

Keith