Any idea how to release https://github.com/jenkinsci/xstream-fork

[Oliver Gondža]

Hey, the xstream fork repo is quite outdated and all but I would like to
cut a new bugfix release. It does not seem to quite follow
maven-release-plugin convention, putting aside the <scm> tag of the fork
still points to the upstream SVN of xstream.

How did we ever released from our fork? I am asking before I start to
rework the thing ....

Thanks!
--
oliver

[Jesse Glick]

On Fri, Dec 7, 2018 at 7:38 AM Oliver Gondža <ogo...@gmail.com> wrote:
> How did we ever released from our fork?

I am not personally even sure whether `xstream` or `xstream-fork` is
really the right source repo, much less exactly how we have
historically cut releases.

[Oleg Nenashev]

`xstream` is what we use in Jenkins nowadays.

`xstream-fork` has been created by Nicolas de Loof at some point, but this repository has never been updated to incorporate Jenkins-specific patches. And I am not sure whether it has passed the full test cycle. There is a splitbrain between the repos, and their README files are misleading. Since 2016 there were pull requests submitted against both repos, and it made the situation worse.

Whomever wants to update XStream, we firstly need to resolve the splitbrain issue. Switching from a custom XStream fork to the official XStream releases is something we should do IMHO, but it needs to be tested a LOT before we do it. Any XStream change may cause Jenkins startup issues and, potentially, security issues if JEP-200 classfilter hooks stop working. 

BR, Oleg

[Oliver Gondža]

On 11/12/2018 12.55, Oleg Nenashev wrote:
> `xstream` is what we use in Jenkins nowadays.
> `xstream-fork` has been created by Nicolas de Loof at some point, but
> this repository has never been updated to incorporate Jenkins-specific
> patches. And I am not sure whether it has passed the full test cycle.
> There is a splitbrain between the repos, and their README files are
> misleading. Since 2016 there were pull requests submitted against both
> repos, and it made the situation worse.
>
> Whomever wants to update XStream, we firstly need to resolve the
> splitbrain issue. Switching from a custom XStream fork to the official
> XStream releases is something we should do IMHO, but it needs to be
> tested a LOT before we do it. Any XStream change may cause Jenkins
> startup issues and, potentially, security issues if JEP-200 classfilter
> hooks stop working.

Well, that surely is a noble goal but I am not sure if doable ta all. My
impressions, mostly from https://github.com/x-stream/xstream/pull/106,
are this will not happen.

--
oliver

[Oliver Gondža]

On 11/12/2018 12.55, Oleg Nenashev wrote:

> `xstream` is what we use in Jenkins nowadays.
> `xstream-fork` has been created by Nicolas de Loof at some point, but
> this repository has never been updated to incorporate Jenkins-specific
> patches. And I am not sure whether it has passed the full test cycle.

Uhh, thanks for pointing that out. Not i makes sense the repo felt so
abandoned...

--
oliver

[nicolas de loof]

As discussed already here, the *-fork repository have been created so that the jenkins flavours of those library are actual forks from upstreams, so we can better propose our patches and/or pull upstream fixes.

Now, if you feel this is useless, fell free to remove the unnecessary ones. 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8b283fea-a325-ce21-4dac-f2c50d4df8ef%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas De Loof

[Oleg Nenashev]

I think it is useful, we just need to update the documentation to clarify what is the purpose of the repo.

It seems that we will have to go forward with a custom for of XStream in meantime, but upstreaming our patches totally makes sense (ones which can be upstreamed).

BR, Oleg

[Matt Sicker]

If upstream doesn't want to support our features, is there any way to refactor said features into its own library that works with an unpatched upstream xstream? Otherwise, I suppose if we maintained a fork that was regularly merged with upstream would be better than just forking a version at one point and never backporting updates from then on.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6d040308-a013-492b-85c7-4a2b015e1c67%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Matt Sicker

Software Engineer, CloudBees

[Jesse Glick]

On Thu, Dec 13, 2018 at 11:47 AM Matt Sicker <msi...@cloudbees.com> wrote:
> If upstream doesn't want to support our features, is there any way to refactor said features into its own library that works with an unpatched upstream xstream?

I think wherever that is possible, we are already doing it in core.
`RobustCollectionConvertor` etc. (Though the XStream maintainer has
said that this trick cannot work reliably.)

We also made some stuff in XStream thread-safe which the maintainer
says should not be—we are using it incorrectly.

References upon request.