hyperion

Which doesn't make sense to me, also I have seen it in the wild. To render scoped labels as they call it as scoped labels only if they are also exclusive is counterintuitive. I'm not alone thinking such https://github.com/go-gitea/gitea/pull/23164/commits/c278def8e3441783b1c07c67bd4bf208d487950b There are open bugs for broken/bad contrast algorithm, so for now choosing colors that work is what one can do. The activity labels are pointless. "reviewer-needed" is true for any open pull request by virtue of being open. Does "under-review" have any connotation other than I grabbed that PR and anyone else should stfu? "work-in-progress" is just the unsafe way to mark a PR as WIP. The "resolved" are also not ideal as it stands for closed, however needs-info could just as well be kept open and only if we don't hear from a user over a certain time close it. Also fixed is closed without any tag. I think it would also make sense to merge priority labels 4 and 5. Basically low medium high and bricked are enough.

7-char will blow up on us, 10-char is just about acceptable, rough approximation: $ bc <<< "scale=15; commits=25000; digits=10; commits^2 / (2*(16^digits))" .000284217094304 Whatever should be added to gitconfig, also remember commands like revert will pre-populate the commit message with full hash. Well, white on light gray I have trouble reading. Help! Component instead of theme maybe, also make them key value pair labels? Coloring the value portion of the label is separate from coloring the key portion, I only suggest the key portion to be the same across a label type. White space would be fine me thinks. An indicator that there are just to many. Let's say open/closed for status is enough *runs*

https://gitea.itms.ovh/issues should list a logged in users issues instance wide. I almost always use git log from cli. That one works, tho the one I had in mind was a tweaked version of the one on play0ad IIRC. Use what you deem fit. While we are discussing UI, the labels are somewhat messy. The color scheme makes it a bit hard to read them, maybe a bit more muted would be better. Those theme/.. labels should be changed to some more meaningful text, theme/core-engine feels just wrong. The type portion of labels should probably have same color for labels of the same type. The priority labels using kebab case feels meh, also starting with a number is not needed. The time tracking feature for issues probably should be disabled, don't think we will use it.

Similar but better looking if I'm not completely wrong I meant the gitea instance hosted at git.wildfiregames.com at some point. I think it was based off of the one on play0ad.com

I guess that is what the adriane tool mentioned is meant for but a draft document outlining the plan would allow us to actually comment on not just guesses @Itms , I remember @Stan` had a header header which look quite slick for his PoC, maybe you could reuse it (didn't screenshot it). Would give the instance a cooperate branding / personal touch and would give the links leaving the instance a separate place to live as having them mixed feels not that great tbh.

np Can't edit the wiki with the new account, same for bugs and I just assume I can't push either. About bugs guess we need a group as well, @Langbart's work would be a good example for the bug-wrangler role. The path is documented on the page Phabricator. Guess an acceptable compromise. Is there a similar document for trac becoming read-only?

If no third party did the tooling then us writing it with the available developer time budget is probably unrealistic even if theoretically possible (gitea supports inline comments). However, there is no way around that at some point phab must be read-only, ideally at the time of migration. Simply opening an issue on gitea with a link to a differential would be a simple albeit subpar solution.

Why not migrate them to gitea pull requests? I remember blender intending to do so and having some success in tooling at some point. If not reasonably possible what is the path to make that instance read-only and possibly static html? How are editing wiki and bugs to be handled? Give everyone access as now done on track?

Fair enough maybe dump them into a wfg/issues repo with only a readme as source instead? Opened a bug with a dummy account, but none are listed in the created by you section of the user

Also we have website / forum bugs on trac, moving them into 0ad source repo seems wrong

Another thing that comes to mind is milestone for bugs, useless and only causes pushing back over and over again ... People work on a ticked if they feel like it, so pretending otherwise doesn't do good to anyone.

Guess there are many, one with questionable wrapping is fc5518a22b15827c7f4d4410c27dad4c628af8a4 and on that got worse with rev to sha is 9f85b097e11ffac38df23815a62b14bd25925d2d you can't change human nature Needs to be made public before the actual migration so others can verify the migration, but can wait.

I don't really mind but @ShadowOfHassen above was puzzled with the outcome of "git pull --tags origin main", so it's safe to assume there is a certain expectation. Ok, but then maybe using Ghost like github or similar would be better to indicate the intent of it being a removed/invalid user. Could also be used in future for deleted users without awkwardness. It helps distinguishing metadata from commit message, the linux kernel and many other projects do this as well, guess it would also be good to follow this convention in the future. Is the source of the whole migration available somewhere? Anyway a first simple solution from the top of my head :set textwidth=72 :normal gggqG :wq save the above as rewrap.vim and run as vim -es -S rewrap.vim message.txt Maybe wrapping the first line (subject) is undesirable though. Anyway looking at the result should shed some light on what to improve. Coreutils has commands to similar effect IIRC, would have to dig through man pages tho. But they might fit better into the migration pipeline in the end.

Fine, let me add some random findings in short form: default branch name trunk -> main maybe Pascal case generates a link on trac, maybe camel case as well. The migration script ideally filters such broken links. Example: https://gitea.itms.ovh/wfg/0ad/issues/6796 https://gitea.itms.ovh/TracUser should probably be renamed, at least if it's used in future for automation in commit messages patch by, comments by, reviewed by, svn commit id probably should be a block, ie. no empty lines in between might want to rewrap commit messages at width 72, some weren't wrapped at all and some are wrapped poorly after changing svn rev with the much longer commit hash If the underling file system allows sharing extends this should be even less.

The technical issue is fairly well summed up by Sam James from Gentoo at https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 A rather good video by Theo discussing the human component of the exploit: