On Wed, Jul 22, 2020 at 5:35 PM Gilles Sadowski <gillese...@gmail.com> wrote:
> Hi. > > 2020-07-22 21:48 UTC+02:00, Gary Gregory <garydgreg...@gmail.com>: > > Hi All: > > > > There are three build systems available to us: > > > > - Apache Jenkins > > - GitHub Actions > > - Travis CI > > - Plus, *your *PC (that one does not really count.) > > I don't agree: a source distribution assumes that one's own > computing resources is essential. > This project never discussed departing from the assumption > that a contributor should be able to build locally and primarily > check that the reports generated comply with the level of > quality defined, implicitly and explicitly, over the years. > I have no idea what you mean here. Are you conflating CI builds with the release process in your reading of this proposal? > > > We have components building here and there, with multiple components > > building on multiple systems. > > > > My main driver is that we already use GitHub for source mirroring and > PRs, > > This also was never agreed as a change of project management; > from a convenience, the use of GitHub has become an assumption > to which everyone is suddenly requested to adapt to. > Which is fair to ask IMO. Would you rather download patch files from Jira, apply them locally, build manually, and check the results? I'll pass and let GitHub do all that for me. Have you considered the value to the contributors? A CI build failure on GitHub is a great way for contributors to validate their work, especially for those who may not be as familiar with Maven or our expectations (passing unit tests, no missing Apache license headers, and so on.) Of course, there is nothing preventing you from downloading a PR as a diff file or patch file and performing the above steps manually, the difference is where you get the patch from: GitHub or a Jira attachment. GitHub is way beyond convenience, it's an enormously beneficial feature set: PRs, PR builds, CI builds, squash and merge, and so on. > > so it feels better to me to have builds in the same place. > > IMHO, we should ensure that components build on Jenkins. > Are you volunteering to maintain all Commons components on Jenkins ;-) I'm not. > > > I propose we default to GitHub > > -1 I've yet to read a technical reason against this proposal that makes sense to me. > > > while allowing each component to do whatever > > it wants. Specifically, I would like to drop Travis CI and use GitHub > where > > both are used by a component. > > More automated builds are a nice convenience. But just that. > Until the policy is explicitly changed and the process adapted > accordingly, what counts is the build performed on the release > manager's (and the reviewer's) computer. > I'm not sure where this is coming from because I never proposed to change anything about the release process. Gary > > > A tangential issue is whether to use or keep on using Coveralls and > > whether that can be made to play with GitHub or if we should just use > > JaCoCo all over even though I am uncertain as to the liveliness of the > > JaCoCo project. > > I don't get why you would want us to have all our eggs in the > same basket. > > Regards, > Gilles > > > > > Thank you, > > Gary > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
