[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ALL] Multiple things broken in commons build infrastructure


On Thu, 20 Sep 2018 09:01:34 +0200, Benedikt Ritter wrote:
Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <


On Wed, 19 Sep 2018 11:41:53 +0200, Benedikt Ritter wrote:
> Hello,
> I'm trying to release commons-csv and there are multiple things
> broken at
> the moment:
> - the site build does not work because of COMMONSSITE-124
> - the OSGi bundle symbolic name is generated incorrectly because fo
> - the commons-build-plugin goal prefix has been changed to from
> commons to
> commons-build, but no documentation has been updated. Neither our
> release
> documentation nor the plugin documentation. I had to dig into the git > history to find the commit that introduced the change. But there is
> no
> explanation why we need this change. I'm currently updating our
> documentation to reflect the new plugin goal prefix.
> I'm asking everybody who works on commons-parent or the
> commons-build-plugin to take special care because our release process
> is
> painful enough even without this detective work...

But it is clearly not enough: things that used to work should not
unexpectedly break, or if it does for a good reason, components
should be updated in a timely manner, i.e. when the change occurred,
not weeks, months or years later when nobody has a clue about the

Maybe we need to do more rigorous code reviews when these components are

Sure, but we can observe that code reviews are not a high
priority in "Commons".
For good or bad, checks rely almost solely on the output of
automated tools.[1]

Is it possible to set up Jenkins jobs (for all components) that
would automatically pick up the current CP snapshot to detect most
of the undesired changes?

I think that would be possible but it would be a lot of work.

Actually I'm asking whether it's possible to automate the creation
of these jobs (i.e. "bulk" creation from a list of existing jobs,
bypassing the Jenkins GUI, and doing the necessary changes on the


[1] Cf. the preeminence of a Clirr report over the analysis of
    code functionality in real use-cases pre-release of RNG v1.1.

To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx