pimutils / meta Goto Github PK

https://www.reddit.com/r/Python/comments/5ohv6k/rgsoc_call_for_oss_projects/

I am considering applying the entire pimutils org (or rather, {khal, vdirsyncer, todoman}). @geier says he has no time at that point to be mentoring for khal, but I wonder whether it'd be possible for you @hobarrera? Particularly todoman seems like a good project to get started with because of the relatively clean codebase (and ease to set up, vdirsyncer not really necessary).

Vdirsyncer doesn't appear to be a very beginner-friendly project to me. Also I wouldn't know which open tasks to pick for RGSoC.

The website is currently built so that it is pushed to gh-pages. However, github actions allows you to deploy the build without creating a git branch. Example: https://github.com/untitaker/blog

Unrelated, but I have had problems making github pages provision a TLS certificate for this website. So the way this setup currently works is:

• github pages is configured with pimutils.org CNAME, but does not serve https with correct certificates
• in front there's cloudflare's proxy, which does the actual TLS termination.

I would like to move away from cloudflare. In order to do that, github needs to start serving https correctly. I believe that may be possible if the "more modern" github pages deployment setup is being used. The same issue disappeared on my private blog once I started deploying via the official github pages action.

cc @WhyNotHugo

I've registered #pimutils but don't know how to set up a redirect.

For instance, khal 0.8 doesn't, and neither does the fresh vdirsyncer. Could we have a table like the one below about the raised concern?

I intend to publish the vdir storage format as a standalone page. Ideally, something like https://vdir.pimutils.org.

Currently, the vdir storage format is documented in vdirsyncer's documentation. This somewhat gives the impression of being an implementation detail of vdirsyncer. I'd like to push it a bit more as a standard which other desktop clients can rely on. I intend for different applications that support a vdir storage to point here for canonical documentation.

I will likely keep this single-page, with the spec itself and some FAQ at the bottom -- nothing too fancy really, it's all about the content itself. I do intent to reword some bits, without changing meaning.

I will take into considerations proposals to enhance the spec, within reason, but honestly have nothing in mind and don't want anything incompatible with existing tools. It does low-key bother me that filenames themselves are meaningless, but I also don't have obvious suggestions for improving this. Trying to represent internal data in filenames (e.g.: DTSTART or whether an item is recurring) would have the side-effect of requiring a filename change when content changes -- this is no acceptable.

I think that proper extensions should become mandatory tho (e.g.: ics to icalendar, vcf for vcard, etc). This prevents conflicts with metadata files and makes the content-type self-describing.

Comments, @geier, @untitaker ?

@geier While reply-all-ing to some mail to [email protected] it seems that the email address in the title bounces. Is contact2020 the new address?

Or should we remove the address altogether? It hasn't received any legitimate mail in a while.

vdirsyncer and khal currently suggest that packagers subscribe to the GitHub tags feed for updates.

@part1zano wants a system that emails him. My concern is that in this case packagers can't really choose which notifications they recieve and which not. If I start mentioning the packaging team for each vdirsyncer release, people who are only responsible for khal are notified and vice-versa.

Are there any other preferences, @pimutils/packaging?

Khard still has users who are excited to use and contribute to it: lucc/khard#96

Unfortunately the current maintainer is so inactive, they haven’t found the time to reply to a request to fork in many months: lucc/khard#144

Is pimutils interested in supporting whatever-khard-becomes? At the very least, we need more than one person with commit access, release access, and authority to grant that access to new maintainers.

I've registered the domain pimutils.org. I don't really know yet what to put on it, but right now I can't even find a proper static site host that does SSL with own domains. I suspect that GitLab Pages works better in this regard than GitHub's, but if we're about to split up our infrastructure like that, we might as well host on a proper server.

Rather than manually creating labels on each project, I'd really like to have these standardized (eg: needs tests, glitch, bug, etc) for all of pimutils.

repo-utils/org-labels might help us maintain this (and copy labels to todoman, which currently only has one or two), though me need to make sure we actually standardize them on every repo first.

How does everyone feel about this?

cc @untitaker @geier (I think we should all watch this repo).

Since the packages no longer support python2 (as for the fresher versions at least), could everyone change the shabang in scripts from #!/usr/bin/env python to #!/usr/bin/env python3? That would make my life a bit less painful. Thank you in advance.