2020-07-23 0:07 UTC+02:00, Torsten Curdt <tcu...@vafer.org>: >> >> 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. >> > > It does not mean that a source distribution goes away.
Nor did I mean that it would. I commented on the remark that one's own computer supposedly did not matter. > We have been distributing binary builds for years. Officially, for convenience (but that's not the point). The point is that the distributed files do not come from CI builds, but from one performed on the RM's machine. > > >> > 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. >> > > Requested to suddenly adopt what exactly? > "adapt" not "adopt". In this instance, I don't see why I should adapt to a flood of messages that was never discussed since I've been asked to subscribe to "issues@". > >> > so it feels better to me to have builds in the same place. >> >> IMHO, we should ensure that components build on Jenkins. >> > > Why? The CI/CD system should not matter. Sure. It's a convenience configured by each developer or team, as they see fit. So, why the original post recommending to favour GitHub? > > >> 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. >> > > Are we talking about changing that? The problem (of today namely) is that we don't talk. The process for using GitHub was not discussed either. For me, anything that comes through GitHub is a burden, a loss of time. I can imagine that it is a boon for others but is this an Apache or GitHub project? >> 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 must have missed some of the messages. > What is the problem using Coveralls? None for me. > >> I don't get why you would want us to have all our eggs in the >> same basket. >> > > As long as we keep one egg (the sources) the other eggs don't really > matter. > Could you explain the problem with the basket? As said above, GitHub is inconvenient for me; thus any move that assumes otherwise, I don't agree with. Regards, Gilles > > cheers, > Torsten > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
