public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: Bug tracking
Date: Mon, 29 Mar 2021 10:07:48 +0200	[thread overview]
Message-ID: <1768455.1617005268@gemini.denx.de> (raw)
In-Reply-To: <20210325193843.qniaryw2xxgkzqjf@ti.com>

Dear Pratyush,

In message <20210325193843.qniaryw2xxgkzqjf@ti.com> you wrote:
>
> You would need people to maintain the bugs that are reported in the 
> tracker. Asking for clear, reproducible info, closing duplicates or old 
> bugs, etc. Then you need people dedicated to fixing those bugs. Sure, 
> some can be taken up by subsystem maintainers or active devs, but what 
> to do with the ones that aren't?
>
> My point is, having a bug tracker needs volunteers to help maintain it. 
> Otherwise it would not be very useful and important bugs would get 
> drowned in the noise or be left stale. We can experiment with it but we 
> need to keep in mind the extra effort required.

I think it is worth to start such an experiment.  Eventually there
are people out there who don;t have experience, time and resources
for bigger development tasks, but who might help out with smaller
tasks like bug fixing.

> > Another option is to use source.denx.de but that would require
> > allowing anyone to register so is probably a non-starter.
>
> Honestly, source.denx.de makes the most sense to me. I would expect the 
> Gitlab instance where the repo is hosted to also be where the bug 
> tracker is hosted. Makes it much easier to find.

I fully agree here; this is also my suggestion.

> But if allowing anyone to register is a no-go, then I would prefer 
> something decentralized/non-proprietary to keep the project independent 
> of the host. But people generally aren't very enthusiastic about those 
> because the proprietary solutions are just so easy to use...

It is not a strict no-go, but we will have to think about some form
of rate limiting - either in form of approvals (which would add to
our work load) or allowing only OAUTH logins from other platforms as
it's done for example here [1].

[1]  https://gitlab.gnome.org/users/sign_in

And we should make sure that only bugs against mainline versions can
be reported - it makes no sense to collect bug information for
out-of-tree code where we might not even have access to.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the realm of scientific observation, luck is granted only to those
who are prepared.                                     - Louis Pasteur

      reply	other threads:[~2021-03-29  8:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 22:14 Bug tracking Simon Glass
2021-03-25  7:50 ` Heinrich Schuchardt
2021-03-25  8:14 ` Jagan Teki
2021-03-25 19:38 ` Pratyush Yadav
2021-03-29  8:07   ` Wolfgang Denk [this message]

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=1768455.1617005268@gemini.denx.de \
    --to=wd@denx.de \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox