public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Peter Stuge <peter@stuge.se>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: Gentoo Bugday
Date: Thu, 28 Feb 2013 01:20:01 +0100	[thread overview]
Message-ID: <20130228002001.17353.qmail@stuge.se> (raw)
In-Reply-To: <20130228000458.350d8fd4@gentoo.org>

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

Tom Wijsman wrote:
> I am saying that working on tools that help you work on open bugs is
> not orthogonal to fixing open bugs, it helps you fix them efficiently.

Sure, but on the bugday itself it sounds on the name like the idea is
to work on bugs with currently available tools, rather than work on
tools to work on bugs .. some other time.


> > Is there a rule in Gentoo that forbids a dev to fix a bug
> > assigned to someone else? That would make absolutely no sense to
> > me.
> >
> > No wonder then, that there are several bugs with no activity for
> > months after I have committed fixed ebuilds to my overlay and
> > mentioned that in a comment.
> 
> Yes, one shall not commit on packages other developers maintain
> without the permission to do such thing.

This is basically stupid.

Anyway, commit is one thing, but fixing bugs can be done while still
respecting that rule. I would however make this simple suggestion:

On bugdays every bugfix [optionally for bugs inactive for x days] is
fair game for every developer to commit.

Those who feel threatened by other people touching their bits might
pay more attention to bugs then. It would also promote more
acceptance of other fixing their stuff. I know that several (many?)
developers give blanket permission, and I think that's good, but I
think it's really broken that they have to at all. Back to bugday..


> But let's assume the horribly "attaching a patch" approach (save
> two files, compare them, bla...)...

Yes, web apps are supremely inefficient shitty tools. I'm very happy
to be able to simply refer to my overlay when I have fixed something.

I do try to also attach fixed files, but I don't always manage.


> Can you write me a tool that shows these kinds of bugs, easily submit
> patches to them and follow up on whether the developer commits them or
> retires at one or another point? I don't do any of this for my bugs.

Bugzilla implicitly does much of that for you already, if you tell it
to send you email for all changes on bugs you have the raw data in
email form, which may be easier to work with sans SQL access to the
bugzilla database. That works really well for me to follow any bugs
that I am interested in, and it's pretty easy to search in email and
see what has happened when, and how much is still open (different
folders).

Submitting patches, no I think that's too broken on the web, and that
something more powerful like an overlay could be used instead - at
the very least for fixes from developers.


> I could state that working on bugs assigned to someone else is
> orthogonal to fixing your own bugs.

Sure - but if all one's own bugs are low priority perhaps it's more
useful on bugday to work on bugs assigned to someone else, if they
aren't doing it themselves.


> > He has become a developer so why would he not be able to take
> > neccessary action to close bugs, even if they haven't been assigned
> > to him?
> 
> Because it isn't as simple as you make it seem like, as stated above.

For several bugs that I have fixed, it is precisely that simple.
Fixes have been ready for months and just need to be committed.
I'd dare to call it outright trivial.

They still aren't committed.

Finding them easily? Well maybe a search query that orders by last
activity weighted by severity, number of attachments and fulltext
search for "fixed" would be a start? I guess that's easy to do even
in bugzilla's web interface?


> > - But Peter, you say, don't you see - that would lead to more fixed
> > bugs!
> > 
> > Orly? How is that bad?
> 
> Y u no serious? U mad?

Not mat, I am being serious - I guess that the uncommitted fixes
mean lack of attention to bugs, which I completely understand. I
further guess that the bugday is an initiative to attend to bugs.

So any developer who wants to help could close bugs by comitting
fixes from others, fixes that are already in bugzilla. I guess the
few bugs that I have done this for are not unique in Gentoo's
bugzilla, likely there are lots of other bugs just like mine, where
users have contributed fixes for stuff that they have run into and it
still hasn't gotten committed, nor reviewed. At least one of "my"
bugs is even UNCONFIRMED. It's almost mocking the entire bugzilla. :)


> > (I'm obviously assuming that all developers (but not infra) are
> > equally competent, since that's the model taught by recruitment.)
> 
> Competence is irrelevant to this discussion, competency is to be
> assumed.

I agree that it is to be assumed, but I think it is relevant because
I believe that fear of incompetence is the reason why developers feel
threatened by commits from others, so it supports the idea that at
the very least on bugday it would be fine for everyone to commit
everything. (Again, I am assuming that all fixes are correct.)


> Though, since you want to discuss this; note that with the
> right tools incompetent developers can become more competent,
> instead of having no clue where to start they can efficiently
> start on something right away and finish it in a timely matter.

Absolutely agreed! Tools are awesome and important. I just think
that *on* bugday everyone should be working on bugs instead.


> > > short term
> > ..
> > > long term
> > 
> > Yes, life is tradeoff. In my experience development of tools is
> > rather a long term thing, while a day of working on bugs is more
> > short term. A day short, to be exact. :)
> 
> What experience are you even talking about?

Decades of developing tools and working on bugs.


> daily Gentoo Dev process?

How could I, I'm not a dev, remember?

And from the outside, becoming one doesn't look super attractive..


> > If there are numerous unactionable bugs then perhaps skip them on
> > that day, and work on shiny bulk processing tools the next day.
> 
> So, we need another tool to mark and bulk process unactionable bugs! Or
> at least plan and write the searches for our lovely Bugzilla to do so,
> oh, and also CC a ton of people with this madness while we're at it.

I guess the low level stuff is there - bugzilla surely has some RPC
API, and someone mentioned pybugz which is perhaps a little bit
higher level. So maybe that is already possible.


> It's only a day short. The other six days are free to work on tools...

I think we are in agreement actually - my point is about the bugday.


Thanks!

//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2013-02-28  0:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-27  0:39 [gentoo-dev] Gentoo Bugday Pavlos Ratis
2013-02-27  2:01 ` "Paweł Hajdan, Jr."
2013-02-27  3:14 ` [gentoo-dev] " Michael Palimaka
2013-02-27  6:28   ` Alec Warner
2013-02-27 10:19     ` Theo Chatzimichos
2013-02-27 18:57       ` Pavlos Ratis
2013-02-27 19:00         ` Peter Stuge
2013-02-27 19:40           ` Tom Wijsman
2013-02-27 21:30             ` Peter Stuge
2013-02-27 23:04               ` Tom Wijsman
2013-02-28  0:20                 ` Peter Stuge [this message]
2013-02-28  1:07                   ` Tom Wijsman
2013-02-28  2:14                     ` Pavlos Ratis
2013-02-28 16:31                       ` Roy Bamford
2013-02-28 11:33               ` Sergey Popov
2013-02-28 15:47                 ` Pavlos Ratis
2013-02-27  9:07 ` [gentoo-dev] " Alexander Berntsen
2013-02-27 15:07   ` Peter Stuge
2013-02-27 19:12 ` Roy Bamford

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=20130228002001.17353.qmail@stuge.se \
    --to=peter@stuge.se \
    --cc=gentoo-dev@lists.gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox