1 |
Tom Wijsman wrote: |
2 |
> I am saying that working on tools that help you work on open bugs is |
3 |
> not orthogonal to fixing open bugs, it helps you fix them efficiently. |
4 |
|
5 |
Sure, but on the bugday itself it sounds on the name like the idea is |
6 |
to work on bugs with currently available tools, rather than work on |
7 |
tools to work on bugs .. some other time. |
8 |
|
9 |
|
10 |
> > Is there a rule in Gentoo that forbids a dev to fix a bug |
11 |
> > assigned to someone else? That would make absolutely no sense to |
12 |
> > me. |
13 |
> > |
14 |
> > No wonder then, that there are several bugs with no activity for |
15 |
> > months after I have committed fixed ebuilds to my overlay and |
16 |
> > mentioned that in a comment. |
17 |
> |
18 |
> Yes, one shall not commit on packages other developers maintain |
19 |
> without the permission to do such thing. |
20 |
|
21 |
This is basically stupid. |
22 |
|
23 |
Anyway, commit is one thing, but fixing bugs can be done while still |
24 |
respecting that rule. I would however make this simple suggestion: |
25 |
|
26 |
On bugdays every bugfix [optionally for bugs inactive for x days] is |
27 |
fair game for every developer to commit. |
28 |
|
29 |
Those who feel threatened by other people touching their bits might |
30 |
pay more attention to bugs then. It would also promote more |
31 |
acceptance of other fixing their stuff. I know that several (many?) |
32 |
developers give blanket permission, and I think that's good, but I |
33 |
think it's really broken that they have to at all. Back to bugday.. |
34 |
|
35 |
|
36 |
> But let's assume the horribly "attaching a patch" approach (save |
37 |
> two files, compare them, bla...)... |
38 |
|
39 |
Yes, web apps are supremely inefficient shitty tools. I'm very happy |
40 |
to be able to simply refer to my overlay when I have fixed something. |
41 |
|
42 |
I do try to also attach fixed files, but I don't always manage. |
43 |
|
44 |
|
45 |
> Can you write me a tool that shows these kinds of bugs, easily submit |
46 |
> patches to them and follow up on whether the developer commits them or |
47 |
> retires at one or another point? I don't do any of this for my bugs. |
48 |
|
49 |
Bugzilla implicitly does much of that for you already, if you tell it |
50 |
to send you email for all changes on bugs you have the raw data in |
51 |
email form, which may be easier to work with sans SQL access to the |
52 |
bugzilla database. That works really well for me to follow any bugs |
53 |
that I am interested in, and it's pretty easy to search in email and |
54 |
see what has happened when, and how much is still open (different |
55 |
folders). |
56 |
|
57 |
Submitting patches, no I think that's too broken on the web, and that |
58 |
something more powerful like an overlay could be used instead - at |
59 |
the very least for fixes from developers. |
60 |
|
61 |
|
62 |
> I could state that working on bugs assigned to someone else is |
63 |
> orthogonal to fixing your own bugs. |
64 |
|
65 |
Sure - but if all one's own bugs are low priority perhaps it's more |
66 |
useful on bugday to work on bugs assigned to someone else, if they |
67 |
aren't doing it themselves. |
68 |
|
69 |
|
70 |
> > He has become a developer so why would he not be able to take |
71 |
> > neccessary action to close bugs, even if they haven't been assigned |
72 |
> > to him? |
73 |
> |
74 |
> Because it isn't as simple as you make it seem like, as stated above. |
75 |
|
76 |
For several bugs that I have fixed, it is precisely that simple. |
77 |
Fixes have been ready for months and just need to be committed. |
78 |
I'd dare to call it outright trivial. |
79 |
|
80 |
They still aren't committed. |
81 |
|
82 |
Finding them easily? Well maybe a search query that orders by last |
83 |
activity weighted by severity, number of attachments and fulltext |
84 |
search for "fixed" would be a start? I guess that's easy to do even |
85 |
in bugzilla's web interface? |
86 |
|
87 |
|
88 |
> > - But Peter, you say, don't you see - that would lead to more fixed |
89 |
> > bugs! |
90 |
> > |
91 |
> > Orly? How is that bad? |
92 |
> |
93 |
> Y u no serious? U mad? |
94 |
|
95 |
Not mat, I am being serious - I guess that the uncommitted fixes |
96 |
mean lack of attention to bugs, which I completely understand. I |
97 |
further guess that the bugday is an initiative to attend to bugs. |
98 |
|
99 |
So any developer who wants to help could close bugs by comitting |
100 |
fixes from others, fixes that are already in bugzilla. I guess the |
101 |
few bugs that I have done this for are not unique in Gentoo's |
102 |
bugzilla, likely there are lots of other bugs just like mine, where |
103 |
users have contributed fixes for stuff that they have run into and it |
104 |
still hasn't gotten committed, nor reviewed. At least one of "my" |
105 |
bugs is even UNCONFIRMED. It's almost mocking the entire bugzilla. :) |
106 |
|
107 |
|
108 |
> > (I'm obviously assuming that all developers (but not infra) are |
109 |
> > equally competent, since that's the model taught by recruitment.) |
110 |
> |
111 |
> Competence is irrelevant to this discussion, competency is to be |
112 |
> assumed. |
113 |
|
114 |
I agree that it is to be assumed, but I think it is relevant because |
115 |
I believe that fear of incompetence is the reason why developers feel |
116 |
threatened by commits from others, so it supports the idea that at |
117 |
the very least on bugday it would be fine for everyone to commit |
118 |
everything. (Again, I am assuming that all fixes are correct.) |
119 |
|
120 |
|
121 |
> Though, since you want to discuss this; note that with the |
122 |
> right tools incompetent developers can become more competent, |
123 |
> instead of having no clue where to start they can efficiently |
124 |
> start on something right away and finish it in a timely matter. |
125 |
|
126 |
Absolutely agreed! Tools are awesome and important. I just think |
127 |
that *on* bugday everyone should be working on bugs instead. |
128 |
|
129 |
|
130 |
> > > short term |
131 |
> > .. |
132 |
> > > long term |
133 |
> > |
134 |
> > Yes, life is tradeoff. In my experience development of tools is |
135 |
> > rather a long term thing, while a day of working on bugs is more |
136 |
> > short term. A day short, to be exact. :) |
137 |
> |
138 |
> What experience are you even talking about? |
139 |
|
140 |
Decades of developing tools and working on bugs. |
141 |
|
142 |
|
143 |
> daily Gentoo Dev process? |
144 |
|
145 |
How could I, I'm not a dev, remember? |
146 |
|
147 |
And from the outside, becoming one doesn't look super attractive.. |
148 |
|
149 |
|
150 |
> > If there are numerous unactionable bugs then perhaps skip them on |
151 |
> > that day, and work on shiny bulk processing tools the next day. |
152 |
> |
153 |
> So, we need another tool to mark and bulk process unactionable bugs! Or |
154 |
> at least plan and write the searches for our lovely Bugzilla to do so, |
155 |
> oh, and also CC a ton of people with this madness while we're at it. |
156 |
|
157 |
I guess the low level stuff is there - bugzilla surely has some RPC |
158 |
API, and someone mentioned pybugz which is perhaps a little bit |
159 |
higher level. So maybe that is already possible. |
160 |
|
161 |
|
162 |
> It's only a day short. The other six days are free to work on tools... |
163 |
|
164 |
I think we are in agreement actually - my point is about the bugday. |
165 |
|
166 |
|
167 |
Thanks! |
168 |
|
169 |
//Peter |