the Scalariform zombie

[Sam Halliday]

Hi all,

Daniel Trinh has been extremely helpful to the community by forking scalariform, and scalariform-sbt, and fixing some bugs that people were having. Matt Russell (original author of Scalariform) appears to have moved on from Scala and is no longer supporting the tooling or responding to email about it (although I can sometimes catch him on twitter). Matt has granted maven central publication permissions to Daniel.

Things were a real mess there for a while, as we had multiple artefacts with different groupIds publishing scalariform binaries that had the same Scala package names, so classpath collisions were a really big deal. Hopefully, that is all fixed now thanks to Daniel.

But the situation is still far from ideal. Scalariform is a critical part of the Scala tooling infrastructure, and regressions in scalariform have a massive impact on all developers using Scalariform in scala-ide, sbt or ENSIME. Many projects enforce formatting rules on save or compile, and an upgrade to scalariform (which may be part of an IDE update) can devastate a source repository. I know of one company that would simply not upgrade scala-ide if it changed its formatting rules.

I propose that we do the following as a community:

* ask mdr (Matt Russell) to offer his (parent) repository to an admin of either scala-ide or ensime, who can then assign it to either project. If he can't do this, we can fork it and try to popularise the new repo.

* force push Daniel Trinh's master branch into that repository.

* move all outstanding tickets into this repository, making it very clear where the home of scalariform is. Ask Daniel to close his issue tracker.

* do the same with the various forks of scalariform-sbt.

* get publication rights to maven central set up for whoever the new owner is (be it scala-ide or ensime)

I believe this would benefit everybody as it makes it clear where the ongoing development is happening and who the owner is. Scalariform is far too important for it not to be maintained by the community.

What do you think?

Best regards,

Sam

[Richard Bradley]

This sounds good to me.

I think things are in an OK state at the moment re "making it very clear where the home of scalariform is", as the parent GitHub repos now has a prominent notice pointing to Daniel Trinh's repos -- see the top of the README at https://github.com/mdr/scalariform (changed by https://github.com/mdr/scalariform/pull/131 ).

The real fix here would be for GitHub to allow changing the "parent" links between repositories. http://zbowling.github.io/blog/2011/11/25/github/

[Simon Schäfer]

On 09/28/2015 12:26 PM, Sam Halliday wrote:

Hi all,

Daniel Trinh has been extremely helpful to the community by forking scalariform, and scalariform-sbt, and fixing some bugs that people were having. Matt Russell (original author of Scalariform) appears to have moved on from Scala and is no longer supporting the tooling or responding to email about it (although I can sometimes catch him on twitter). Matt has granted maven central publication permissions to Daniel.

Things were a real mess there for a while, as we had multiple artefacts with different groupIds publishing scalariform binaries that had the same Scala package names, so classpath collisions were a really big deal. Hopefully, that is all fixed now thanks to Daniel.

But the situation is still far from ideal. Scalariform is a critical part of the Scala tooling infrastructure, and regressions in scalariform have a massive impact on all developers using Scalariform in scala-ide, sbt or ENSIME. Many projects enforce formatting rules on save or compile, and an upgrade to scalariform (which may be part of an IDE update) can devastate a source repository. I know of one company that would simply not upgrade scala-ide if it changed its formatting rules.

How many reported bugs are there for Daniels fork, which could prevent users from updating? And how likely is it that Daniel fixes them? Scala IDE would simply not upgrade or revert an upgrade if such bugs could not be fixed. I don't see how moving scalariform under the Scala IDE or the ensime umbrella would prevent the occurrence of such bugs. As long as Daniel is active we can contribute fixes back if it is necessary.

I propose that we do the following as a community:

* ask mdr (Matt Russell) to offer his (parent) repository to an admin of either scala-ide or ensime, who can then assign it to either project. If he can't do this, we can fork it and try to popularise the new repo.

* force push Daniel Trinh's master branch into that repository.

* move all outstanding tickets into this repository, making it very clear where the home of scalariform is. Ask Daniel to close his issue tracker.

* do the same with the various forks of scalariform-sbt.

* get publication rights to maven central set up for whoever the new owner is (be it scala-ide or ensime)

I believe this would benefit everybody as it makes it clear where the ongoing development is happening and who the owner is. Scalariform is far too important for it not to be maintained by the community.

What do you think?

Best regards,

Sam

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/6024abab-8a83-4d86-b72e-2769d3cceb28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Halliday]

On Tuesday, 29 September 2015 18:31:05 UTC+1, Simon Schäfer wrote:

On 09/28/2015 12:26 PM, Sam Halliday wrote:

Daniel Trinh has been extremely helpful to the community by forking scalariform, and scalariform-sbt, and fixing some bugs that people were having. Matt Russell (original author of Scalariform) appears to have moved on from Scala and is no longer supporting the tooling or responding to email about it (although I can sometimes catch him on twitter). Matt has granted maven central publication permissions to Daniel.

Things were a real mess there for a while, as we had multiple artefacts with different groupIds publishing scalariform binaries that had the same Scala package names, so classpath collisions were a really big deal. Hopefully, that is all fixed now thanks to Daniel.

But the situation is still far from ideal. Scalariform is a critical part of the Scala tooling infrastructure, and regressions in scalariform have a massive impact on all developers using Scalariform in scala-ide, sbt or ENSIME. Many projects enforce formatting rules on save or compile, and an upgrade to scalariform (which may be part of an IDE update) can devastate a source repository. I know of one company that would simply not upgrade scala-ide if it changed its formatting rules.

How many reported bugs are there for Daniels fork, which could prevent users from updating? And how likely is it that Daniel fixes them? Scala IDE would simply not upgrade or revert an upgrade if such bugs could not be fixed. I don't see how moving scalariform under the Scala IDE or the ensime umbrella would prevent the occurrence of such bugs. As long as Daniel is active we can contribute fixes back if it is necessary.

There is this one: https://github.com/daniel-trinh/scalariform/issues/29 (which now has a PR with a proposed fix) plus a few other smaller things that were introduced in the last version. After a discussion in https://github.com/daniel-trinh/scalariform/pull/58 I'm pretty sure Daniel sees how important it is to maintain backwards compatibility (although I'm not sure if we have a large testbed in place to check this). I'm actually proposing that Daniel would be the maintainer wherever the repository is moved to, since he is so active, but it would be good for others to be able to cut releases as necessary. From my perspective, I still get confused about where scalariform lives and which ticket tracker to use. I guess, fundamentally, we'd need @mdr to assign ownership of the repo for anything to make sense (i.e. this whole thread is moot unless he can do that) :-(