On 06-08-10 17:19 +0100, David Bisset wrote:
>
> >> a) Boards and software "chunks" need to be products.
> >> Bflash
> >> Balloon2
> >> Balloon3
> >> FPGA/CPLD
> >> Command Line
> >> JTAG Interface
> >> Other Devices
> >> NOR Device Interface
> >> IO Interface
>
> >This seems a lot of components for a relatively small bit of software.
>
> Agreed my original e-mail was scanty on explanation. OK so here is some
> justification for the list.
>
> Firstly my assumption is to bunch bugs wherever possible from a user
> perspective (as opposed to a code perspective) this is so that we don't
> expect someone reporting a bug to have intimate knowledge of the system and
> its construction, and secondly so that when we change the structure we can
> keep the outstanding bugs, and when we add functionality that the user sees
> we add a category to the component list.
>
> Therefore the above list of components is a user centric view of bflash
> operation. These help to narrow down the search for bugs if you think you
> have spotted a problem and you want to see if it has been reported
We are certainly in agreement on the principles.
I still think most users would have some difficulty dividing their use
of bflash up into such small aspects (they could manage 'programming
the FPGA' and 'programming the bootldr', and 'loon2/3' but more is
asking for a high level of understanding/familiarity. I think what you
have actually described is a developers-view of the software
described in functional terms :-)
Anyway. At least I now understand your categories, and they are useful
from a development POV even if the users don't file things in the
right component, so I've updated bugzilla accordingly. We'll see how
it works out in practice.
> Balloon2/3 are there so that bugs that relate specifically to bflash on each
> of these machine types can be recorded. There is quite a bit of platform
> specific data in bflash and bugs could crop up differently between the two
> platforms. It can't be related to the product Balloon and its version number
> because there isn't a cross linking facility. (At least I havn't spotted
> one). We could simply combine these as "platform" however it would be
> important to know which platform caused the problem.
You can't specify more than one 'product' (SFAIK), but you can specify
a 'platform' for each bug. So I've added a selection of balloon
types to the platform list. I'll try and find a place to change the
template and remind people to fill this in rather than ignore it like
they probably do on other bugzillas (because it is always 'PC').
I've included 'balloon2' and 'balloon3' for people who don't know
exactly what build/pcb/flavour they have. A definitive list of
balloon2 builds/pcbs in the wild would be useful...
> FPGA/CPLD relates to future functions for bflash so could be removed for
> now.
Can it not program them already? Wasn't that part of the point of
writing it? I suspect I misunderstand.
> >> Base Modules (PCMCIA, USB Ethernet, etc)
>
> >I've put this under kernel
>
> Modules are delivered in a separate way to the kernel and are likely to be
> maintained in a different way by different people. I think they ought to be
> a separate category. Even though some modules will end up in the kernel.
Only because our current distro-production method is a bit crap.
modules should be built as part of the kernel. Doing anything else is
a bad idea, and asking for trouble. Perhaps they deserve a separate
catgory but I'm going to resist a bit longer (until there is some
clear need).
> PCB/schematic stuff probably ought to come to me.
OK, changed.
> I'd also like to suggest that we use Bugzilla as the means of capturing user
> suggestions for improvements. The easiest way of doing this is to add a
> "suggestion" component to each product. (Other bug reporting systems have
> this as a "type" of bug).
Bugzilla has an 'enhancement' bug type as standard, which is clearly
for this purpose. We could change the name or leave it as 'bugzilla
standard'. I have currently left it as whilst I prefer 'wishlist' or
'suggestion' it seems slightly gratuitous to change it - I think it's
clear enough.
> Once this discussion has settled I'll enter all the known P2 hardware bugs.
OK. I've now fixed the email non-delivery so bugzilla can hassle us
all about new bugs and un-looked-at bugs after 7 days.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://wookware.org/
(text/plain)