Out-of-date mirror on GitHub

Out-of-date mirror on GitHub

[Ramkumar Ramachandra]

Hi,

I think it's nice for every project to have an up-to-date mirror on
GitHub, so contributors can maintain a fork and regularly send patches
upstream (via email in this case).  Unfortunately,
https://github.com/zsh-users/zsh seems to be mirroring
git://zsh.git.sf.net/gitroot/zsh/zsh, when the upstream has moved to
git://git.code.sf.net/p/zsh/code.  I don't know who runs the zsh-users
account, but I'm assuming that they're on this list -- so, could
someone update it?

Thanks.

Ram

Re: Out-of-date mirror on GitHub

[Frank Terbeck]

Ramkumar Ramachandra wrote:
> I think it's nice for every project to have an up-to-date mirror on
> GitHub, so contributors can maintain a fork and regularly send patches
> upstream (via email in this case). [...]

I always thought that the nice thing about decentralised systems like
git was that they allowed contributors to keep forks even without a
central place like github. Github is only useful if you want visibility
for your changes and even then you can just publish a repo with your own
account. On github, bitbucket or $yourserviceproviderhere, it doesn't
matter. I actually think having more than one canonical source (and one
that might be out of date as we can see) would actually hurt.

Personally, I do have a mirror of the code repository on my account. But
I don't want to see push requests or forks or any of that. I won't
promise, that it's up-to-date. I won't even promise, that it's there
tomorrow... I only use it to, from time to time, show someone something
I've worked on.

Since any real changes have to go through the mailing lists to pick up
X-Seq: header numbers¹ for later reference anyway, I think everyone is
better off working on a clone (which already _is_ a fork) of the
canonical zsh code repository at sourceforge, and using git's excellent
mail-workflow related tools (like "git format-patch", "git send-email"
and "git am").

Regards, Frank

¹ If you wonder what those are, you might want to take a look at the
  README of https://github.com/ft/zsh-am, which explains zsh's
  traditional development style and a way to cope with it with the
  minimal amount of pain from an integrator's point of view.

Re: Out-of-date mirror on GitHub

[Ramkumar Ramachandra]

Frank Terbeck wrote:
> I always thought that the nice thing about decentralised systems like
> git was that they allowed contributors to keep forks even without a
> central place like github. Github is only useful if you want visibility
> for your changes and even then you can just publish a repo with your own
> account. On github, bitbucket or $yourserviceproviderhere, it doesn't
> matter. I actually think having more than one canonical source (and one
> that might be out of date as we can see) would actually hurt.

Who talked about a central point?  I'm talking about using one of many
convenient free services to keep my code.  No, it's not for
visibility; the point is that my fork needs to be published somewhere
if:

1. I want to work from multiple devices (which I currently do).

2. I want my friends on GitHub to try out my fork, and be able to base
their work on my fork (by forking my fork).

3. I want my local clone to have two different namespaces
(refs/remotes/origin versus refs/remotes/myfork) for a clean
separation between upstream and my fork.  I've actually been
advocating this triangular workflow setup since I got
remote.pushdefault and branch.<name>.pushremote merged into git.git
(just earlier this month).  It means that I can have lot of local
branches that pull from upstream, and push to my fork (git pull/push
just DTRT once this is set up).

Now, you can argue that everyone can have a full clone up on GitHub
(like you do), but that's highly sub-optimal: forks on GitHub share
the same object store, which means that my fork is only taking up the
space used up by my non-upstreamed changes on the GitHub servers.  And
yes, it makes it easy for a friend to see what I'm working on.

> Since any real changes have to go through the mailing lists to pick up
> X-Seq: header numbers¹ for later reference anyway, I think everyone is
> better off working on a clone (which already _is_ a fork) of the
> canonical zsh code repository at sourceforge, and using git's excellent
> mail-workflow related tools (like "git format-patch", "git send-email"
> and "git am").

I'm not advocating pull-requests or anything of the sort.  I like the
mailing list and the patch workflow.  I'm just asking for another
reliable mirror on GitHub which we can all use with a click of a
button.  I mainly contribute to the git project, and we use the patch
workflow too: but we have several up-to-date mirrors including one on
GitHub (at git/git).  linux.git also has a up-to-date mirror on GitHub
(mirrors/linux).

Unless we have something against GitHub, I don't see what the harm is
in having an official (or semi-official) up-to-date mirror hosted
there.

Re: Out-of-date mirror on GitHub

[Frank Terbeck]

Ramkumar Ramachandra wrote:
> Frank Terbeck wrote:
[...]
> Now, you can argue that everyone can have a full clone up on GitHub
> (like you do), but that's highly sub-optimal: forks on GitHub share
> the same object store, which means that my fork is only taking up the
> space used up by my non-upstreamed changes on the GitHub servers.  And
> yes, it makes it easy for a friend to see what I'm working on.

I think the number of active zsh developers is much too small for the
size of the object store to matter for an operation the size of github. ;-)

>> Since any real changes have to go through the mailing lists to pick up
>> X-Seq: header numbers¹ for later reference anyway, I think everyone is
>> better off working on a clone (which already _is_ a fork) of the
>> canonical zsh code repository at sourceforge, and using git's excellent
>> mail-workflow related tools (like "git format-patch", "git send-email"
>> and "git am").
>
> I'm not advocating pull-requests or anything of the sort.  I like the
> mailing list and the patch workflow.  I'm just asking for another
> reliable mirror on GitHub which we can all use with a click of a
> button.  I mainly contribute to the git project, and we use the patch
> workflow too: but we have several up-to-date mirrors including one on
> GitHub (at git/git).  linux.git also has a up-to-date mirror on GitHub
> (mirrors/linux).
>
> Unless we have something against GitHub, I don't see what the harm is
> in having an official (or semi-official) up-to-date mirror hosted
> there.

For the record: I am NOT against mirrors. Mirrors are good. The more the
merrier. Github and Bitbucket would be suitable candidates for obvious
reasons. One of the reasons for contemplating a switch to git was the
CVS server outage at sourceforge a year or two ago, that lasted for a
substantial amount of time. With a number of well-maintained mirrors
that would have been much less of a problem.

However, someone would have to feel responsible for keeping the mirror
up-to-date. And I think an actual mirror is not some repo you push to
manually every now and then from your laptop. A mirror would update
every - say - 10 to 15 minutes from a machine that's permanently online.

Also, like with the git project itself, it has to be established that
have to be submitted to the -workers mailing list for inclusion in the
main codebase. These are the main concerns with semi-official mirrors.
You need to make it perfectly clear somewhere, where changes need to go
to be included, and it the mirror needs to be automatically updated at
short intervals, IMO.

Regards, Frank