W dniu czw, 14.12.2017 o godzinie 14∶56 +0100, użytkownik Fabian Groffen
napisał:
> On 14-12-2017 14:41:17 +0100, Michał Górny wrote:
> > W dniu czw, 14.12.2017 o godzinie 13∶56 +0100, użytkownik Fabian Groffen
> > napisał:
> > > On 14-12-2017 13:39:18 +0100, Michał Górny wrote:
> > > > Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen <grob...@gentoo.org> 
> > > > napisał(a):
> > > > > Can we make it a policy to list /what/ QA issues are the justification
> > > > > for commits like these?  A description in the commit message would be
> > > > > preferred, but a pointer to a location where said issues can be found
> > > > > would do too.
> > > > 
> > > > Maintainer-needed is reason enough. If somebody couldn't be bothered to 
> > > > maintain what he committed, why should we bother to list the issues?
> > > > 
> > > > Using repoman and looking at CI mails is also a good idea.
> > > 
> > > Obviously for me to learn something, I won't/can't use repoman here.  So
> > > a pointer to said CI mails from the message of the QA commit would be
> > > nice.
> > 
> > Last I checked, I wasn't personally responsible for teaching people
> > ebuild writing 101 while on phone. But here you go (in malformed paste
> > of ebuild below).
> 
> You simply replied, and therefore took ownership from QA point of view.
> I can't help it you do that whilst on the phone.  In fact, this is
> email, so being on the phone is not a good reason to be vague and avoid
> answering questions in the first place.
> 
> [snip issues]
> 
> Thanks, much appreciated.  I'm completely convinced now.  I'm referring
> back to my earlier suggestion to include such list or the type of issues
> found when a drastic commit like the one we discuss is done under the QA
> flag.  It's good to know that the QA issue complaint was valid, and
> improvements can be made.
> 
> A final suggestion is to talk to the committer before taking such
> drastic actions, in a situation where our users aren't endangered.  As
> this one is, in my opinion.
> There is more problematic stuff in the tree, but teach a man to fish ...
> next time the problems may be avoided.
> 

The point of taking this 'drastic' action is to prevent people from
starting to depend on the package, and therefore blocking its removal.
In this case, the revert was already too late.


-- 
Best regards,
Michał Górny


Reply via email to