Date: Fri, 30 Aug 2019 10:24:55 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ed Maste <emaste@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, fcp@freebsd.org Subject: Re: FCP 20190401-ci_policy: CI policy Message-ID: <20190830072455.GD71821@kib.kiev.ua> In-Reply-To: <CAPyFy2Dig7MF=NcDWqT=qSTeS_qh1PhRr=hSC_LfHa2X6jU0jg@mail.gmail.com> References: <CAOfEmZgEbT7ni80vWehHm%2B4oPyH3m%2Brb0M_VyxHmNM3rkhyG1Q@mail.gmail.com> <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> <CANCZdfoYNn9Xcyds_YbDXMLTrMdmTewvP_pK7FSDAPbDAeV6Lw@mail.gmail.com> <CANCZdfqagrUzv5wOawypu55Naxt9%2BAHLSege4ccEzrDkuFa9Mg@mail.gmail.com> <CAPyFy2BH2EN-KCWhtNku8BghnguEVXr=F04=H51_YdPCNPnhUA@mail.gmail.com> <CANCZdfqpzoR2YE0H493xTgfOxXcoSOJKrO9CWoc7KNaAk5BvHQ@mail.gmail.com> <CAPyFy2Dig7MF=NcDWqT=qSTeS_qh1PhRr=hSC_LfHa2X6jU0jg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 29, 2019 at 07:44:59PM -0400, Ed Maste wrote: > >> This sounds more like a problem with the tooling than an argument > >> against reverting though. > > > > We live in a subversion universe for the moment, so you have to view it through that lens. > > Fair enough, right now the policy needs to accommodate the reality of > the tools we're using today. > > Perhaps it's a failure of imagination on my part but I have trouble > seeing how a revert would lead to losing work - could you give an > example? If you have a committed change that is the precursor for later series, and this series is not yet committed. Then rebase or merge of the master with the base change reverted causes much trouble. > > > Sometimes yes, sometimes no. Even with git svn, there is a cost associated with it. The level of effort is not zero. Especially when one pushes several interrelated changes at once. If the first of these caused an issue on gcc, say, often the cost is too high to revert the whole chain. It's a lot easier to put in a fix and move on. > > The level of effort imposed on other users while the tree is broken is > not zero, either. Certainly if it's possible to commit a fix and move > forward that's the approach favoured by community norms. > > > It's a fair example for why a simpleminded approach will create more friction than the current system. And there is a need for caution in expanding the logic beyond all but the most recent changes... > > The point of the FCP is to facilitate the revert while the change is > (among the) most recent, precisely so that additional changes don't > build on it. Also, I have to admit publically, that my changes were blamed by CI so many times, when they had nothing to do with the breakage. I forwarded such mails to ci@ regularly, then stopped doing that. Also, I believe that imposing requirements on committers to not offend CI is not fair if committers cannot _easily_ verify that the change does not. Give us a way to e.g. mail pgp-signed message to ci-check@ and get the reply 'ok/fail' in reasonable time, or a button on phab to get the same response. Even if I bother to recreate CI env locally (I do not), races are different on the CI machines.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190830072455.GD71821>