All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Mitchell <ml@communistcode.co.uk>
To: openembedded-core@lists.openembedded.org
Subject: Re: bug scrub - RFC
Date: Thu, 09 Jan 2014 10:56:53 +0000	[thread overview]
Message-ID: <52CE8075.8040700@communistcode.co.uk> (raw)
In-Reply-To: <52CDDD3E.7040508@linaro.org>

On 08/01/14 23:20, Trevor Woerner wrote:
> Hi everyone,
> 
> This is a "Request For Comments" email regarding a "bug scrub" party the
> OE TSC would like to hold.
> 
> 
> background:
> It has been noticed that the number of bugs in the bugzilla[1] has been
> climbing; it would be nice to hold a "bug scrub" event to raise
> awareness of the bugzilla and hopefully get some issues resolved.
> 
> 
> questions:
> 1) Currently it has been suggested this should be a 2-day event, should
> these two days be during the week or over a weekend? In either case,
> which 2 days?
> 

If it's two days long then why don't you do the best of both worlds and
have a Friday/Saturday or Sunday/Monday combination?

> 2) Since this is an OE event, should it focus only on OE bugs[2], or
> should it be generalized for any bug?

I don't think we should be limiting people to what they can work on
while "participating".

> 
> 3) Should we create a sign-up sheet (wiki) to keep track of who is
> participating, and which issues are being looked at by whom?
> 
> (anything else?)

I think maybe a "I will be there at some point for some amount of time"
column would be good, and maybe a place to register interest for certain
bugs or areas of code that need improvement.

> 
> 
> notes:
> 1) If you or the company for which you work uses OE/Yocto, please
> consider making this a company event and having/allowing the engineers
> (to) participate.
> 
> 2) Even if you're not a recipe-, or a build-, or a python-wizard there
> are still many things you can do to contribute. Being able to reproduce
> a bug or reporting that a bug can't be reproduced can sometimes be quite
> helpful (sometimes this points to a host issue or to a bug's description
> not being descriptive enough). Sometimes a bug is stuck in the "needs
> info" stage which maybe you can provide.

People with different environments is always useful, either bleeding
edge or "very stable". Variety is the spice of life ;)

> 
> 3) Can anyone think of way to help "get the word out"?
> 
> 4) It would be cool to be able to provide incentives to help people get
> interested and contributing to knocking some bugs around. So if anyone
> (*cough* Intel) has any neat hardware (*cough* Galileo, Edison) they
> could offer as an incentive (or, conversely, if there's a board you'd
> like to see Yocto target) please see about making that happen.
> 

A unified effort towards a "new trendy" board would be a fun goal, but I
worry that hardware teething issues would then eat up run of the mill
bug fixing time, handouts for participation however, (bug fixed/reviewed
by/tested by) would be a great idea.

> 
> Thanks and best regards,
>     Trevor
> 
> 
> 
> [1] https://bugzilla.yoctoproject.org
> [2]
> https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&classification=Build%20System%20%26%20Metadata&list_id=156074&product=OE-Core&query_format=advanced&resolution=---&order=bug_id%20DESC&query_based_on=
> 

Cheers,

-- 
  Jack Mitchell (jack@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 


  reply	other threads:[~2014-01-09 10:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 23:20 bug scrub - RFC Trevor Woerner
2014-01-09 10:56 ` Jack Mitchell [this message]
2014-01-09 15:07   ` Trevor Woerner
2014-01-09 15:34     ` Otavio Salvador
2014-01-09 15:38       ` Trevor Woerner
2014-01-10  2:47     ` Philip Balister

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52CE8075.8040700@communistcode.co.uk \
    --to=ml@communistcode.co.uk \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.