| 1 |
W dniu czw, 14.12.2017 o godzinie 14∶56 +0100, użytkownik Fabian Groffen |
| 2 |
napisał: |
| 3 |
> On 14-12-2017 14:41:17 +0100, Michał Górny wrote: |
| 4 |
> > W dniu czw, 14.12.2017 o godzinie 13∶56 +0100, użytkownik Fabian Groffen |
| 5 |
> > napisał: |
| 6 |
> > > On 14-12-2017 13:39:18 +0100, Michał Górny wrote: |
| 7 |
> > > > Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen <grobian@g.o> napisał(a): |
| 8 |
> > > > > Can we make it a policy to list /what/ QA issues are the justification |
| 9 |
> > > > > for commits like these? A description in the commit message would be |
| 10 |
> > > > > preferred, but a pointer to a location where said issues can be found |
| 11 |
> > > > > would do too. |
| 12 |
> > > > |
| 13 |
> > > > Maintainer-needed is reason enough. If somebody couldn't be bothered to maintain what he committed, why should we bother to list the issues? |
| 14 |
> > > > |
| 15 |
> > > > Using repoman and looking at CI mails is also a good idea. |
| 16 |
> > > |
| 17 |
> > > Obviously for me to learn something, I won't/can't use repoman here. So |
| 18 |
> > > a pointer to said CI mails from the message of the QA commit would be |
| 19 |
> > > nice. |
| 20 |
> > |
| 21 |
> > Last I checked, I wasn't personally responsible for teaching people |
| 22 |
> > ebuild writing 101 while on phone. But here you go (in malformed paste |
| 23 |
> > of ebuild below). |
| 24 |
> |
| 25 |
> You simply replied, and therefore took ownership from QA point of view. |
| 26 |
> I can't help it you do that whilst on the phone. In fact, this is |
| 27 |
> email, so being on the phone is not a good reason to be vague and avoid |
| 28 |
> answering questions in the first place. |
| 29 |
> |
| 30 |
> [snip issues] |
| 31 |
> |
| 32 |
> Thanks, much appreciated. I'm completely convinced now. I'm referring |
| 33 |
> back to my earlier suggestion to include such list or the type of issues |
| 34 |
> found when a drastic commit like the one we discuss is done under the QA |
| 35 |
> flag. It's good to know that the QA issue complaint was valid, and |
| 36 |
> improvements can be made. |
| 37 |
> |
| 38 |
> A final suggestion is to talk to the committer before taking such |
| 39 |
> drastic actions, in a situation where our users aren't endangered. As |
| 40 |
> this one is, in my opinion. |
| 41 |
> There is more problematic stuff in the tree, but teach a man to fish ... |
| 42 |
> next time the problems may be avoided. |
| 43 |
> |
| 44 |
|
| 45 |
The point of taking this 'drastic' action is to prevent people from |
| 46 |
starting to depend on the package, and therefore blocking its removal. |
| 47 |
In this case, the revert was already too late. |
| 48 |
|
| 49 |
|
| 50 |
-- |
| 51 |
Best regards, |
| 52 |
Michał Górny |
Archives