Jump to content

hyperion

Community Members
  • Posts

    894
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by hyperion

  1. 6 hours ago, Itms said:

    That's not how labels work on Gitea.

    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.

  2. 2 hours ago, Itms said:

    Yeah I figured that out, now are you advocating for 10-char hashes? 7-char? Something else?

    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.

     

    3 hours ago, Itms said:

    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.

    Well, white on light gray I have trouble reading.

     

    3 hours ago, Itms said:

    and since I'm not a designer

    Help! :P

     

    2 hours ago, Itms said:

    Can you be more specific, which alternative would you propose?

    Component instead of theme maybe, also make them key value pair labels?

     

    3 hours ago, Itms said:

    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.

    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.

     

    3 hours ago, Itms said:

    can try pascal case, but that wouldn't work for themes, so meh for the consistency

    White space would be fine me thinks.

     

    3 hours ago, Itms said:

    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.

    An indicator that there are just to many. Let's say open/closed for status is enough *runs*

  3. 35 minutes ago, Itms said:

    I can see that activity on that page but you are probably taking about a different one, can you send the URL?

    https://gitea.itms.ovh/issues should list a logged in users issues instance wide.

     

    48 minutes ago, Itms said:

    because the web view reduces the hash to a short version

    I almost always use git log from cli.

     

    37 minutes ago, Itms said:

    Is it the one at docs.wildfiregames.com?

    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.

  4. 19 minutes ago, Stan&#x60; said:

    Irc the goal was to get rid of trac since it gets completely absorbed in gitea. Then we can just make the domain point to the gitea for some time I guess ?

    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.

  5. 2 hours ago, Itms said:

    I hadn't realized that you had created an account instead

    np :)

    2 hours ago, Itms said:

    Can you check that you can edit the wiki but didn't get any extra permission for the repo nor the issues?

    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.

     

    3 hours ago, Itms said:
    6 hours ago, hyperion said:

    If not reasonably possible what is the path to make that instance read-only and possibly static html?

    The path is documented on the page Phabricator.

    Guess an acceptable compromise. Is there a similar document for trac becoming read-only?

  6. 53 minutes ago, Stan&#x60; said:

    I'm not sure you can migrate code comments and whatnot on Gitea.

    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.

     

  7. On 04/04/2024 at 9:38 PM, Itms said:

    - code.itms.ovh A registration-disabled copy of Phabricator, upgraded to the latest version (RIP).

    All the inactive accounts were deleted, especially the dormant spam accounts.

    This should stay up as much as possible. We need to keep all the discussions on patches and commits. TODO: I need to find a (possibly ugly) way to disable the upload of new diffs.

    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?

  8. 16 minutes ago, Itms said:

    Can you point out a few instances of commit messages where something else than the first line would benefit from being wrapped?

    Guess there are many, one with questionable wrapping is fc5518a22b15827c7f4d4410c27dad4c628af8a4 and on that got worse with rev to sha is 9f85b097e11ffac38df23815a62b14bd25925d2d

     

    19 minutes ago, Itms said:

    rely less on assumptions

    you can't change human nature :)

     

    21 minutes ago, Itms said:

    Yes, but in a private repo.

    Needs to be made public before the actual migration so others can verify the migration, but can wait.

    • Like 1
  9. 50 minutes ago, Itms said:

    I'd like to keep trunk for historical/nostalgic reasons, and also because I'd like us to explicitly follow a trunk-based development model. I am open to discussion about that.

    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.

     

    57 minutes ago, Itms said:

    TracUser is a Gitea account I created specifically for messages originating from people who have no account on Trac, and thus no account from migration on Gitea. This covers two cases: people who posted once on Trac without registering with an email address; and people who deleted their Trac account. This has no relationship with CI/CD.

    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.

     

    1 hour ago, Itms said:

    Mh I can probably group the Phabricator-related lines indeed, but I'm not sure it makes much of a difference. If others want me to do that, please weigh in.

    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.

     

    1 hour ago, Itms said:

    Could you come up with a script that performs that rewrap? I am not sure how to perform this in a way that provides a satisfying result for all commit messages.

    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.

     

     

  10. 1 hour ago, Itms said:

    No, please post everything here, I'm following. And this is just an unofficial PoC for now, please don't report bugs on Trac.

    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

     

    1 hour ago, Itms said:

    No! That's the beauty of it! (yes I'm going to blow my own horn quite a bit in this thread, sorry). Forks do not duplicate LFS storage. So every fork of 0 A.D. only weighs 100MiB.

    If the underling file system allows sharing extends this should be even less.

     

     

    • Like 1
  11. @Itms

    Glad to see progress was made and we might have an improved workflow in the not so distant future. Appreciated.

    I wonder if it would make sense to create a subforum for the git migration and keep this topic as a means for informing the community about the general progress. I already see me bringing up various issues which each might warrant a discussion. Putting them into separate threads would help keep some order at least and help avoid duplicate reports to some extent. Or maybe we simply should use trac?

    • Like 1
    • Thanks 1
  12. 1 hour ago, ShadowOfHassen said:

    I think for some reason, you're making it seem much more complicated, @hyperion than I've seen it with even the flatpak people. I don't see how it would be hard, to say, "hey people who are currently doing a fine job with maintaining the Flathub, how about we make this official?" And then have them help the dev team maintain it.

    If Redhat trust the people they have given commit access to flathub they can just put the trusted label on it and users can chose to trust Redhat or not, done. Upstream endorsing downstream is backward, why should upstream endorse Canonical and Redhat but not all the other distributors? Maybe you realize there is as much politics in this as other reasons.

    If upstreams aren't serious about it and just randomly hand out dozens of endorsements then it's a disservice to the end user and being serious means work, no way around it.

  13. 1 hour ago, ShadowOfHassen said:

    I am certain if you just did flatpak and snap, it would be much cheaper than helping to maintain the 12+ different package repositories for the Linux distros?

    Those distribution builds are done by distribution maintainers and not wfg. Sure sometimes they run into issues and might ask a quetion or two but more often than not they provide patches and it can be considered a net win for the project. From the viewpoint of wfg flatpack is just yet another binary repo. That reminds me of https://xkcd.com/927/

     

    1 hour ago, ShadowOfHassen said:

    I don't know how much you use Linux, but it is really bad to use wine with a game with an installer.

    I'm a Linux user for 30 years and still not yet a fundamentalist. What I expect from binaries is that I could build them myself and that they are from a trusted source, also I want to get notified of security issues and them being taken care of in a professional and timely manner. Lastly it should be functional. This is what a distribution maintainer is for and if you want to take care of flatpack you will have to take up the same role.

    Whether the binary format is PE, ELF or Mach-O I don't care and don't see why I should. So the really bad I really don't understand.

     

    1 hour ago, ShadowOfHassen said:

    using wine increases the raw system power you need on a device

    Wine is a recursive acronym for wine is not an emulator. Sometimes a software actually runs faster in wine than on Windows. I remember getting about twice the FPS  for Diablo II. Ofc an Linux package is preferable all else equal.

     

    1 hour ago, ShadowOfHassen said:

    Native means, It's built specifically for Linux.

    Debian builds for 4 different archs https://packages.debian.org/stable/0ad, so no single binary to rule them all. There are more archs than that running Linux, some somewhat recent patches suggest people also want to run 0ad on risc-v and e2k.

     

    2 hours ago, ShadowOfHassen said:

    Does it cost something for WFG to make a Linux build? Even when people like me volunteer to help?

    Not money but man-hours. Half a day would be not unusual I'd estimate. Add to that that bugs with that package would be come our bugs instead of theirs.

    If you want to help I guess you'd have to be familiar with building from source, packaging software, willing to commit for several years, live in a country were law can reach you and possibly meet a current developer IRL for exchanging keys.

    • Like 1
  14. 20 minutes ago, ShadowOfHassen said:

    No. Why should I? I have native Linux builds.

    Why would you mind the unverified label for flatpack? ;)

    Also what does native mean? After all the exe is a native x86 binary and flatpack isn't a native distribution package.

    Using wine gets you a 0-day trusted binary path at basically no cost for wfg. The cost for a release I'd argue is already in the unhealthy territory. I fully understand that this might not be the most favorite solution for a small set of users but my standpoint is providing the sources is good enough and beyond that is adding bells and whistles.

  15. 52 minutes ago, Stan&#x60; said:

    Does it even run ?

    Few years ago I tried and hwdetect triggered an error due to numa not being implemented in wine, the error dialog offered a continue button and so I continued and from there the game ran just fine. If this is still the case just dropping numa detection which we don't make use of in the the first place would allow us to have a viable alternative to offer a "trusted" binary for the impatient beside the just build it yourself (tm).

    While it is true that a distro might lag a lot, those listed as the most popular were all reasonably fast to offer the latest version in the past as far as I remember.

  16. 1 hour ago, Grautvornix said:

    I do agree that historical leaders are preferred. Just in case we cannot come up with enough famous names we should not restrict ourselves and instead add additional "normal" names of that civ/period.

    We don't strictly need 8 names, I mean I can play against 3 or maybe 4 before I get badly beaten. So in most games a single name per civ would be already enough. Using made up names would undermine the point made by @Stan` which I quite like. So requiring 8 names doesn't sound that great.

×
×
  • Create New...