Date: Sat, 1 Dec 2018 10:14:44 +0700 From: Eugene Grosbein <eugen@freebsd.org> To: cem@freebsd.org Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r341352 - head/usr.sbin/trim Message-ID: <13bec879-3cf5-3f9b-58a3-47f7405e5f77@freebsd.org> In-Reply-To: <CAG6CVpWMCsoho-gDnuSHWjh=KsbsyL6=xBT%2BQX=dfRhh3Cx-gg@mail.gmail.com> References: <201811302157.wAULv2iH057184@repo.freebsd.org> <CAG6CVpWMCsoho-gDnuSHWjh=KsbsyL6=xBT%2BQX=dfRhh3Cx-gg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
01.12.2018 9:34, Conrad Meyer wrote: > Generally when a committer puts a patch on phabricator, they'll commit > it when they're ready. I think this is wrong behaviour of the Phabricator to auto-close a differential just because some singe commit referred to it. It was not meant to be closed for now and I've just re-opened the differential. > In particular this patch hadn't actually been > approved by any reviewers yet and review discussion was still active. Is it possible to add hackers@ audience to reviewers list? I do not see people discussing the topic adding themselves and it would be wrong to force them. > As far as I can tell, imp@ hadn't indicated he wasn't going to commit > his patch himself. Parts of changes that have consensus were committed. Why is it bad? > I'd love to be imagining things, but it seems like > the general trend is you consistently fail to follow basic etiquette > and consistently ignore review and concerns. > > This time around you definitely don't have the excuse of phabricator > being silent for months — the review hadn't seen any 24h period of > inactivity since its creation. > > I was tentatively ok with trim staying in based on imp@ taking charge > of cleaning up the deficiencies, but you've gone around imp@ and > ignored me completely. This is untrue: I committed some changes requested by you and imp. > Please back out trim and consider taking a few days off. The way trim > has entered the tree is just not how we do things as a project. I > think there's universal consensus that we want a tool that does what > trim does in base; there's some bikeshedding about whether it should > live in dd or not (it shouldn't); but rest assured, it will go in in > some form. My ask is that it to go in the right way, instead of the > total mess it has so been so far. I have not seen universal consensus about backing it out and I disagree that it is "total mess". The code is small, clean and works. But if you insist, feel free to remove it.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13bec879-3cf5-3f9b-58a3-47f7405e5f77>