Date: Thu, 29 Aug 2019 19:01:04 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Ian Lepore <ian@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Marcelo Araujo <araujo@freebsd.org>, fcp@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>, Li-Wen Hsu <lwhsu@freebsd.org>, Kristof Provost <kp@freebsd.org> Subject: Re: FCP 20190401-ci_policy: CI policy Message-ID: <201908300201.x7U214qn086080@slippy.cwsent.com> In-Reply-To: <CANCZdfqagrUzv5wOawypu55Naxt9%2BAHLSege4ccEzrDkuFa9Mg@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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CANCZdfqagrUzv5wOawypu55Naxt9+AHLSege4ccEzrDkuFa9Mg@mail.gmail.c om> , Warner Losh writes: > On Thu, Aug 29, 2019 at 3:26 PM Warner Losh <imp@bsdimp.com> wrote: > > > > > > > On Thu, Aug 29, 2019 at 1:05 PM Rodney W. Grimes < > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > >> (unneeded context removed) > >> > >> > > In either scenario we end up reducing test coverage, which means we?re > >> > > going to push more bugs towards users. > >> > > > >> > > > I totally agree. This is an overly-bureaucratic solution in search > >> of > >> > > > a problem. > >> > > > > >> > > > If this needs to be addressed at all (and I'm not sure it does), > >> then > >> > > > another sentence or two in bullet item 10 in section 18.1 [*] of the > >> > > > committer's guide should be enough. And even then it needn't be > >> > > > overly-formal and should just mention that if a commit does break > >> the > >> > > > build the committer is expected to be responsive to that problem and > >> > > > the commit might get reverted if they're unresponsive. I don't > >> think > >> > > > we need schedules. > >> > > > > >> > > I do feel that?s a better argument. We?ve always had a policy of > >> > > reverting on request (AIUI), so this is more or less trying to be a > >> > > strong restatement of that, more than a fundamental shift in policy. > >> > > > >> > > >> > We don't have a policy to revert commit, actually revert commit is > >> > something bad, it is kind of punishment, I have been there, nobody > >> wants to > >> > be there. Stop to push this non-sense argument. > >> > >> Here in lies one of the fundemental problems, this view by some that > >> a "revert commit is something bad, it is kind of punishment". That is > >> not true. Reverts are GREAT things, they allow the tree to be returned > >> to a known state, usually quicly. The original commit is STILL IN SVN, > >> and a bad revert can guess what.. be reverted!. > >> > >> IMHO the project as a whole needs to overcome its fear of reverts and > >> start to use them for the great and powerful things that they are. > >> > >> This connection of bad and punishment needs to stop, and the sooner > >> the better. > >> > > > In the past, if someone had any follow on work at all in their tree, the > reversion would be quite disruptive to that work. Most of the time it's a > lot easier for me, with a lot less friction, to just fix issues that come > up after the commit than to revert and prepare a new commit. Sure, it's > possible, but it can destroy work in extreme cases. *THAT* is why I'm > firmly in the camp of giving the original committer a shot at fixing things > because it's much less disruptive to them, and generally we can get a fix > into the tree faster. It reduces friction and encourages people to fix > things quickly, imho, to hesitate a little on the revert. Especailly when > the broken thing is the playstation loader on powerpc that can stay broken > for the hour or six (or even days) it takes me to figure out why it > broke... Often things away from the beaten path don't get discovered for > days or weeks or months, and a reversion then can be extremely disruptive > if there's other changes layered on top of the offending commit.... > > So the whole reversion issue is a lot more complicated than 'oh, it's still > in svn'. There are real high costs associated with being too quick or > liberal on the revert and those must be weighed against the damage the bad > commit is doing.. I think that's why we need to define the problem first. The justification of the arbitrary numbers of minutes/hours isn't clear. I see there are possibly two trains of thought here which need to be separated. 1. A general frustration by some. 2. A tool, a solution to a problem, I am unsure if it is related to #1. Why do I see this as such? The problem statement beings by saying that FreeBSD has a CI system that performs compiles and runs automated tests. In the next paragraph it says sometimes changes break compilation... This tells me that A) we have a solution which we discuss in B (the problem). To my thinking we need to approach this from: A) we have a problem, maybe backing it up with some stats some evidence of sorts. Then explore one or preferably two solutions. Not to be hard on anyone and keeping my emotions out of it, they way the problem statement is structured reads to me as a solution looking for a problem. That's not to say we don't have a problem (nor am I saying we do have a problem either). The problem statement is structured to a foregone conclusion. I'd structure this by stating the problem (paragraph 2 and the bullet points, though I think the problem needs to be explored a little more), then discuss some of the timing issues regarding the fixing of the three types of problems (compile, panic, and regressions, of which tests identify regressions). I'm not saying that there is or isn't a problem but the problem statement as written doesn't convince me there is a problem. It's leading me to a conclusion. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201908300201.x7U214qn086080>