Testing

[Matthew Selsky]

On Wed, Dec 06, 2017 at 02:49:07PM -0500, Eric S. Raymond wrote:
> Matthew Selsky via devel <devel at ntpsec.org>:
> > On Wed, Dec 06, 2017 at 12:25:14PM -0500, Eric S. Raymond via devel wrote:
> > 
> > > I have a different plan.  I always write doc patches as part of my
> > > change commits; my discipline is to prevent code and docs from getting out
> > > of sync in the first place.
> > 
> > Does everyone on the project do that?  This "policy" isn't listed in devel/hacking.txt.  If it's a project policy, then it should be.
> 
> Good point.  I just did that.

Did this get pushed?  I don't see anything new in devel/hacking.txt

> I should have done it sooner, but this habit is so ingrained in me that
> the requirement has become kind of invisible.
> 
> > We also don't have formal code reviews (before commit) since many devs push directly to "master".  So we can't enforce any policies to code before they get committed to master.
> > 
> > At some point, maybe soonish, can we stop pushing directly to master and instead push to branches (either in the main repo, or a personal fork) and then submit MRs and go through the review/approval workflow that's built into GitLab?
> 
> What would the gain in this be?
> 
> If dev with merge-approver power pushes to a branch and then merges
> it, how is the entailed risk any different from a direct push?

We can have gitlab enforce that all CI builds must pass before merge.  This will keep some of the brokenness that we've seen in the past out of master.

We can put off discussion of approvals in the workflow until later.

Cheers,
-Matt