Re: Haxx will stop hosting most Rockbox services after 2020
On Sun, Mar 15, 2020 at 9:18 AM Solomon Peachy via rockbox-dev < rockbox-dev@cool.haxx.se> wrote: > On Sun, Mar 15, 2020 at 11:13:36AM +0100, Baptiste BARON via rockbox-dev > wrote: > > *Forums : Same as above, dump the database and mirror the forums on a > third > > GitHub branch (github.com/Rockbox/rockbox-forums). We might ensure a > > transition with an update later on. > > IMO, migrating the existing forums is a largely pointless affair; nuke > 'em from orbit and create something new, if at all. :) > > I think that the people who worked so hard on the project historically should be rewarded (and in rare cases, for mistakes, punished) for their efforts. Thus, the forums need to be preserved. Also, otherwise, people will be forced to waste reinventing the wheel on projects and ideas that don't work, and they will have to re-learn what others pioneers expended time on. I am happy to host rockbox.org as an additional domain using options normally afforded via cpanel. Obviously, some features would need to be scrapped. The conversions of old materials need not be 100% perfect IMO. Just let's preserve word search capacities, somehow. > > * Gerrit : Is it easy to setup once the main repo is GitHub ? What is > used > > for the CI ? Can the CIs be migrated as well ? May we see the code > somewhere > > AFAIK using gerrit means gerrit has to host the code, period. Gerrit's > flow is largely incompatible with a GH-style pull-request model. > > It's not agreed upon that keeping Gerrit is worth it overall, but > migrating the existing patch backlog is likely to be a challenge. Some > (most?) of it is irrelevant but a lot of it isn't. > > The CI/build system is home-grown, its code resides on git.rockbox.org, > and isn't really compatible with any existing CI flow. I really don't > think it's worth rewriting, if only because it's a decent amount of > work, what exists today works very, well, and the bulk of the builders > are maintained by currently-active developers. > Sadly I don't know enough about this to comment how it can be used to work via my relatively limited cpanel interface, but I'm agreeing to host it and might need some help from others to know what to do. > All that said, at the end of the day, talk is cheap, and it's going to > take someone stepping up to do the actual work. > Agreed. I don't think I spend more than 10 minutes writing this email. -- Jason Taylor 301-277-1909 (Work Landline Telephone) 240-471-5613 (textable cellphone) I respond in some fashion to all emails with new subjects directed specifically to me within 48 hours, so try again by phone if I don't respond, because it means that I didn't get your message.
Re: Haxx will stop hosting most Rockbox services after 2020
On Sun, Mar 15, 2020 at 11:13:36AM +0100, Baptiste BARON via rockbox-dev wrote: > *Forums : Same as above, dump the database and mirror the forums on a third > GitHub branch (github.com/Rockbox/rockbox-forums). We might ensure a > transition with an update later on. IMO, migrating the existing forums is a largely pointless affair; nuke 'em from orbit and create something new, if at all. :) > * Gerrit : Is it easy to setup once the main repo is GitHub ? What is used > for the CI ? Can the CIs be migrated as well ? May we see the code somewhere AFAIK using gerrit means gerrit has to host the code, period. Gerrit's flow is largely incompatible with a GH-style pull-request model. It's not agreed upon that keeping Gerrit is worth it overall, but migrating the existing patch backlog is likely to be a challenge. Some (most?) of it is irrelevant but a lot of it isn't. The CI/build system is home-grown, its code resides on git.rockbox.org, and isn't really compatible with any existing CI flow. I really don't think it's worth rewriting, if only because it's a decent amount of work, what exists today works very, well, and the bulk of the builders are maintained by currently-active developers. > * Flyspray : Development for Flyspray has resumed some time ago, most > up-to-date version is 1-0rc9, per the website. They also have a GitHub repo > as well. Can we see the code for the current FlySpray used for Rockbox, so > we can test migrations ? Speaking from experience, migrating to the current version of flyspray is likely to be straightforward. The question is whether or not to just nuke it from orbit or not, as most of the issues in there are so old to be of little relevance today. * * * All that said, at the end of the day, talk is cheap, and it's going to take someone stepping up to do the actual work. IMO, from a "bang-for-the-buck" perspective, it makes more sense to cut-n-paste the existing tooling off of the haxx infrastructure onto sometihng else. After everything is consolidated, we can determine what tooling makes sense to rework without a dangling sword overhead. I'm still willing (and able) to do this, including hosting everything but the forums, but I won't have the personal bandwidth until April. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. signature.asc Description: PGP signature
Re: Haxx will stop hosting most Rockbox services after 2020
Le 13/03/2020 à 09:31, Daniel Stenberg via rockbox-dev a écrit : On Sat, 8 Feb 2020, Daniel Stenberg via rockbox-dev wrote: Hello, This is just a gentle reminder that there has now been over a month since we made everyone aware of the coming service shutdown/transition. Since then, scorche has also advertised that he too shuts down the Rockbox related services he runs, at the same time. I will again urge interested people to start this transition ASAP. There will be no deadline extension. As mentioned in the subject, the Haxx team (me, Björn, Linus and Kjell) will stop hosting most Rockbox related services on January 1st 2021. It should give everyone plenty of time to find new places and alternatives for everything that needs to survive. https://github.com/Rockbox/rockbox/wiki/Transition Hello, people. The https://github.com/Rockbox/rockbox/wiki/Transition page gives an insight of what is needed in terms of resources. I'd like to bring my advice, point after point. First of all, I pronounce myself in favor of GitHub for "code hosting", and self-hosting for "content delivery". What I mean is that we can still have code backups in the cloud, which is much more secure than code that may disappear if the main provider stops hosting the services altogether (which might happen with Rockbox now...) * Git : I see that the last commits were made on git.rockbox.org, and that the github mirror is still a mirror. We might switch ASAP and consider the active version to be the GitHub one, and the passive one to be the git.rockbox.org one. * Themes and Translate : Can someone mirror them to a GitHub repo, separate from the main Rockbox one (like github.com/Rockbox/rockbox-themes and github.com/Rockbox/rockbox-translate) ? We might have a look at the code and modernize it later, but the main thing is to at least have a version mirrored in the cloud ASAP. *Forums : Same as above, dump the database and mirror the forums on a third GitHub branch (github.com/Rockbox/rockbox-forums). We might ensure a transition with an update later on. * Gerrit : Is it easy to setup once the main repo is GitHub ? What is used for the CI ? Can the CIs be migrated as well ? May we see the code somewhere ? * Flyspray : Development for Flyspray has resumed some time ago, most up-to-date version is 1-0rc9, per the website. They also have a GitHub repo as well. Can we see the code for the current FlySpray used for Rockbox, so we can test migrations ? * Daily builds : Host the scripts on GitHub as well ? * Wiki : Is it hard-coded or based on an existing framework like DoKuWiki or MediaWiki ? As for the self-hosting, I am no dev, but I am a sysadmin. There is a French provider with cheap, but powerful servers, and an unlimited bandwidth. Given what is indicated in the "Resource Overview" heading, they might suffice to host all of your services. Here is a link : https://www.soyoustart.com/us/essential-servers/ Those are dedicated servers and not VPS, it seems, which is much more convenient. And, on the top of that we have unlimited bandwidth. (Data consumption is generally not charged in France, except for 4G data). Thank you all for your advice. Regards, Baptiste B.
Re: Haxx will stop hosting most Rockbox services after 2020
On Sat, 8 Feb 2020, Daniel Stenberg via rockbox-dev wrote: Hello, This is just a gentle reminder that there has now been over a month since we made everyone aware of the coming service shutdown/transition. Since then, scorche has also advertised that he too shuts down the Rockbox related services he runs, at the same time. I will again urge interested people to start this transition ASAP. There will be no deadline extension. As mentioned in the subject, the Haxx team (me, Björn, Linus and Kjell) will stop hosting most Rockbox related services on January 1st 2021. It should give everyone plenty of time to find new places and alternatives for everything that needs to survive. https://github.com/Rockbox/rockbox/wiki/Transition -- / daniel.haxx.se
Re: Haxx will stop hosting most Rockbox services after 2020
On Sat, Feb 08, 2020 at 12:38:14AM +0100, Daniel Stenberg via rockbox-dev wrote: > As mentioned in the subject, the Haxx team (me, Björn, Linus and Kjell) will > stop hosting most Rockbox related services on January 1st 2021. It should > give everyone plenty of time to find new places and alternatives for > everything that needs to survive. That's a remarkably generous timeframe, thank you! (On top of many, many years of generous hosting services, thank you again!) > https://github.com/Rockbox/rockbox/wiki/Transition (I started this conversation on IRC, but wanted to elaborate more here) The problem I see with some of those proposals is that it mixes both hosting migration and retooling, and the current level of user and developer interest doesn't seem to support a major retooling effort. It seems to me that the main problem with the existing infrastructure is a lack of general maintainance, and IMO it would take less overall work to actively maintain what we have than to completely retool. The fact that things still work as well as they do is a testament to how well they were put together, especially the build system. Migrating the existing infrastructure as-is to systems that current developers can maintain is IMO the best path forward. After the hosting crisis is mitigated, then we can turn our attention to making whatever incremental (or major!) changes we see fit, but on a more relaxed timeframe. I'm also not keen on retooling around proprietary services like github. I think being able to self-host is extremely important. So. If we're to migrate stuff off of the haxx infrastructure, we need to know more: * Is the existing *.rockbox.org stuff self-contained on a single dedicated server/VM, or are the services spread out onto multiple hosts? (If it's all self-contained, then migrating as-is will be a lot easier) (if it's not, then we'll need to know what the service dependencies are, eg php, database(s), and so forth) * What is the typical server resource load? (CPU, RAM, disk) * What is the typical bandwidth usage? (ideally on a per-service basis; I imagine serving the builds, followed by git & builder infrastructure, are the biggest users) I already self-host my entire digital presence [1], so depending on the answers to the above questions, I should be able to host all of the haxx-hosted rockbox services with only an incremental level of effort. I think DNS and @rockbox email/lists should probably move too, but those can probably be the last to go -- This way HAXX never has to be bothered about anything rockbox ever again. :) Anyway, thought I'd help keep the conversation going. The level of effort needed for various actions really depend on the details involved, and I think the more information we have, the better a plan we can come up with. [1] DNS, email & mailing lists, web (plus php and python), wikis, databases, git repos (gitolite + cgit), flyspray, xmpp, a rockbox builder, shell access, and more. This server is 12c Opteron, 32GB of ram, and about 5TB free RAID disk space, piggbacking on an uncapped fiber feed that routinely exceeds 500Mbps uplink bandwidth.) At home I have a lot more compute resources, with a private jenkins instance for my other F/OSS work, multiple VMs, and another rockbox builder... but with a very crappy 2Mbps uplink. I have a third site with a slightly crappier uplink that I was intending to set up with additional CI builders, but need to swap the server out first. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. signature.asc Description: PGP signature
