Hi Keith,

 

Thank you for your response.  

 

In that case I understand your point.  Your method is intended to be used
for two purposes.  Just to be clear we can name them.  

 

1)       Allow developers to post a fix to a specific stable image.

      Bob then:

2)   Runs tests to identify fixes needed in other images.  (Go back to 1)

 

I see this as a very nice feedback loop that finds issues and provides a
methodology to address specific problems.  

 

>From the responses I read it appears that your solution does not work well
for creating that stable image.  We are working on creating stable images
using a method that is similar to the trunk system.  It works because it
gives you a very fast feedback loop for development, but I agree it only
works when you put it into the hands of developers you trust.

 

The fact that the trunk system is taking a long time can be attributed to
how difficult the changes are.  The changes that are going in are
monumental.  If you were to add overhead to the work that is currently going
on I don't think it would get done at all.  

 

So if you can remove your last point we agree.  Your method works well to
support developers that are interested in a methodology to find and fix
problems to stable images because that is what it does: it helps them to
find and address specific problems.

 

The fact that the extra overhead involved to use this method for development
is not supported by the community, I believe, is a direct result of trying
to apply this method to something that you just said doesn't work.  Consider
the current trunk as a single contribution that is being generated by a
team.  The team decided to work together to accomplish something.  When that
is done you will have your stable "non moving target" image.  At that point
I believe the community would see the value of the proposal outweighs the
overhead involved in using it (if it works).

 

With respect,

 

Ron Teitelbaum

 

 

 

  _____  

From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of keith
Sent: Friday, March 12, 2010 1:31 PM
To: Ron at USMedRec.com; The general-purpose Squeak developers list
Subject: Re: [squeak-dev] [Election] ...is soon upon us! Last day info

 

Why couldn't Bob harvest changes from Mantis so they can be reviewed and
posted to trunk?

 

1) Because trunk is a moving target. The principle is that mantis needs to
manage fixes relative to an actual release. So that you can take a
production image and fix bits you need to to keep current. If you are
harvesting fixes from mantis into trunk then you will be adjusting the fixes
to be appropriate to "trunk" (a moving target). 

 

Bob isnt only about harvesting fixes.

 

2) If you are the developer of a package that loads in all forks, you are
supported by the ability to load fixes into the other forks you support. The
trunk process doesn't care about supporting you to keep your package
working.

 

Every change made to trunk is made to trunk only, the implications on that
change to the packages that you may wish to load is not tested. That is what
bob was designed to do, to test the whole, and to test all derived images.

 

2) The bob process is intended to be used in regular cycles, to generate
multiple artifacts, that may then be integrated. Trunk messes this up by
prolonging the release cycle to years to produce one artifact.

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100312/d008c439/attachment.htm