Dima Pasechnik <d...@sagemath.org> writes:
> On Mon, Jan 24, 2022 at 04:57:49PM +0000, Stuart Henderson wrote: >> On 2022/01/24 15:51, Dima Pasechnik wrote: >> > Would a git-generated email with a diff be acceptable? >> > https://git-send-email.io/ >> >> Yes as long as it's not one of those big [1/n] sequences of separate >> emails that would be better dealt with in a single mail :) >> >> > In principle, such a patch would be very easy to apply (with git) >> > to your local git repo - and it can be bounced to appropriately configured >> > CI... >> >> Applying it with git isn't useful for someone who is going to commit >> it to cvs because (even if they use a mixture of git/got+cvs themselves) >> it still needs to get into their cvs checkout. > > I'm guessing here, but can't you overlay CVS and git trees? > If it's possible then merging with git will produce a CVS diff. > >> >> > > At the moment it's hidden in a page named 'Building the System from >> > > Source', not very clear. Maybe put in on porter's handbook? >> > > >> > > - Some kind of automated pre-submission sanity test would be nice. >> > > Should be simpler than a full CI setup. (is my diff mangled? is my >> > > tree outdated?) >> > The OpenBSD-supporting CI I mentioned in my other email >> > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd >> > would be very easy to set up for this. >> >> What would you propose a CI to do for ports submissions? > > building (maybe testing too) the new/updated port only, just on amd64, as a > start. > > Dima My thought on this is basically: cd /usr/ports/thing/thatchanged && \ portcheck && \ make FETHC_PACKAGES= Also as far as CI "runners" go, this one looks promising: https://github.com/mario-campos/emulate Obviously 7.0 wouldn't be sufficient to do ports testing, but maybe current could be added without much hassle. Another issue is having a ports tree in the "runner".. a git checkout is large, but maybe since it would be "local" to github it wouldn't be _that_ bad?.. but a cvs checkout would be way to slow. > >> >> Identifying and building ports that depend on a particular port and >> doing a build of all of them on a clean -current OpenBSD system could >> be useful in some cases, though complete overkill in most, and would >> take long enough that it would be silly to do before a basic review. >> >> There's another consideration with this. In a way it's good if a diff >> from a less-experienced porter has some easier-to-spot issues (i.e. >> the sort of issues that an automated check would be likely to identify) >> because it's a bit of a flag that other, harder to spot, issues are >> likely to be present too. >>
