Bug tracking policy (was Re: [squeak-dev] Re: Trunk now Toolbuilderized)

Eliot Miranda eliot.miranda at gmail.com
Fri Aug 14 23:30:26 UTC 2009


On Fri, Aug 14, 2009 at 6:05 AM, Keith Hodges <keith_hodges at yahoo.co.uk>wrote:

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



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.


> 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
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090814/bbb1edb3/attachment.htm


More information about the Squeak-dev mailing list