Am Do., 20. Sep. 2018 um 11:57 Uhr schrieb Gilles < [email protected]>:
> Hi. > > On Thu, 20 Sep 2018 09:01:34 +0200, Benedikt Ritter wrote: > > Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles < > > [email protected]>: > > > >> 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... :-) 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: [email protected] > For additional commands, e-mail: [email protected] > >
