Move freetype-py to Freetype organisation ?

[rougier]

Hi all,

I've not been very active on freetype-py for a few months (or years) and this might be a good time to move freetype-py to the freetype organisation, what do yout think?

Note that I'm perfectly ok if you prefer to leave the repo here but still, it might be easier to have it under the umbrella of the freetype org.

[anthrotype]

Thanks, that sounds like a good idea. Although the Github freetype organization doesn't seem very active, and is mostly just a mirror of https://gitlab.freedesktop.org/freetype/ which is the official one. Maybe you should reach out to [email protected] to see if Werner and others maintainers are interested in moving freetype-py over there?

[rougier]

That could be solution yes. Since you (and others) will be the most impacted (gitlab vs github), I let you decide what is best. If the gitlab solution is possible, I think we can archive this repo to keep issues but I fear the transition won't be so smooth with issues open on both github/gitlab for a few weeks.

[apodtele]

Migrating freetype-py to https://gitlab.freedesktop.org/freetype/ makes sense. I think it is possible to migrate all issues, then stop accepting them here.

@lemzwerg Agreed?

@AnuthaDev helped us previously. Please advice.

[HinTak]

I am not sure it makes any difference. It is not as if there are more python-knowledgeable people over there. Put it plainly, I am opposed to re-org for the reason of re-org.

[lemzwerg]

Well, FreeType on github is really just a mirror and nothing else – we actively discourage to open any issues there to avoid stuff distributed over two sites. So if freetype-py should ever be moved, it should go to the same place where FreeType resides, i.e., gitlab.freedesktop.org, as Alexei pointed out. Later on, a mirror to github could be created.

However, Hin-Tak has a point – moving just for the sake of moving doesn't make sense since we (i.e., Alexei, Toshiya, and I) don't have the manpower to maintain another piece of software.

In general, I don't oppose to a move (if I don't have to do it 🙂), but what exactly are the benefits?

[apodtele]

Co-localization might result in cross-promotion.

Our docwriter is python. Perhaps @nikramakrishnan will get involved.

[HinTak]

It is not as if one party are not unaware of the other party. I, for myself, regularly "advertise" on freetype-devel interesting things about freetype-py, like the ot-svg examples. Not a lot of interests. The other direction, I don't think anybody else on freetype-py even tries to build freetype or freetype2-demos . The disinterest is quite mutual...

[HinTak]

I just ran git log --since=2019-01-01 ... freetype/ examples/ | grep '^Author' | ... to get a 5-year stats of who did anything API or examples-wise. Not to under-estimate others' contribution, but just separating the generic "any python-based project" / "any software projects" changes, vs changes specific to interacting with freetype lib.

Out of 80 commits: 51 from me, 8 from Takaaki of Morisawa, 6 from Josh Hadley of Adobe. Then 3 from a 163.com address. The rest are 1 or 2 per person.

If anything, this probably indicates that should @rougier wants to stop, he should transfer the project to me...

If you run the same command for the whole repo, you get 162 commits (about double that). I still come top at 58, follow by Nikolaus of Daltonmaag at ~34, then Cosimo of Google at 14, then @rougier at 13.

I would say that besides me, the other represent corporate interests. Actually I don't quite agree with bundling freetype and harfbuzz (a big part of those 34+14), for example; and I suspect freetype org doesn't like that part (bundling a private copy of freetype and harfbuzz) either.

[NCBM]

We almost agree that the project should be transferred to a place where it will be maintained well. The only controversy is where to go.

Personally I would prefer the project transferred to those who would relatively actively maintain it like HinTak.

The latest release now is almost a year and a half old - such a long time. I hope the project will go further.

In addition, I must clarify that my 163.com e-mail address is a free e-mail service similar to Gmail, and it is convenient for me since it runs in China.

[HinTak]

I would disagree with and question (1) it not maintained well, (2) a year and half between release is too long, (3) moving the project would magically get more people working on it.

Freetype itself is fairly old (freetype 2 is 25+ years old, and if you count freetype 1, that goes to 30+), there are very few "interesting" changes that requires addition/changes to freetype-py. People who want more generic pythonic/non-freetype-driven changes like improving the packaging etc are already contributing. More frequent releases and go further, in what direction?

