Re: WIP branches

What is the advantage of having ghc-wip instead of having all devs just have their own forks?

I am all for each dev having its own fork. The ghc-wip repo would be just for devs having an SVN workflow (i.e. several people working with commit rights on the same branch/fork). If no-one uses this workflow or if Gitlab allows fine tuning of permissions on user forks, we may omit the ghc-wip repo altogether. Regards, Sylvain PS: you didn't send your answer to the list, only to me On 05/02/2019 19:44, Richard Eisenberg wrote:

I agree that movement in this direction would be good (though I don't feel the pain from the current mode -- it just seems suboptimal). What is the advantage of having ghc-wip instead of having all devs just have their own forks?

Thanks, Richard

...

On Feb 5, 2019, at 11:36 AM, Sylvain Henry wrote:

Hi,

Every time we fetch the main GHC repository, we get *a lot* of "wip/*" branches. That's a lot of noise, making the bash completion of "git checkout" pretty useless for instance:

...

git checkout <TAB> zsh: do you wish to see all 945 possibilities (329 lines)?

Unless I'm missing something, they seem to be used to: 1) get the CI run on personal branches (e.g. wip/USER/whatever) 2) share code between different people (SVN like) 3) archival of not worth merging but still worth keeping code (cf https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches)

Now that we have switched to Gitlab, can we keep the main repository clean of those branches? 1) The CI is run on user forks and on merge requests in Gitlab so we don't need this anymore 2 and 3) Can we have a Gitlab project ("ghc-wip" or something) that isn't protected and dedicated to this? The main project could be protected globally instead of per-branch so that only Ben and Marge could create release branches, merge, etc. Devs using wip branches would only have to add "ghc-wip" as an additional remote repo.

Any opinion on this?

Thanks, Sylvain

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs