osuosl / ganeti-instance-image

Ganeti Instance Image is guest OS definition for Ganeti that uses either filesystem dumps or tar ball images to deploy instances. The goal of this OS definition is to allow fast and flexible installation of instances without the need for external tools such as debootstrap. It was originally based on ganeti-instance-debootstrap.
GNU General Public License v2.0
25 stars 18 forks source link

More than 154 historical commits you may want to cherrypick #30

Open rowanthorpe opened 7 years ago

rowanthorpe commented 7 years ago

While working on GRNET's forked repo of ganeti-instance-image several years ago I made more than 154 new commits. Some added new functionality, some added entirely new tools, some fixed issues, and some ended up being rewrites. I opened various PRs against the osuosl repo in the beginning, but after several years of no response I assumed the repo was a zombie, so I closed the PRs (and there were many more commits since those PRs).

I just noticed that activity has restarted on the osuosl repo recently, and some of that activity is reimplementing what I had already done long ago. Obviously that means unnecessary (existing) work for you, and it also means me not getting the benefit of credit as a "contributor" if you reimplement more work that could have just been cherrypicked from me. Because GRNET stopped using ganeti-instance image back when I stopped working on it, I wasn't sure what they intended to do with their copy of the repo, so at the time I cloned a copy under my name too.

I am sure there are many commits you wouldn't want to use (stylistic changes, conflicts with newer commits of your own), but I suspect there is a lot there that will be useful to you if you dig through it. I remember I even wrote auxiliary tools for image-mounting and manipulating VMs' images offline (handy for root password-resets, etc).

Although I don't have time to dig back through historical code I have long since lost mental context for, I am willing to help you make sense of my intentions when I wrote stuff, if you are digging through it and cherrypicking, and it would be a shame if none of that mountain of work is used. Let me know.

My copy of the repo is here and the master and devel branches are at the same commit. Feel free to close this issue when you have finished looking there.

ramereth commented 7 years ago

Sorry for the zombie nature of this project over the last several years. I have been busy doing other projects and our needs had been met. But I've recently started looking into this again to find some improvements. Thanks for pointing these out! Are there any particular major features/changes you added that you think might be the most useful? I'm not sure when I'll get around to this, but it's nice to have on my radar.

Also, your contributions are always welcome!

Thanks!

rowanthorpe commented 7 years ago

Thanks for replying. I opened the initial pull-requests between October & December 2014, and after no responses decided to close them in February 2015 and not open any more new ones after that as my employer decided to just work with our repo as a fork. The PRs can be found by searching the ones from me against your repo but at a glance I can see the latest commits on my forked repo were 7 months after the latest PR, so it is probably also worth scrolling through those later commits individually as well. I remember I was mostly (always?) rigorous about making the commits readable and commit-messages sane, so it shouldn't be difficult to get a quick overview.

I think the main issue would be that by the time of the later commits (after we decided to just "use the fork") the code-base diverged so far from yours that it was effectively rewritten in many places (including sometimes even just scattered changes for stylistic reasons to make personal maintenance easier). For that reason (and because I now haven't used Ganeti for several years and am busy with other stuff entirely) I wouldn't be able to find time to fish through rebasing commits against your latest code & preparing maintainer-friendly PRs. Because you are using G-I-I and actively updating it again though I expect it would be much easier and faster for you to glance through the commit-messages and cherrypick anything that looks useful and relevant for your use-case. At least it will be faster than reimplementing any of those changes yourselves from scratch, which I noticed happened with at least 1 or 2 commits since then.

rowanthorpe commented 7 years ago

BTW: I also now notice that at least a few of the new issues and PRs are for things that were fixed in my repo many years ago, so you may be able to close several of them by cherrypicking from there, and it might actually save you time for things you are presently dealing with, compared to addressing them from scratch. Obviously it is also personally a bit frustrating to see new PRs adding code which I had already added 2.5 years ago but won't get any credit for (I am not implying there is any actual uncredited "copy-pasting" happening, I expect those developers don't even know about the existence of my code/commits/PRs - because when I was writing them there were no responses from osuosl).