On Tue, Mar 8, 2022 at 8:51 AM José Abílio Matos <jama...@lyx.org> wrote:
> On Tuesday, 8 March 2022 01.53.10 WET Scott Kostyshak wrote: > > > Thanks, Joel! I've been complaining several years that we should switch, > > > but I don't do anything about it :). And I still have no plans to > > > volunteer. > > > > > > Scott > > There are several examples of transitions like that: > > https://lwn.net/Articles/885854/ > > In that article from LWN there are references to other moves like llvm. > > So it not so much is the move is worth, certainly it is in the sense that > the administration of a infrastructure takes lots of time. The next issue > is when should it be done, before a release, 6 months after a major > release, etc... > > -- > > José Abílio > Colleagues, Thanks for reinvigorating this discussion. Regarding José's link: indeed, I did some similar reading a while ago and it seems the only constant is change, as projects have migrated around. Those projects using Trac have variously reported success, and from what I found it seems like newer versions of Trac have improved exporters relative to what I understand LyX's version has available. We effectively have a SQLite dump available that then needs to be parsed. Once parsed, we need to then import into the preferred interface. For this sort of thing, I prefer Gitlab over Github (mainly because of the tighter integration of services—see PS line if interested). To that end, I tested an import of ~1,500 LyX issues into Gitlab about a year ago, which is about 10% of the tickets. That's about the upper limit of import size, which just means we'll need to do ~10 chunked imports. I see no problem with this. To JMarc's question on what works and what doesn't. Importing issue data is clunky, but functional. We cannot import individual comments as Gitlab comments (as far as I can tell), but we can structure comments in the issue description to read sensibly. Importing issue attachments and cross-referencing the files to the issues is something I couldn't get working, is complicated, but I have some ideas about how to get working. It is surely worth looking back at this since a year has elapsed since I last did this. Also, a coordination challenge: to get issues properly linked to human actors (submitters, commenters, etc.), it appears that we'll want to have individuals register an account with Gitlab *before* the import. I'm sure we won't get 100% coverage, but I hope we can "put the word out" on the various LyX lists to drive this registration, to collect such user IDs, to ultimately best link the imported data to real people. To Scott's observation that we likely need *a* volunteer who is highly motivated and has time... I'm happy to continue working with this if the prevailing opinion supports such a migration. On the subject of when and how to do this: much prototyping can be done before a "real migration". I still have the Python script I was using to process Trac data into Gitlab-importable artifacts. The real migration will likely be a matter of closing issue activity over the course of a weekend to permit export from Trac and import to Gitlab. Regarding when that weekend should be: after a release seems reasonable, but I'm unsure whether we need to hold ourselves to any such schedule because a significant rift in workflow will result, and there's likely no "good" time for that. If we do have the prevailing opinion that we want to move ahead, some next steps I see: 1. I would ask active LyX developers/maintainers interested in assisting me with sanity checks and testing to create a Gitlab.com account and send me (privately) your user ID. With that, I can add those individuals to the private project where I've been doing my prototyping. I want to keep the project private until I can get a sanity check from trusted LyX maintainers that I'm not failing to consider any privacy or security issues. 2. Once confirmed, I'd like to open up the current prototype Gitlab site to be publicly accessible and solicit broader feedback (likely on this list, though not limited just to trusted LyX maintainers but all interested parties). 3. Incorporate the aforementioned feedback into the output processing that's already there, and perform a prototype migration to a (different) test project. This prototype migration would not require any Trac outage, etc. With the outcome of the third step, we can determine go/no-go on a real migration and coordinate when to do that, with particular consideration for getting all available folks registered beforehand but not bothering everyone too early in case we can't ensure clear success. I look forward to everyone's thoughts on these points and this approach. Thank you, Joel P.S. Some remarks on other Gitlab experience: I coordinate a Gitlab-based project related to experimental and evaluated nuclear data processing here <https://gitlab.com/ASTM_E10_Data_Collator/ASTM_E10_Produce_Figures>, which makes extensive use of CI/CD, Docker, and Gitlab's pages to deploy "the end product <https://astm_e10_data_collator.gitlab.io/ASTM_E10_Produce_Figures/>." It is this tight integration of services that makes me strongly prefer Gitlab over rivals, though I will admit that Github has matured significantly in this respect over the last few years. Minor discussion on this site is available here <https://www.osti.gov/biblio/1825393-workshop-using-git-based-repository-astm-committee-technical-knowledge-capture> in the form of a workshop presentation...made in LyX. ;-)
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
