> > 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. We have been distributing binary builds for years. > > 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? > > 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. > 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? > 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? > 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? cheers, Torsten
