1 |
On Thu, 28 Feb 2013 01:20:01 +0100 |
2 |
Peter Stuge <peter@×××××.se> wrote: |
3 |
|
4 |
> Sure, but on the bugday itself it sounds on the name like the idea is |
5 |
> to work on bugs with currently available tools, rather than work on |
6 |
> tools to work on bugs .. some other time. |
7 |
|
8 |
Neither of us did suggest such thing. |
9 |
|
10 |
> > Yes, one shall not commit on packages other developers maintain |
11 |
> > without the permission to do such thing. |
12 |
> |
13 |
> This is basically stupid. |
14 |
|
15 |
But that's just the way it is, because random committing makes no sense. |
16 |
|
17 |
> Anyway, commit is one thing, but fixing bugs can be done while still |
18 |
> respecting that rule. I would however make this simple suggestion: |
19 |
> |
20 |
> On bugdays every bugfix [optionally for bugs inactive for x days] is |
21 |
> fair game for every developer to commit. |
22 |
|
23 |
It works this way for packages (retirement, etc...), but for bugs this |
24 |
introduces the random committing effect; just because you keep one bug |
25 |
around for a package and fix all others doesn't mean someone else can |
26 |
suddenly come and take that bug, fix and apply it blindly. |
27 |
|
28 |
> Those who feel threatened by other people touching their bits might |
29 |
> pay more attention to bugs then. |
30 |
|
31 |
Again more easily said than done, time is limited; not every bug can be |
32 |
fixed, some require too much effort for what they are worth, ... |
33 |
|
34 |
> It would also promote more acceptance of other fixing their stuff. I |
35 |
> know that several (many?) developers give blanket permission, and I |
36 |
> think that's good, but I think it's really broken that they have to |
37 |
> at all. Back to bugday.. |
38 |
|
39 |
This model has been in place for years, it's not easily changed. |
40 |
|
41 |
> > But let's assume the horribly "attaching a patch" approach (save |
42 |
> > two files, compare them, bla...)... |
43 |
> |
44 |
> Yes, web apps are supremely inefficient shitty tools. I'm very happy |
45 |
> to be able to simply refer to my overlay when I have fixed something. |
46 |
> |
47 |
> ... |
48 |
> |
49 |
> Submitting patches, no I think that's too broken on the web, and that |
50 |
> something more powerful like an overlay could be used instead - at |
51 |
> the very least for fixes from developers. |
52 |
|
53 |
That's just moving the extra effort to the person who receives your |
54 |
patch; who now has to obtain the overlay, sync the overlay, obtain the |
55 |
file from the overlay and diff that file against his local file to |
56 |
obtain the actual patch. And if it's not done in a timely manner, too |
57 |
much may have changed already which makes generating a clean patch hard |
58 |
and therefore will need them to spent time to figure out which code |
59 |
actually belongs to the patch. Overlays weren't meant for this... |
60 |
|
61 |
> I do try to also attach fixed files, but I don't always manage. |
62 |
|
63 |
I do try to generate patches from overlays, but I don't always manage. |
64 |
|
65 |
> > Can you write me a tool that shows these kinds of bugs, easily |
66 |
> > submit patches to them and follow up on whether the developer |
67 |
> > commits them or retires at one or another point? I don't do any of |
68 |
> > this for my bugs. |
69 |
> |
70 |
> Bugzilla implicitly does much of that for you already, if you tell it |
71 |
> to send you email for all changes on bugs you have the raw data in |
72 |
> email form, which may be easier to work with sans SQL access to the |
73 |
> bugzilla database. That works really well for me to follow any bugs |
74 |
> that I am interested in, and it's pretty easy to search in email and |
75 |
> see what has happened when, and how much is still open (different |
76 |
> folders). |
77 |
|
78 |
How exactly does Bugzilla show these kinds of bugs? |
79 |
|
80 |
Submitting patches or using overlays, it makes no difference. |
81 |
|
82 |
Following the bug through mail exactly doesn't show retirement, unless |
83 |
you CC yourself on a ton of bugs and want to maintain these individual |
84 |
CCs into archive folders where you look up the oldest mails (because |
85 |
not every CC is one you want to archive), and you also have to |
86 |
consider that you don't get mails for changes you commit to the bug. |
87 |
Sum that up and it's not a reliable approach, unless you write a tool. |
88 |
|
89 |
> > I could state that working on bugs assigned to someone else is |
90 |
> > orthogonal to fixing your own bugs. |
91 |
> |
92 |
> Sure - but if all one's own bugs are low priority perhaps it's more |
93 |
> useful on bugday to work on bugs assigned to someone else, if they |
94 |
> aren't doing it themselves. |
95 |
|
96 |
Those bugs are often of equal priority, and I have nothing against |
97 |
that; I'm just stating that it's much harder to fix other people's |
98 |
bugs, this is due to the inefficiency that comes along, without tools |
99 |
being written to aid in this process it'll continue that way. |
100 |
|
101 |
> > > He has become a developer so why would he not be able to take |
102 |
> > > neccessary action to close bugs, even if they haven't been |
103 |
> > > assigned to him? |
104 |
> > |
105 |
> > Because it isn't as simple as you make it seem like, as stated |
106 |
> > above. |
107 |
> |
108 |
> For several bugs that I have fixed, it is precisely that simple. |
109 |
> Fixes have been ready for months and just need to be committed. |
110 |
> I'd dare to call it outright trivial. |
111 |
> |
112 |
> They still aren't committed. |
113 |
|
114 |
"just" being the whole overlay process I outlined above? Not trivial. |
115 |
|
116 |
> Finding them easily? Well maybe a search query that orders by last |
117 |
> activity weighted by severity, number of attachments and fulltext |
118 |
> search for "fixed" would be a start? I guess that's easy to do even |
119 |
> in bugzilla's web interface? |
120 |
|
121 |
Still needs you to write this search query for it to become useful as |
122 |
a tool (a tool doesn't necessarily have to be a script or a program). |
123 |
|
124 |
> So any developer who wants to help could close bugs by comitting |
125 |
> fixes from others, fixes that are already in bugzilla. I guess the |
126 |
> few bugs that I have done this for are not unique in Gentoo's |
127 |
> bugzilla, likely there are lots of other bugs just like mine, where |
128 |
> users have contributed fixes for stuff that they have run into and it |
129 |
> still hasn't gotten committed, nor reviewed. At least one of "my" |
130 |
> bugs is even UNCONFIRMED. It's almost mocking the entire bugzilla. :) |
131 |
|
132 |
I can't find them, I don't have the right tools or search query. |
133 |
|
134 |
Will you link them all to us this Saturday on IRC? :( |
135 |
|
136 |
> Absolutely agreed! Tools are awesome and important. I just think |
137 |
> that *on* bugday everyone should be working on bugs instead. |
138 |
|
139 |
Agreed, but that's not today or tomorrow, just 4 days of a month. |
140 |
|
141 |
> > So, we need another tool to mark and bulk process unactionable |
142 |
> > bugs! Or at least plan and write the searches for our lovely |
143 |
> > Bugzilla to do so, oh, and also CC a ton of people with this |
144 |
> > madness while we're at it. |
145 |
> |
146 |
> I guess the low level stuff is there - bugzilla surely has some RPC |
147 |
> API, and someone mentioned pybugz which is perhaps a little bit |
148 |
> higher level. So maybe that is already possible. |
149 |
|
150 |
Yeah, it's one more to throw on the list of things to eventually |
151 |
implement when they start to extremely bother you; maybe I should set |
152 |
up a Gentoo Project that does nothing but implement these kinds of |
153 |
tools, "which one to implement first" is then voted by all developers. |
154 |
|
155 |
> > It's only a day short. The other six days are free to work on |
156 |
> > tools... |
157 |
> |
158 |
> I think we are in agreement actually - my point is about the bugday. |
159 |
|
160 |
And mine was not, just in general. |
161 |
|
162 |
Although I was reading this because I might look into helping out on |
163 |
such website, later on; which you probably have figured out by now... |
164 |
|
165 |
|
166 |
With kind regards, |
167 |
|
168 |
Tom Wijsman (TomWij) |
169 |
Gentoo Developer |
170 |
|
171 |
E-mail address : TomWij@g.o |
172 |
GPG Public Key : 6D34E57D |
173 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |