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