FCP 20190401-ci_policy: CI policy

[Cy Schubert]

In message <201908300201.x7U214qn086080 at slippy.cwsent.com>, Cy Schubert 
writes:
> In message <CANCZdfqagrUzv5wOawypu55Naxt9+AHLSege4ccEzrDkuFa9Mg at mail.gmail.c
> om>
> , Warner Losh writes:
> > On Thu, Aug 29, 2019 at 3:26 PM Warner Losh <imp at bsdimp.com> wrote:
> >
> > >
> > >
> > > On Thu, Aug 29, 2019 at 1:05 PM Rodney W. Grimes <
> > > freebsd-rwg at 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 searc
> h
> > >> 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 t
> he
> > >> > > > 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 a
> nd
> > >> > > > 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.

Thinking much of this week about how I approached this, it was wrong of me 
to structure this email in this way to convey I wasn't entirely convinced. 
This was critique and it should not have been. My email was offensive and 
for that I'm sorry.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.