Itms

I regenerated the repo and associated data (that broke some links, I can't do much except rewiping the databases and users, which I'll try to avoid doing too frequently). I'm going to stop changing/fixing bugs in the PoC for now, thanks for all the reports and testing. I am now going to focus on the Unix build environment and the setting up of CI/CD. Changelog: git repository: - used short hashes in messages (I didn't have to choose the length, git automatically chose 10 chars) - wrapped the content of commit messages to 72 chars, ignoring the first line - grouped metadata lines in commit messages as much as possible (my regexp detects "[...] by:" and "Differential Revision:" but not for instance Trac tickets:, I can't cover and test all cases) - handle phab: links and [Pp]hab: links to non-commits - added a Bugs herder team Imported issues: - updated label display (typography/color), removed activity labels - disabled time tracking - do not publish a Patch change if the new value is empty wiki documentation: - added notices to install git LFS - adapted contents to label improvement Cosmetics: - added link to docs.wildfiregames.com in top menu Future branch: - merged Stan's update to .gitignore In gitea 1.22 (currently RC, will upgrade when it's released): - command-line instructions to merge will be adapted to our merge strategies - username will be correctly used instead of real name in commit feeds (including the RSS consumed by the IRC bot) Didn't do: - rename TracUser, I really think it's important to be explicit about the fact content comes from Trac - keep the Trac registration date of users... because Trac doesn't record that at all (only the last activity date) - I cannot reproduce @hyperion problem with "issues created by me"

Why not! But that would have to link with the migration. They can be moved now or later, in both cases I'll preserve them. No need at all! Images can be retrieved from a remote URL, for instance on play0ad.com, or from the nightly-build SVN. It's okay, it's still kinda maintained, and as long as it doesn't break, we don't need to fix it. But there are indeed more popular choices for C++ test frameworks nowadays. That's also unrelated to the migration. My changes to the build environment will probably supersede those interesting diffs you linked.

Oh I misunderstood your previous message, sorry! I thought you were suggesting doing things, but you were questioning/proposing improvements on what I did. Please go ahead and make a PR The bat files are used in the Windows installer I think, no need to make sh equivalents when we have a .desktop file. Converting to Markdown is a must, but it would indeed be great to deduplicate things that go to the wiki. Instead it would be awesome to have a readme.md which is actually appealing, with screenshots and a user-orientated presentation of the project. I have not worked in that direction but I'd love to see it done. I have already planned to remove svn-related binaries, but I have decided not to remove premake and cxxtestgen. Those are very lightweight binaries, and keeping them really simplifies the Windows build process in the design I am proposing.

@Stan` Everything you listed in the latest message is either already covered or still WIP but planned in https://gitea.itms.ovh/Itms/0ad in what I called the "future" branch. Please test and propose alternative coloring if you have a strong opinion on the matter. That was not at all the aims I had in mind, I see how my wording was confusing. Please avoid deeming others' work "pointless" and being rude for no reason. I see that there is indeed overlap with other Gitea features. I wanted to make sure PRs without any reviewers would stand out. Instead of adding a "reviewer-needed" label, we could make a rule that reviewers assign themselves to PRs (which I hadn't realized is different from assigning one to an issue). That way, orphan PRs could be found with the "No assignees" filter. "under-review" is then already covered by the presence of assignees, and "work-in-progress" is covered by the "changes requested" display. This is a very good point, it would be great to be able to mark an issue as waiting on info without closing it. The "Due Date" feature would here be useful to keep track of when to close it. (still no found use for the Time Tracker which is a different feature) Well I could call that "closed". Order doesn't matter here since closed tickets should just have a "closed/resolved" and "theme" label. I disagree, there is an actual difference between "nice to have" (this would provide an actual benefit to the user or the devs, but low priority) and "if time permits" (this would be nice, but it either wouldn't change anything from the user pov, or the cost of doing it would counterbalance the small benefits). Then again, I just don't want to lose any information from Trac. Merging the labels can be done in the future if the team wishes.

Will take a look Another thing worth mentioning: I plan to delete all Trac accounts without content as part of the migration (using the Trac spam filter). I did not perform that in my PoC because I haven't set up the spam filter (useless in a read-only instance). As a consequence, I will only create Gitea users for active Trac accounts in the actual migration.

I would go with 10 to match the Gitea display, but maybe 12 would reassure me more. Scratch that, the Linux kernel uses 12, but that's overkill for us. I'll use 10. I am not planning to touch gitconfig in the repo. I specifically chose "theme" so that it is after activity/difficulty/priority (alphabetically). "topic" would also work. It is a less important label than those. I could prefix the label types with A/B/C like some projects do on Github, but I suspect you won't like it That's not how labels work on Gitea. I suggest you make your own label set in your test repository, so that you can see what the constraints are. What you call "key/value" pair labels are the "exclusive" labels, which is not the case for the theme. But reflecting on this now, Trac didn't leave the possibility to set multiple components for a ticket, so maybe I'm going too far by allowing multiple theme labels. Oh that's on me, I assumed that white space wasn't allowed. Thanks, I'll improve that then! (there is a possibility that the trac2gitea tool doesn't support it though, we will see) I kinda agree but right now all the labels are used, removing some would mean losing information from Trac. And I strongly believe we need the "activity" label or an equivalent, to triage PRs (and it needs to be the first label type, and to stand out) Interesting. That's stronger than preventing you to post. Oh that's easy to do, and I did it almost daily when testing my migration scripts I deleted your top-secret account. Also I unrestricted you, but I also have the option to prevent you from logging in, so I'm testing that. Can you confirm you can't login at all?

Yes I just restricted PoppaSmurf, I don't know how it appears to you. I can't contact users but I do have access to their email addresses (pretty much like in Trac). It is actually a good thing in my opinion that Gitea doesn't have a PM system. I would be unhappy so see communication even more split between platforms. Yes, I tested a while ago, it works. In the worst case I can debug that after the migration, emails can wait for a few days. I really don't want to test now and spam a wide public. I really had a hard time to decide between an organization and a user. Users need email addresses so I didn't really want that. Also I figured it might be handy to be able to add people to the organization if there is a need to manually edit imported Trac data... but that is realistically not going to happen. What do you mean about surprising? In terms of privacy you mean? (if yes, I tried to be precise in the privacy policy, and people who don't use Gravatar won't have their data sent there, so they are not supposed to complain unless I missed something). For the PoC, getting the profiles from Gravatar allows one to have a sense of the look and feel of the platform and of the community interactions. I wouldn't like to see everyone with generated avatars... For the actual migration, active users will be able to populate their profile, but IMO it would be a bit of a shame to leave all the old members of the community without a face. I'm very happy to see a profile pic associated with janwas or k776 for instance. Oh, that works for me, so that's a bug indeed. I'll track it and let you know Yeah I figured that out, now are you advocating for 10-char hashes? 7-char? Something else? I used the default color palette*, and since I'm not a designer, I try to trust the Gitea devs to have done their UX work. This can be changed at any time anyway, so I'm going to stay with those for the migration unless an artist offers insight. *apart for the new "activity" labels, so if your grudge was specifically against them, your concern is valid and I'll change those colors Can you be more specific, which alternative would you propose? I disagree, colors convey meaning for priorities or difficulties. I kept a single color for resolution, components, and ticket types. I don't have a strong opinion for the colors of the new "activity" label. I can try pascal case, but that wouldn't work for themes, so meh for the consistency Yes it is, labels are sorted alphanumerically (both in menus and in issue lists and previews), I need to group them and order them correctly for the users. I think you're correct. I'll check whether it's possible to disable that feature

Going through points I didn't address. As an admin, I see all repos including private ones. I'll try and write a regex for identifying metadata and grouping them. It is unfortunate that the empty line was mandatory for Phabricator to parse correctly the closing of differentials. The first one I agree. Long lines should be wrapped. Also added to my TODO board. For the second one, it looks perfect when viewed in gitea, because the web view reduces the hash to a short version. But I don't know if it's a good practice to use short hashes in the actual message. If yes, I suppose that 10-char hashes are unique enough for our use. But I haven't made up my mind. I can see that activity on that page but you are probably taking about a different one, can you send the URL? Yes indeed, ariadne is for that. I kinda documented it at HowToUseTrac. But there is no exact plan, basically there is no reason to shut down Trac (unlike Phabricator, it is still maintained) but no reason to keep it up either (since all of its contents can be migrated). I would advise caution and avoid stopping it right at the migration (I may have forgotten to migrate something, or I may have made a mistake in ariadne...). So considering the high amount of places redirecting to our Trac instance, I propose to keep it online for a couple months, maybe a year, before making the URLs point to the redirect tool. Is it the one at docs.wildfiregames.com? I also used it at svn.itms.ovh, but I had to fix a bit the CSS, which makes the width overflow, at least on Firefox. (width:100% is not compatible with having a padding).

A bare clone of my repo is 5.9 GiB. Unfortunately a checkout will take twice as much space (.git is 5.9GiB, binaries/ is the same size when LFS files are downloaded). On the other hand, on Gitea, the entire history of LFS files is stored, and that takes 13GiB, which is what is displayed in the web interface. Maybe I should make a change in the documentation, to avoid confusion, and write "12GiB" for the size of a checkout. So that people don't mix that up with the 13GiB of stored LFS files in Gitea. It's a coincidence the values are similar: it basically means that each asset of the game has on average two versions in history. If it was, say, three, the size of the LFS repo would be 18GiB while the checkout would still be 12. I think The SVN repos are not supposed to be web-visited so maybe not clutter the top bar, however adding the docs is a fantastic idea. I saw the huge progress on that front a couple days ago, congrats!

Oh @hyperion I hadn't realized that you had created an account instead of using your migrated Trac account. Thanks so much for your enthusiasm! I added you. Can you check that you can edit the wiki but didn't get any extra permission for the repo nor the issues? By the way, did uploading the Ubuntu ISO correctly fail?

It seems unrealistic to me to automatically convert SVN patches on arbitrary revisions to branches of git commits. Importing the discussions could probably be done but it's a huge amount of work I'm not interested in doing. The path is documented on the page Phabricator. Yes, I already created a Docs team with wiki edit access. But so far this post doesn't have a huge success, as almost nobody has asked for the password to their gitea account. So it hasn't been tested yet.

They are still served over SVN (svn.itms.ovh), with audio and art_source public; art private, I didn't change anything. None of that is in the git repo. I had to overcome a few issues arising from "svn copy" being used between repos, and I also had to expunge a few sensitive files from ps, that are private in SVN, those are not in the git repo either.

That's out of scope for the migration (and milestones are one of the rare features that perfectly match between Trac and Gitea...) . And I've been inactive for some time but the milestones were necessary to plan releases. That's true, but I can't drop those tickets during the migration. Maybe they can be moved to a different website repo if we start seriously versioning our website theme. Or maybe we should have a Wfg infrastructure repo. That will have to wait, and the corresponding label will stay in the meantime. Uuuuh once again that final slash looks highly suspicious. Not having ".git" is unusual but treating that as a directory seems wrong. I will try to upload things and trigger your errors during the weekend. But it would help if you'd send the commands you tried to run, and also the full output from git, because for an authentication issue I'd like to know if you are using a password manager, whether git prompted you for identifiers, etc. For the record, I uploaded the 0ad repo through ssh and the commits on the "future" branch with http,so both methods work, at least in some contexts.

I didn't look into that! You can test for sure, especially since I don't have access to the ircbots machine. Please test. It is supposed to fail/deny the upload. If it breaks I'll fix and learn a lesson, and the costs for this server are fixed, so no worries about that.

Well I suppose it should happen at the split, not before. Currently this repository is 0ad, since it contains the game assets. Also it is important to have a memorable and easy to type address. I am already reluctant to have called the repo wfg/0ad instead of 0ad/0ad, but the organization must be named wfg, so I settled with that. Don't you need ".git" at the end of the remote url? If not, that's an actual bug I have to take a look at. Please don't restrain yourself, test away. Better detect bottlenecks now.