Proposal for changing recommended process: Just fork the original repo

[nightscape]

Hi all,

I might be missing some background about how etlas works, but I'll just propose this nonetheless 😉
Could the proposed process to create a patch changed to something like this?

1. Fork the original repo.
2. Create a new without_eta branch, starting from the commit of the version you want to patch.
3. Create a new with_eta branch from the same commit.
4. Create a PR from with_eta to without_eta.
5. Create an issue on eta-hackage which links to the PR, and add an In Progress label, so everyone knows what you're working on and you can get early feedback.
6. Write, commit and push the required changes. If you need help, ask the Typelead team on your PR.
7. Create a patch from the diff without_eta..with_eta.
8. Submit this patch.

The idea is that it's much easier to discuss code changes and get feedback if there is an easy way to show your current state. Patches don't lend themselves to this, because they have to be created, copied around and then committed themselves. And then you still only see the patch and not its context (i.e. the non-patched code).
Moreover, if you just fork the original project, it's much easier to git-rebase your changes onto newer versions, or maybe even contribute back some commits to the original repo.

If etlas would support directly pulling from a git repository (instead of patching itself), then you could even get rid of at least steps 7. and 8.

I think in the long run it would be great if the Haskell libraries themselves could integrate the patches, e.g. like in Scala where you have a shared code-base for everything that is not platform specific and then some extra folders for scala-jvm, scala-js and scala-native.

[rahulmutt]

This sounds like a wonderful process! I'm not too happy with the existing process, especially in the cases where the patch is huge (like for directory, process, etc.) and I agree about the feedback, etc.

Etlas does have support for pulling from a github repo, but in this case I don't think it's a good idea and will make dependency management a bit difficult.

[rahulmutt]

And the long term plan is to eventually submit these patches upstream behind CPP conditions. We've already done it for semigroups and contravariant so far.