Matthew Selsky via devel <devel@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.
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?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
