[ALL] Multiple things broken in commons build infrastructure

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[ALL] Multiple things broken in commons build infrastructure

Benedikt Ritter-4
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
Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski
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.

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

>
> Regards,
> Benedikt


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Benedikt Ritter-4
Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
[hidden email]>:

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


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


>
> Regards,
> Gilles
>
> >
> > Regards,
> > Benedikt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski
Hi.

On Thu, 20 Sep 2018 09:01:34 +0200, Benedikt Ritter wrote:

> Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
> [hidden email]>:
>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Benedikt Ritter-4
Am Do., 20. Sep. 2018 um 11:57 Uhr schrieb Gilles <
[hidden email]>:

> Hi.
>
> On Thu, 20 Sep 2018 09:01:34 +0200, Benedikt Ritter wrote:
> > Am Mi., 19. Sep. 2018 um 12:23 Uhr schrieb Gilles <
> > [hidden email]>:
> >
> >> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski
On Tue, 25 Sep 2018 14:52:03 +0200, Benedikt Ritter wrote:

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