bug triaging (was: Re: svn commit: r331728 - in stable/11/etc: . rc.d)

[Marcelo Araujo]

2018-03-30 11:04 GMT+08:00 Mark Linimon <linimon at lonesome.com>:

> This is addressed to developers in general, not just rgrimes, but he
> made the comments, so ...
>
> On Thu, Mar 29, 2018 at 09:33:44AM -0700, Rodney W. Grimes wrote:
> > It seems that the Phabricator review system is somewhat dysfunctional
> > in that actual review is only happening in some cases.  Some people
> > have even stated they flat out hate it.
>
> I will have to state as someone who has spent a great deal of time on
> classifying/triaging bug reports in this project, that the attitude
> that some developers have that "I am not going to use tool xyz" is both
> disheartening and demotivating.  I find it difficult to remember when I
> triage: who it is that will or will not use which tool?
>
> Here: the plain facts are that our clearance rate for Phabriactor reviews,
> for both src and doc, are far better than for Bugzilla.  For ports, the
> opposite is true.  These are just facts.
>
> By and large IMHO phab is a plus.  (Disclaimer: I personally hate the
> web interface, it makes me want to pull out my few remaining hairs.)
> But I do not see it going away.  Nor, do I see bugzilla going away.
> Some people like the workflow of the one, some like the other.
>
> > The problem is that most people are not notified that a review
> > of a change is even in process until the commit lands, this is
> > not a functional communications system.
>
> But many developers also ignore bug reports coming through Bugzilla,
> echoed on the mailing lists.  What is your constructive suggestion
> here?  Do we make subscribing to Phab reviews per src bit mandatory?
> I would support it but imagine I would get a lot of pushback.
>
> > Requring us all to go sign up like imp@ did to receive all
> > submitted reviews, imho, is also a non functional situation.
>
> So what is a constructive suggestion?
>
> (Fair warning, folks: I won't consider "get rid of Phabricator" or
> "get rid of Bugzilla" as constructive.)
>
> mcl
>

IMHO, pre-review is very good, and as far as I have saw at least for "src",
most of developers always ask somebody else's review, especially when you
are touching an area that you are not very familiar with, or there is
somebody that request review in that area because he/she is the maintainer,
and/or for additional inputs. So it works pretty good.

But in other hand, in the past years, there is a big flow of
emails(post-review) for every each commit, and in most cases as I can see
clearly, those post-reviews are in commits that change few lines, because
those are easy to read and people can get very opinionated. Most of the
developers that does the daily post-review, they do little or no real work
at all.

Personally we are losing some good approaches the project used to have,
such like:
1) Now, shut up and code.  Really.
2) Fix things and move forward.
3) bikeshed pop-up windows:

      +------------------------------------------------------------+
      | Your email is about to be sent to several hundred thousand |
      | people, who will have to spend at least 10 seconds reading |
      | it before they can decide if it is interesting.  At least  |
      | two man-weeks will be spent reading your email.  Many of   |
      | the recipients will have to pay to download your email.    |
      |								   |
      | Are you absolutely sure that your email is of sufficient   |
      | importance to bother all these people ?                    |
      |								   |
      |                  [YES]  [REVISE]  [CANCEL]                 |
      +------------------------------------------------------------+

That MFC in question, I was the reviewer, if I committed it, it means
I approved the review, the submitter is not a committer.

It would applies in the same situation as "Approved by", If I review a
commit from somebody else that has no commit bit in that particular
area,
it is implicit that I'm doing the "Approved by" and that person can
commit with my blessing.

So the fuss here is too big, because one or two developers believes
they must be involved for every each change that other developers are
working on.
It just cannot work in that way, simple like that, instead to do
microscopic post-review over other people's work and most of time
without a single patch,
save the time spent on write so many emails and send a patch, I do
believe all the project will benefit more.

Again, there is nothing wrong with PHA, that review was pretty much
right, but unfortunately rgrimes didn't pay enough attention to that
review, because is clear the submitter is not a commiter,
I committed the patch, I was the reviewer, If I committed, it means I
approved that.

I don't know about you guys, but I will go back try to do something
productive <CODE>.


Best,
-- 

-- 
Marcelo Araujo            (__)araujo at FreeBSD.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
Power To Server.         .\. /_)