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

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

On Tue, 25 Sep 2018 14:52:03 +0200, Benedikt Ritter wrote:
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
>> > - 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.[1]

I don't see how automated build process help here. The build for
commons-collections has been broken for months... :-)

Sure, but I think that most jobs have the automatic email
notification disabled (to spare us yet another layer of
simili-spam), but we could imagine that "critical changes"
should be attended to immediately if their associated jobs
start to fail. [At least that's what I understood from your
message about "rigorous code reviews".]



>> 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