On 08/15/2016 02:43 PM, Jeff Epler wrote:
> I have about an 80% solution to checking signed-off-by and showing it on
> github pull requests as an automated check. You can see a PR that
> satisfies our policy here in my personal github fork:
>
> https://github.com/jepler/linuxcnc/pull/3
>
> (for some reason you have to be signed in on github to see the result of
> checks. then click the "show all checks" link just below the list of
> commits)
>
> This requires a service hosted on public http(s); my chosen
> implementation uses apache and python along with some random internet
> and github components to glue everything together.
Did I see you playing with automated builds on Travis CI recently?
You're running custom web services to support the SOB check; could the
functionality be moved to Travis?
> The remaining 20% would be moving the implementation to a better site
> than one of my personal websites, and making sure it's robust. (I'd
> probably put it on the VM that hosts forum.linuxcnc.org, since I
> administer it, it'll be easy to set up another virtual host and install
> the dependencies)
>
> I'm just wondering: should I spend further time on this?
>
>
> Github "checks" are advisory only; nothing stops a dev clicking "merge
> pull request" if checks are incomplete or failed. This is in stark
> contrast with our current SOB checking, which is mandatory; client side
> "git push --force" cannot bypass this check.
>
> We could do one of the following:
>
> a. nothing. this is easiest.
>
> b. finish implementing this. this is good, because patch submitters
> will get an automated notice pointing them at our SOB policy; and
> devs who are considering whether to work on merging a PR can see
> early if this will prevent pushing them to glo
>
> c. finish implementing this, and decide it's good enough to replace the
> mandatory check and allow us to use the "merge pull request" button.
>
> This would make github our primary git server. I would advise that
> we retain our project git server at git.linuxcnc.org as a hedge
> against github downtime or a cultural shift that makes github less
> desirable to use.
>
> I am personally stuck between options b and c. I think that c would
> require an IRC vote, since the current policy was adopted by IRC vote.
> What do my fellow devs think?
IMO, this kind of automation is very valuable. Why not start with b,
and after some experience with it, decide where to go from there?
John
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
