Re: [ALL] Multiple things broken in commons build infrastructure
Am Do., 20. Sep. 2018 um 11:57 Uhr schrieb Gilles <
> On Thu, 20 Sep 2018 09:01:34 +0200, Benedikt Ritter wrote:
> > Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
> > gilles@xxxxxxxxxxxxxxxxxxxxx>:
> >> Hi.
> >> 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
> >> > COMMONSSITE-125
> >> > - 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...
> >> +1
> >> 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
> >> problem.
> > Maybe we need to do more rigorous code reviews when these components
> > are
> > changed...
> 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.
I don't see how automated build process help here. The build for
commons-collections has been broken for months... :-)
> >> 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
>  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