[oe] Bugtracker Status
Philip Balister
philip at balister.org
Fri Jan 23 01:39:22 UTC 2009
Otavio Salvador wrote:
> "Michael 'Mickey' Lauer" <mickey at 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090122/7a5b34de/attachment-0002.bin>
More information about the Openembedded-devel
mailing list