> On Apr 13, 2022, at 12:06 PM, Raphaël Gomès <raphael.go...@octobus.net> wrote: > > Hi everyone, > > It has now been more than a month and our window to migrate out of our VM is > closing down. >
Thanks for keeping track of this! > I am happy to report that the new versions of Heptapod and the evolve > extension have brought the expected speedups and the push/pull times on > Heptapod are now much better. There still remains a lot to be desired with > regards to exchange, but that is for another discussion. > > It's time to make an inventory of the project and make some decisions about > what stays the same, what changes and what disappears. We also need to > discuss the contribution and review process. > > # Inventory > > We still don't have a clear path for VM hosting, but maybe the OSUOSL can > help us, seeing as a good amount of the foss.heptapod.net CI there. > Seehttps://osuosl.org/services/hosting/details > <https://osuosl.org/services/hosting/details>. > > ## The mailing lists > > They're not going anywhere, of course. Additionally, the ability to send > patches to the devel mailing list will stay, but will not be the preferred > way proposed. > > They are currently managed by a mailman on the VM, which will need to be > migrated out. The OSUOSL people have already agreed to manage our mailing > lists for us. This could be a good solution to further reduce sysadmin burden. > If we finish off the lists and phabricator, that reduces our footprint a _lot_ FWIW. That removes all (I think?) the reasons we have to send mail, so you’re really down to hosting the wiki and the repos. > > ## Phabricator > > Phabricator will be turned off and be replaced as a means of contribution by > Heptapod. > > The `phab.mercurial-scm.org` differential URLs will be kept around as a > static archive: I have already started the relatively painful (basically > because of AJAX) endeavor of creating the scripts to save the valuable > history of our review discussions, and hope to have enough free time to have > it done before the VM dies. > > ## mercurial-scm.org > > The website will need to be migrated out. I don't expect this to be a major > hassle. > > On a related but technically independent front, I've started some very simple > patches to improve its contents (like not advertising that we use Python > 2...). > > ## Wiki > > The wiki needs to be migrated out. I'm not exactly sure what the story of > MoinMoin is currently, but this should also be a relatively simple process. > > ## Repos > > I think the project should still use hgweb to advertise at least its main > (read-only) repository and any other repo that doesn't have a better home. > See the part about the contribution process for more discussion about the > hg-committed repo. > These all sound right. > ## Patchwork > > What should we do about patchwork? I've only been reminded of its existence > by looking around the VM. Maybe my `getpatches` alias uses it underneath for > queuing from the mailing list? > If your getpatches alias is the one I think it is, that probably hits https://hgpatches.durin42.com/? <https://hgpatches.durin42.com/?> Which, as the URL suggests, is actually running on a machine I own. It’s been zero-maintenance for years, but if y’all care about it long-term we should probably transition it eventually. Though it’s not as pressing. > ## Buildbot > > This has been functionally dead for a long while and will not be carried over > now that we have the Heptapod CI. > > ## Bugzilla > > We will want to - of course - keep our bug tracking. We're using Bugzilla > with MySQL, but we could use PostgreSQL in the target machine if that makes > it easier, I don't think this particular aspect would be too hard to migrate > on its own. > > The migration from bugzilla to another tool (like Heptapod/Gitlab issues) > should probably be another discussion to simplify the transition. > Agreed. Bugzilla has been a pretty minor pain point compared to phabricator. > ## Other things? > > Have I forgotten an important piece of the project? > hgbot runs on mercurial-scm.org <http://mercurial-scm.org/>. It uses a sqlite database and is pretty minimal in terms of overhead, so as long as wherever we put the VM can handle the irc connection, seems fine. > > # Review process > I’m inactive enough I’ll defer to the opinions of others here. Others: if you have opinions, _please_ speak up! This is your chance to make a difference before we EOL phabricator and your choices are (by default) heptapod and `hg email`. [snip review process options] > > # Conclusion > > The hope of this migration is to remove a lot of the sysadmin burden, > simplify, strengthen and modernize the contribution and review process and > leave the project in a healthier, more maintainable state. I hope to see my > mental load reduced by a lot after this transition, and I'm pretty sure I'm > not the only one. > Thanks a bunch!
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
