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

Keith Hodges keith_hodges at yahoo.co.uk
Fri Aug 14 14:57:27 UTC 2009


Michael Haupt wrote:
> Hi Keith,
>
> On Fri, Aug 14, 2009 at 3:16 PM, Keith Hodges<keith_hodges at yahoo.co.uk> wrote:
>   
>>> As for reporting, I'd strongly opt for not having to report (and
>>> attach a changeset) every little thing I can immediately fix. Why
>>> should the fix be stored in two different places: the trunk, and
>>> Mantis? It's waste.
>>>
>>>       
>> Putting fixes into trunk is a waste I agree, so what do we need the
>> trunk for again?
>>     
>
> I presume you intentionally mistook me there. :-)
>   
Indeed.
>> Core developers should be working on particular innovations, bounded
>> within certain packages and with documentation and deliverables. They
>> should not be let loose on the image indescriminately.
>>     
>
> I don't think this is the case. Apart from that, getting the image "in
> shape" (in the form of a release, for instance) sounds like core
> developer responsibility to me. This cannot be done in isolated
> packages; it affects many of them.
>   
So if integration is something which happens across packages, why are
you managing it in MCPackages a wholly inappropriate organisation. The
MCPackages are useful as an output of the integration process, but they
can be generated automatically. The inputs are the units of knowledge
collected in order to perform the integration, and there are several
candidate audiences for that knowledge, but you aren't capturing that
knowledge for them, you are only capturing the output of that knowledge
and even then its not organised in a useful manner.

You are also forgetting that the process of integration also effects the
700 or so loadable packages, where is the process for this?
>>> This morning I removed an obsolete test case from the trunk, along
>>> with a method. This was not really a bug, it just was one of the
>>> reasons that the bar would not go green, but in no way an indicator
>>> for some fault in the code in the image as such. I feel awkward when I
>>> read I should have reported *this* as a *bug*.
>>>
>>>       
>> It depends on what your test was for. Tests should be managed externally
>> to the image anyway, and integrated for test candidates
>>     
>
> This I agree with; and the tests repository - as kept separate from
> the trunk - is a step in that direction, right?
>   
Yes, except that the primary feature of 3.11 as planned and coded was
the reorganisation of the image into new structure of packages where the
tests and implementation were managed separately in separate package yet
alongside each other organisationally and tidily.

One process in the production of the release is deciding what structure
it should have. This process needs to happen first, now it cant be done
at all, because you have decided the structure of your packages as an
input, and we are resigned to keeping the same old mess we have had for
years.

Just throwing open a tests repository is not planning or organisation,
its just open chaos. Nor is your tests repository against any particular
release. Now if you were to say, here is a repository for working on
shared Collections for all forks and with Collections we have a tests
package, then we have a manageable unit, against which apis can be
documented and compared across forks, and plans can be made.

Keith




More information about the Squeak-dev mailing list