Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for changing recommended process: Just fork the original repo #59

Open
nightscape opened this issue Sep 26, 2017 · 2 comments
Open

Comments

@nightscape
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants