Open nightscape opened 6 years ago
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.
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.
Hi all,
I might be missing some background about how etlas works, but I'll just propose this nonetheless :wink: Could the proposed process to create a patch changed to something like this?
without_eta
branch, starting from the commit of the version you want to patch.with_eta
branch from the same commit.with_eta
towithout_eta
.eta-hackage
which links to the PR, and add anIn Progress
label, so everyone knows what you're working on and you can get early feedback.without_eta..with_eta
.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
andscala-native
.