On Tue, 25 Sep 2018 14:52:03 +0200, Benedikt Ritter wrote:
Am Do., 20. Sep. 2018 um 11:57 Uhr schrieb Gilles <
gil...@harfang.homelinux.org>:
Hi.
On Thu, 20 Sep 2018 09:01:34 +0200, Benedikt Ritter wrote:
> Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
> gil...@harfang.homelinux.org>:
>
>> 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.[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".]
Gilles
Benedikt
>>
>> 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
fly).
Gilles
[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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
