Re: Bugtracker Status

[Philip Balister <philip@balister.org>]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

Otavio Salvador wrote:
> "Michael 'Mickey' Lauer" <mickey@vanille-media.de> writes:
> 
>> Hi guys,
>>
>> we have 1141 open bugs in the bugtracker, a couple of hundreds from ancient 
>> autobuilder builds, some more hundreds application specific bugs, and then 
>> some actual ones.
>>
>> I think there are two ways to deal with the mess:
>>
>> 1.) Officially close the bugtracker down.
>>
>> 2.) Attack the situation.
>>
>> I'm fine with either way, though if we'd go for 2.), I'd propose:
>>
>> 2.1.) Removing all autobuilder bugs completely (how can we script that?) and 
>> stop autobuilder automatically adding bugs. It was a great idea, but it 
>> didn't work out. We do not have enough manpower and it just messes up the 
>> bugtracker.
>> 2.2.) Remove all software specific bugs that have an upstream and are not 
>> distribution-relevant, such as GPE, Opie, Kernel, etc.

Can we at least markbugs that are upstream issues in such a way that we 
can track when they are fixed upstream?

>> 2.3.) Reinstate the monthly bug squashing weekends.

Dedicated bug squashing periods are good!

>>
>> Opinions?
> 
> I propose to change the workflow a bit (and reuse few points you've proposed):
> 
>  1. stop using bugtracker to handle patches
>  2. use mailing list to handle patches (comments bellow)
>  3. drop autobuilder bug reporting (comments bellow)

Basically, I agree with Otavio.

What about a new list for patches and discussion? I don't know if this 
is a good idea though.

I think the tinderbox work may be a better way of tracking auto-builder 
issues.

Philip



> 
> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
> new in the OE environment to comment about them so let me comment
> about my points:
> 
>  1 and 2:
> 
>  We're trying to get more people to review the changes to be done in
>  OE dev tree and bugzilla UI is horrible and difficult to use (at
>  least for me). Most people ends up redoing someone else patch since
>  we don't watch carefully the bugtrack.
> 
>  I propose we move to mailing list reviewing process mostly like Linux
>  kernel does. We can use PatchWork (http://ozlabs.org/~jk/projects/patchwork/)
>  tool to make our life easier. I see some pros for that:
> 
>   . people will get more review into the patches
>   . people will be aware of ongoing work and what is being prepared to
>     be merged
>   . less forgotten patches
>   . less duplicated work
> 
>  I also see a single con for that:
> 
>   . more mailing list traffic
> 
>  3:
> 
>  Instead of reporting bugs, we could mail mailing list with the
>  failure and link a log for someone to take a look. It makes us to
>  worry more about the change since if we break something _everyone_
>  we'll know it :-)
> 
> My 2c :P
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]