[libvirt] [ocaml] reset and resync the libvirt-ocaml repository
Hi, for reasons mostly lost in the history, after the libvirt-ocaml repository was converted to git, it was not used by its main author (Rich Jones); the development continued on Rich's git, at http://git.annexia.org/?p=ocaml-libvirt.git;a=summary After a talk with Rich, we agreed that it was better to move the development back to libvirt.org, just like all the other bindings. There are two problems however: 1) the first 38 commits have an bad author/committer date, and this is also the reason why the existing libvirt-ocaml is not mirrored on github 2) the top 3 commits on libvirt-ocaml were not integrated back to Rich's ocaml-libvirt, and maybe their content might not be totally OK (I will let Rich comment more on this) While rewriting history is bad, - most probably there are not many users of libvirt-ocaml around, - the repository itself is very small (< 500k), - in general it will better to have a working repository So what I'm proposing is to replace the libvirt-ocaml repository with a fixed version of Rich's ocaml-libvirt, and directly on the git hosting side (i.e. not using force-push on the current one). Rich has already commit access for libvirt, so there are no problems to keep his maintainer role on it. Once done, we can notify users in this list about it. What do you think? Is it an acceptable path forward? -- Pino Toscano
On Thu, Sep 06, 2018 at 05:13:23PM +0200, Pino Toscano wrote:
Hi,
for reasons mostly lost in the history, after the libvirt-ocaml repository was converted to git, it was not used by its main author (Rich Jones); the development continued on Rich's git, at http://git.annexia.org/?p=ocaml-libvirt.git;a=summary
After a talk with Rich, we agreed that it was better to move the development back to libvirt.org, just like all the other bindings. There are two problems however:
1) the first 38 commits have an bad author/committer date, and this is also the reason why the existing libvirt-ocaml is not mirrored on github
2) the top 3 commits on libvirt-ocaml were not integrated back to Rich's ocaml-libvirt, and maybe their content might not be totally OK (I will let Rich comment more on this)
While rewriting history is bad, - most probably there are not many users of libvirt-ocaml around, - the repository itself is very small (< 500k), - in general it will better to have a working repository
So what I'm proposing is to replace the libvirt-ocaml repository with a fixed version of Rich's ocaml-libvirt, and directly on the git hosting side (i.e. not using force-push on the current one). Rich has already commit access for libvirt, so there are no problems to keep his maintainer role on it. Once done, we can notify users in this list about it.
What do you think? Is it an acceptable path forward?
I had a chat with Pino offline and I agree with this plan. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Thu, 2018-09-06 at 17:13 +0200, Pino Toscano wrote:
What do you think? Is it an acceptable path forward?
Rewriting history is frowned upon for very good reasons, but considering that the last commit performing anything but trivial maintainance tasks is from 2009 I think it's pretty fair to assume nobody is watching the repository too closely, so I'd personally be okay with replacing it with a fixed one as long as the change is clearly communicated through both the libvir-list and libvirt-users mailing lists. We should stick with the libvirt-ocaml name, though, which is consistent with the way (almost[1]) all language bindings are named. And once we have moved it back to libvirt.org and enabled mirroring to GitHub, we should start thinking about CI :) [1] I'm annoyedly looking at you, ruby-libvirt! -- Andrea Bolognani / Red Hat / Virtualization
On Friday, 7 September 2018 13:57:03 CEST Andrea Bolognani wrote:
On Thu, 2018-09-06 at 17:13 +0200, Pino Toscano wrote:
What do you think? Is it an acceptable path forward?
Rewriting history is frowned upon for very good reasons, but considering that the last commit performing anything but trivial maintainance tasks is from 2009 I think it's pretty fair to assume nobody is watching the repository too closely, so I'd personally be okay with replacing it with a fixed one as long as the change is clearly communicated through both the libvir-list and libvirt-users mailing lists.
Indeed, an email is easy to send once the repository is switched.
We should stick with the libvirt-ocaml name, though, which is consistent with the way (almost[1]) all language bindings are named.
Agreed.
And once we have moved it back to libvirt.org and enabled mirroring to GitHub, we should start thinking about CI :)
Agreed! This will be on my TODO list once the repository is switched. -- Pino Toscano
On Thu, Sep 06, 2018 at 05:13:23PM +0200, Pino Toscano wrote:
Hi,
for reasons mostly lost in the history, after the libvirt-ocaml repository was converted to git, it was not used by its main author (Rich Jones); the development continued on Rich's git, at http://git.annexia.org/?p=ocaml-libvirt.git;a=summary
After a talk with Rich, we agreed that it was better to move the development back to libvirt.org, just like all the other bindings. There are two problems however:
1) the first 38 commits have an bad author/committer date, and this is also the reason why the existing libvirt-ocaml is not mirrored on github
2) the top 3 commits on libvirt-ocaml were not integrated back to Rich's ocaml-libvirt, and maybe their content might not be totally OK (I will let Rich comment more on this)
While rewriting history is bad, - most probably there are not many users of libvirt-ocaml around, - the repository itself is very small (< 500k), - in general it will better to have a working repository
I agree with all those points
So what I'm proposing is to replace the libvirt-ocaml repository with a fixed version of Rich's ocaml-libvirt, and directly on the git hosting side (i.e. not using force-push on the current one). Rich has already commit access for libvirt, so there are no problems to keep his maintainer role on it. Once done, we can notify users in this list about it.
What do you think? Is it an acceptable path forward?
This sounds fine to me, and will let us fix the mirroring too. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thursday, 6 September 2018 17:13:23 CEST Pino Toscano wrote:
What do you think? Is it an acceptable path forward?
Considering there seems consensus on this solution, how do we move forward? Should I fix the repository, publish it somewhere (github or so), and somebody will replace it server-side? Thanks, -- Pino Toscano
On Wed, Oct 10, 2018 at 09:39:03AM +0200, Pino Toscano wrote:
On Thursday, 6 September 2018 17:13:23 CEST Pino Toscano wrote:
What do you think? Is it an acceptable path forward?
Considering there seems consensus on this solution, how do we move forward? Should I fix the repository, publish it somewhere (github or so), and somebody will replace it server-side?
I'll co-ordinate with you further off-list to get it done. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Pino Toscano -
Richard W.M. Jones