<br><br><div class="gmail_quote">On Fri, Aug 14, 2009 at 6:05 AM, Keith Hodges <span dir="ltr"><<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
><br>
> Firstly, Board members are free to speak their mind. We usually make<br>
> it clear in writing when something is a decision by the Board.<br>
><br>
> Secondly, Ken stated that "Mantis is falling out of favor", which<br>
> seems an accurate description of how our community uses the bug tracker.<br>
</div>Not at all.<br>
<div class="im">> Wish it was different, but it somehow is at odds with the way this<br>
> community works.<br>
</div>You obviously don't build much in the way of actual working images from<br>
squeak 3.10. I think that this is the problem, the board and Andreas'<br>
gang is currently populated with people don't actually use squeak 3.10<br>
for anything serious, so they are not aware of the tools that are being<br>
used and how they are being used.<br>
<br>
Mantis is in favour, and has been more in favour ever since fixes were<br>
loadable automatically from Installer. Mantis is the only way of<br>
reporting a fix and getting it discussed and making it loadable in all<br>
images that needed in order to make a fix and a dependent package<br>
available to the widest possible audience. It works very well indeed for<br>
that purpose.<br>
<br>
Not only that it works for everyone, not just those working on a<br>
release. Fixes availability on mantis frees people from any dependence<br>
upon the/any release team schedule.<br>
<br>
There has been a lot of contribution from folks like Nicolas Cellier and<br>
others, that is right there.<br>
<div class="im">> (I should also point out that IRC is a second-grade medium in our<br>
> community.<br>
</div>Again I disagree. IRC is a first grade medium, and those of us who have<br>
used it for discussing release team issues have been able to have actual<br>
discussions to make decisions and come to conclusions while talking to<br>
the relevant people. </blockquote><div><br></div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It is only since people started using squeak-dev<br>
and lots of uninvolved and uninformed people enter the fray that things<br>
have gone noticably diluted and pear shaped. This is exactly what<br>
happened in the 3.9 days, and at that time the victim was Marcus. It was<br>
well known that the release team needed to be protected from the open<br>
lions den that is squeak-dev, and this is why the release mailing list<br>
exists. Those who don't learn from history are....<br>
<div class="im">>> Logical considering that we just got the technical side of the<br>
>> process of using mantis to manage fixes working. How about we invest in<br>
>> actually organising people to use mantis properly.<br>
> Good idea. Try to convince people. We tried. As Ken wrote on IRC, "I'm<br>
> tired of fighting this issue after several years now".<br>
</div>No you didn't try. Trying involves actually doing something. Count the<br>
number of emails on squeak-dev on the subject, particularly the ones<br>
after the automation mechanism was completed. What you have done is<br>
undermine all existing work that has already been carried out by telling<br>
people it isn't necessary. Now mantis is going to languish in an<br>
indeterminate state that is not useful to anyone, because mantis is not<br>
actually part of any process whereas it has been for several years.<br>
<br>
I cant try to convince people of anything, because you have told them<br>
that "trunk" is the way to go, I cant compete with, nor should I have<br>
to, nor do I want to compete with Andreas. However Andreas isn't putting<br>
himself in the position to work with anyone, he is overriding everyone else.<br>
If he was truly running an experiment, then it would be bounded, and<br>
would not trash everything else that is and has been worked on.<br>
<div class="im">>>> I guess you misunderstood. Mantis is still where to report bugs.<br>
>>><br>
>>> But if a core developer notices a small bug and can fix it right away,<br>
>>> he can just do so. Formerly, he would have to open a Mantis bug and<br>
>>> attach a changeset.<br>
>> Exactly this should be mandatory<br>
> This is a valid proposal. Who does support it? Who is against?<br>
><br>
> Nothing is set in stone, ideas for better processes are always welcome.<br>
</div>No they aren't. Previously ideas used to require written proposals,<br>
discussion and approval. Now there is no procedure left, it has been<br>
undermined.<br>
You already have a proposal for better processes that you approved, but<br>
you removed that approval without due process, and in doing so you<br>
undermined any future decision that the board makes.<br>
<br>
The board now makes decisions, in one sitting, without consultation, and<br>
they can be entirely contrary. Therefore no one can make a proposal any<br>
more, because it is a worthless concept.<br>
<div class="im">> So far the trunk is still an experiment, we'll see how it goes.<br>
</div>This is complete double speak, ask Andreas if he sees it as an experiment.<br>
<br>
It hasn't been publicised as "an experiment", its certainly hasn't been<br>
a "no impact" on existing procedures experiment. This was announced as<br>
<br>
"THE NEW Process", as in the Definite article, that is not experimental<br>
language. The irony being that what is called "the process" isn't a<br>
process at all.<br>
<br>
If you want to do experiments, how about a poll or even an email to the<br>
community to ask what kind of experiment would be useful. There are<br>
plenty of projects that you could do in "trunks" notice the plural, I<br>
can think of 5 off the top of my head. But you must do each innovation<br>
separately, and without mixing everything together. Innovations must be<br>
for existing images and squeak users not, some as yet experimental image.<br>
<br>
Rio (replacement for FileDirectory) and Logging are examples of this<br>
that might be ready for integration.<br>
<div class="im">>> Please define simply - consider what an average squeak user has to do<br>
>> differently now as compared to the original situation.<br>
><br>
> Core developer:<br>
> 1. Fix bug.<br>
> 2. Commit changed package to trunk.<br>
><br>
> Non-core developer:<br>
><br>
> 1. Fix bug.<br>
> 2. Commit changed package to inbox.<br>
> 3. Open Mantis report.<br>
><br>
> This assumes users are using the trunk image.<br>
</div>Why would anyone be using the trunk image for their daily development?<br>
<div class="im">> If not, you can still attach changesets to mantis, so it's about the<br>
> same as before.<br>
>> Before all I needed was a little changeset generated from my own<br>
>> working image.<br>
> How about a poll: Who actually uses changesets for daily development?<br>
</div>For daily development, I doubt if many people manage MC packages of the<br>
squeak kernel in their repositories. I do however upload fixes to the<br>
kernel to mantis, and load them into my other images from there on a fix<br>
by fix basis.<br>
<div class="im">> I have the impression that use of Monticello has overtaken changesets<br>
> by far.<br>
</div>Not for fixing the kernel. If this was true then why are people working<br>
on things like DeltaStreams.<br>
<div class="im">> Many newer developers are not comfortable with changesets at all.<br>
> Making a changeset from a MC package is still not trivial.<br>
</div>Again people dont use MC for managing the kernel in their working images.<br>
<div class="im">>> Other forks of squeak can browse the list of documented fixes and pick<br>
>> out any that they might also like to adopt, and when they do they can<br>
>> generate their documentation automatically.<br>
> We need to produce this list for a release, indeed. But why not from<br>
> trunk commit logs?<br>
</div>What use would that be to anyone? You cant load a fix from a trunk log,<br>
it doesn't come with any documentation or code.<br>
<div class="im">>> From the community that invented extreme programming this is embarrassing<br>
> Actually, Squeak development in the last two years felt glacial.<br>
</div>Then you haven't been tracking the developments which have happened.<br>
<div class="im">> I have the impression that people like the trunk model because it is<br>
> way more agile, not less.<br>
</div>But you are assuming that nothing happened, The truth is lots happened.<br>
Major issues that plagued the squeak community were addressed and fixed,<br>
although the majority are in a loadable form. Squeak is much much more<br>
usable now than it was 3 years ago, simply because you can load a<br>
complex package like Magma or Seaside in a one liner. Innovations which<br>
were only available in one version of squeak, are now available in<br>
several versions of squeak.<br>
<div class="im">> Many people like Squeak because it allows them to be way more<br>
> productive than in any other tool. So the processes that best fit that<br>
> mind-set do not require external tools. This is what made the old<br>
> update stream attractive -<br>
</div>And as we had already established - prone to incremental expansion, when<br>
the stated goal was the opposite.<br>
<br>
We need the image to reduce and together with that we need tools for<br>
loading the things we have removed back in again. Actually we need these<br>
tools first, prior to removing stuff. Squeak now has those tools but you<br>
aren't using them as part of the process, so in actual fact we are going<br>
backwards.<br>
<div class="im">> you prepared a changeset and submitted it without ever having to<br>
> switch away from Squeak. And this is what makes the trunk attractive.<br>
</div>The "trunk" is a choice made by the board to create another image, which<br>
is "a fork" from the previous image. Apparently we are now told that "it<br>
is only an experiment", except it is unmanaged and unmanageable.<br>
<br>
Previously we expected to have to take a mature approach to development<br>
with people to conceive implement and test innovations prior to<br>
integration. With tools to support the process we can continuously test<br>
an innovation everywhere that it is used. The ability to do this<br>
requires a lot of investment up front, but once you have it, you are<br>
ready to take on the actual enormity of the task.<br>
<br>
You will not be able to replace the need for actual vision, actual<br>
leadership, actual management, and actual testing with a bunch of random<br>
undocumented commits to "trunk".<br>
<br>
regards<br>
<font color="#888888"><br>
Keith<br>
<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br>