Discussion:
[ALL] Multiple things broken in commons build infrastructure
Benedikt Ritter
2018-09-19 09:41:53 UTC
Permalink
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...

Regards,
Benedikt
Gilles
2018-09-19 10:23:25 UTC
Permalink
Hi.
Post by Benedikt Ritter
Hello,
I'm trying to release commons-csv and there are multiple things broken at
- 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.

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?

Regards,
Gilles
Post by Benedikt Ritter
Regards,
Benedikt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Benedikt Ritter
2018-09-20 07:01:34 UTC
Permalink
Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
Post by Gilles
Hi.
Post by Benedikt Ritter
Hello,
I'm trying to release commons-csv and there are multiple things broken at
- 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...
Post by Gilles
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.

Benedikt
Post by Gilles
Regards,
Gilles
Post by Benedikt Ritter
Regards,
Benedikt
---------------------------------------------------------------------
Gilles
2018-09-20 09:57:37 UTC
Permalink
Hi.
Post by Benedikt Ritter
Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
Post by Benedikt Ritter
Hi.
Post by Benedikt Ritter
Hello,
I'm trying to release commons-csv and there are multiple things broken at
- the site build does not work because of COMMONSSITE-124
- the OSGi bundle symbolic name is generated incorrectly because
fo
Post by Benedikt Ritter
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
Post by Benedikt Ritter
history to find the commit that introduced the change. But there
is
Post by Benedikt Ritter
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
Post by Benedikt Ritter
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]
Post by Benedikt Ritter
Post by Benedikt Ritter
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-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Benedikt Ritter
2018-09-25 12:52:03 UTC
Permalink
Am Do., 20. Sep. 2018 um 11:57 Uhr schrieb Gilles <
Post by Gilles
Hi.
Post by Benedikt Ritter
Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
Post by Benedikt Ritter
Hi.
Post by Benedikt Ritter
Hello,
I'm trying to release commons-csv and there are multiple things broken at
- the site build does not work because of COMMONSSITE-124
- the OSGi bundle symbolic name is generated incorrectly because
fo
Post by Benedikt Ritter
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
Post by Benedikt Ritter
history to find the commit that introduced the change. But there
is
Post by Benedikt Ritter
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
Post by Benedikt Ritter
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... :-)

Benedikt
Post by Gilles
Post by Benedikt Ritter
Post by Benedikt Ritter
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.
---------------------------------------------------------------------
Gilles
2018-09-25 13:06:48 UTC
Permalink
Post by Benedikt Ritter
Am Do., 20. Sep. 2018 um 11:57 Uhr schrieb Gilles <
Post by Benedikt Ritter
Hi.
Post by Benedikt Ritter
Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
Post by Benedikt Ritter
Hi.
Post by Benedikt Ritter
Hello,
I'm trying to release commons-csv and there are multiple things broken at
- the site build does not work because of COMMONSSITE-124
- the OSGi bundle symbolic name is generated incorrectly
because
Post by Benedikt Ritter
Post by Benedikt Ritter
fo
Post by Benedikt Ritter
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
Post by Benedikt Ritter
Post by Benedikt Ritter
Post by Benedikt Ritter
release
documentation nor the plugin documentation. I had to dig into
the
Post by Benedikt Ritter
Post by Benedikt Ritter
git
Post by Benedikt Ritter
history to find the commit that introduced the change. But
there
Post by Benedikt Ritter
Post by Benedikt Ritter
is
Post by Benedikt Ritter
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
Post by Benedikt Ritter
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,
Post by Benedikt Ritter
Post by Benedikt Ritter
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
Post by Benedikt Ritter
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
Post by Benedikt Ritter
Benedikt
Post by Benedikt Ritter
Post by Benedikt Ritter
Post by Benedikt Ritter
Is it possible to set up Jenkins jobs (for all components) that
would automatically pick up the current CP snapshot to detect
most
Post by Benedikt Ritter
Post by Benedikt Ritter
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-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Loading...