[NCBM]

I'm sorry that I leave my comment mainly because the latest release is too old. I've just realized that works around freetype is generally not so interesting. I should expect enough maintainence instead of saying "go further". Sorry for my misleading comment.

[HinTak]

I have a quick look at the changes/additions since May 2023, and there are indeed interesting additions since. So asking for a new release is fair. But that's a different request. Looking at the releases, it looks like all past 6 years of releases were done by Nikolaus without exceptions; but I believe Nikolsus is not the only one. That's a somewhat interesting situation - when somebody is/was working on an open-source project partly as his day job, what happens when he leaves his job / is fired, or his employer changes directions and prefers/mandates him spending time on something else?

Anyway, @rougier do I have enough access to make a release? In particular, do you need to do something on pypi, like invite me to join there or something? I already do the monthly releases of skia-python there since about a year ago, and I think I can do most things except approving my own pull 🙃. (So if the owner disappears, I might have to register a dummy github account, create pull there, then approve myself from my main account ...)

[HinTak]

@rougier @madig I think I established that I don't/can't make release that propagates to pypi either via the older /deprecated API or the newer truster publisher API (tried releasing 2.5.0 with either, and failed). I suspect the latter needs a configuration addtion on the pypi side. anyway, my account on the pypi side should be whatever skia-python's says, so if you add my account as a colaborator to that side, and/or adding github CI as a trusted publisher, that would be simpler.

[HinTak]

@rougier @madig I cleaned up but left the two failure CI logs, if you want to see what fails. I think there is a configuration setting on the pypi side to switch to trusted pubblishers.

[rougier]

Sorry for long delay. I just read the whiel thread and I think ti would make sense to transfer the project to @HinTak since you're de facto the maintainer. As for pypi, I'm not sure what is the procedure.

[HinTak]

@rougier for now, adding my handle https://pypi.org/user/HinTak/ on the pypi side would be good to see if I can get a release out.

[madig]

@HinTak I sent you a PyPI invite.

[HinTak]

@madig thanks, I accepted it, but can't get to the trusted publisher setting. Skia-python has a setting at (I don't think this is any deep secret as the other half is in github)

https://pypi.org/manage/project/skia-python/settings/publishing/

Which says:

We should add the equivalent.
Moving to trusted publisher is what pypi recommends when they added the 2FA stuff a year ago.

[madig]

Ok, I added it :) Try it.

[HinTak]

@madig okay, took a bit of trial and error to get the wheels out in 2.5.1 (2.5.0 went to pypi without wheels, so wasn't appropriate to delete and re-try). So that's at least one small problem solved - whoever can tag and release on github will have the result uploaded to pypi. So that get around the twine user/secret (is that per user or per project?) legacy issue.

[madig]

Cool, thanks. I haven't looked at deploy setups in a long time. I think twine secrets are per project, because you set them as secret variables.

[HinTak]

But where are the secrets kept on the github side? I.e. how did it allow multiple people to make releases in the older pre-trusted-publisher setup?

[anthrotype]

The secrets are per repository, decrypted only when the workflow is run from the main repo and not from a fork.

[anthrotype]

If the previous secrets encoded some personal pypi token or password, then it would appear on the pypi side as if that particular user had uploaded the packages.

[anthrotype]

All collaborators with commit access can make releases and push git tags to GitHub, which trigger the deployment workflow. That is separate from the authentication details with PyPi.

[HinTak]

I believe the twine-secrets based pypi release process was broken (github-wide) a few months ago - they requested 2FA a year ago, deprecated twine-based release also then and suggested people moving to trusted publishers then. Then they broken the old work flow 6 months later, after a deprecation period. It broke between Dec 5 2023 and Jan 2x 2024 - sounds like probably there was a public deadline announcement for 1st Jan 2024 somewhere.

I checked the skia-python release log - all the monthly-ish releases since last autumn were from me. I made 3 releases under the old system, it broken, and we did the migration, then made another 5. Since the two releases were only 6 weeks apart, it is definitely something the github/pypi did to stop the old process.

[HinTak]

Anyway,
https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/

#152 (comment)