On Sat, Jan 25, 2014 at 6:41 PM, Yuri <y...@rawbw.com> wrote: > On 01/25/2014 14:44, Aryeh Friedman wrote: > >> The key seems to be that no one has time to do the stuff they really want >> to do (get new ports into the system)... to that end automating everything >> that can be automated is sure help free up comitter time so they can look >> at what is interesting >> > > Yes. I just can't imagine any generic port tests that can't be automated > and coded into the script once and for good. > Ideal system should be like github with the added automated testing > between pull request submission and merge. It should either fail and notify > the submitter, or succeed and notify the committers. >
Git hup (or *ANY* remote service for that matter) is a no go IMO > > Today all committers do for ports is running some generic tests by hand, > like 'lint' with various flags. Install/uninstall/etc. No wonder this isn't > very a rewarding activity, and committers probably perceive it as a > necessary evil. The way how it is, it causes a waste of their time. > That's why I keep suggesting devel/aegis it does *EVERYTHING* git/git hub does but all locally and has the added benefit that you can not change the change set (aka port submission) until it has passed all 3 of the following (you can turn all but the last two off at runtime and the first only needs to build to pass at a min): 1. Develop change (To leave development it must build and pass *NEW* tests, this is where the automation should go) 2. Review (this is where human eyes come in once all the automated tests are passed) 3. Intergration make sure it plays well with others -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
