Re: [gentoo-dev] Re: Gentoo Bugday

[Pavlos Ratis]

@neddyseagoon: Yeah it would be great to have it back, I think the day
should remain as is. Every first Saturday of every month. Thanks.

@TomWij and Peter: Well guys, I think you should not expand the topic
so much, lets stay to the bugday. As I said in my first post, bugday's
goal is to close as many bugs as possible and not to create new tools.
We can create tools(small scripts) in the future that can help us
before the bugday. But in the bugday as an event we should concentrate
on closing bugs.


On Thu, Feb 28, 2013 at 3:07 AM, Tom Wijsman <TomWij@g.o> wrote:
> On Thu, 28 Feb 2013 01:20:01 +0100
> Peter Stuge <peter@×××××.se> wrote:
>
>> 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.
>
> Neither of us did suggest such thing.
>
>> > Yes, one shall not commit on packages other developers maintain
>> > without the permission to do such thing.
>>
>> This is basically stupid.
>
> But that's just the way it is, because random committing makes no sense.
>
>> 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.
>
> It works this way for packages (retirement, etc...), but for bugs this
> introduces the random committing effect; just because you keep one bug
> around for a package and fix all others doesn't mean someone else can
> suddenly come and take that bug, fix and apply it blindly.
>
>> Those who feel threatened by other people touching their bits might
>> pay more attention to bugs then.
>
> Again more easily said than done, time is limited; not every bug can be
> fixed, some require too much effort for what they are worth, ...
>
>> 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..
>
> This model has been in place for years, it's not easily changed.
>
>> > 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.
>>
>> ...
>>
>> 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.
>
> That's just moving the extra effort to the person who receives your
> patch; who now has to obtain the overlay, sync the overlay, obtain the
> file from the overlay and diff that file against his local file to
> obtain the actual patch. And if it's not done in a timely manner, too
> much may have changed already which makes generating a clean patch hard
> and therefore will need them to spent time to figure out which code
> actually belongs to the patch. Overlays weren't meant for this...
>
>> I do try to also attach fixed files, but I don't always manage.
>
> I do try to generate patches from overlays, 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).
>
> How exactly does Bugzilla show these kinds of bugs?
>
> Submitting patches or using overlays, it makes no difference.
>
> Following the bug through mail exactly doesn't show retirement, unless
> you CC yourself on a ton of bugs and want to maintain these individual
> CCs into archive folders where you look up the oldest mails (because
> not every CC is one you want to archive), and you also have to
> consider that you don't get mails for changes you commit to the bug.
> Sum that up and it's not a reliable approach, unless you write a tool.
>
>> > 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.
>
> Those bugs are often of equal priority, and I have nothing against
> that; I'm just stating that it's much harder to fix other people's
> bugs, this is due to the inefficiency that comes along, without tools
> being written to aid in this process it'll continue that way.
>
>> > > 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.
>
> "just" being the whole overlay process I outlined above? Not trivial.
>
>> 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?
>
> Still needs you to write this search query for it to become useful as
> a tool (a tool doesn't necessarily have to be a script or a program).
>
>> 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 can't find them, I don't have the right tools or search query.
>
> Will you link them all to us this Saturday on IRC? :(
>
>> Absolutely agreed! Tools are awesome and important. I just think
>> that *on* bugday everyone should be working on bugs instead.
>
> Agreed, but that's not today or tomorrow, just 4 days of a month.
>
>> > 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.
>
> Yeah, it's one more to throw on the list of things to eventually
> implement when they start to extremely bother you; maybe I should set
> up a Gentoo Project that does nothing but implement these kinds of
> tools, "which one to implement first" is then voted by all developers.
>
>> > 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.
>
> And mine was not, just in general.
>
> Although I was reading this because I might look into helping out on
> such website, later on; which you probably have figured out by now...
>
>
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@g.o
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D