New package: dankcalendar v0.1.4

[Purian23]

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the package requirements: YES

This package provides dankcalendar, dcal is a standalone calendar app that brings your Local, Google, Microsoft, CalDAV, and iCloud calendars together in one place. It runs as a lightweight daemon with a tray icon, keeps your accounts in sync in the background, and reminds you about events, all with the look and feel of DankMaterialShell. It syncs native support perfectly to the inbound DankMaterialShell (DMS) package submission.

Local build testing

• I built this PR locally for my native architecture, (x86_64)
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • aarch64

https://danklinux.com/docs/dankcalendar//

[ahesford]

This project is too nascent to consider packaging for Void. We expect software projects to exhibit an established history of stable releases at a cadence appropriate for distribution packages.

Furthermore, you appear to be a representative of the organization that owns this project. We do not generally accept new packages submitted by upstream maintainers. This is particularly true when the submitter is a new contributor without a demonstrated record of good package stewardship.

[Purian23]

This project is too nascent to consider packaging for Void. We expect software projects to exhibit an established history of stable releases at a cadence appropriate for distribution packages.

Furthermore, you appear to be a representative of the organization that owns this project. We do not generally accept new packages submitted by upstream maintainers. This is particularly true when the submitter is a new contributor without a demonstrated record of good package stewardship.

Hi there, thank you for your feedback, however I believe these may have all been closed prematurely. The first 3 packages that were submitted are well established with a history of just under a year old. The only exclusion to this would be DankCalendar, as it has just been released a couple of weeks back publicly, which is where you based your starting decision here, understandably.

These packages are a precursor to the next one we intended to list, DankMaterialShell (DMS). The packages have been maintained on our DankLinux repo on Debian, Ubuntu, Arch Linux, RHEL, CentOS, NixOS, Gentoo, and OpenSUSE. Furthermore, they span across the AUR, Copr, Nix, Gentoo Guru and OBS build systems.

DMS has been Officially listed on Arch Linux, NixOS, and Fedora mainstream repos.

Void Linux was next up on our roadmap. I am more than happy to resubmit them from our Avenge Media Org account to match the flow of how we list the others. I look forward to hearing your feedback, we would like to offer official support to our Void Linux users too.

[ahesford]

We do not generally accept submissions from upstream maintainers, especially when those maintainers are new contributors to Void, for two important reasons. First, submissions from upstream maintainers more interested in broad distribution support than the quality of the Void package itself are much more likely to overlook specifics of the Void package. This is especially detrimental when a package breaks, and the upstream maintainer preserves only a tenuous connection to Void. Second, we generally prefer third parties (and known Void contributors) maintain package templates because it provides an independent check on the quality of releases before updates are submitted.

Although the second consideration may occasionally be relaxed, we tend to do so only for well-known contributors that maintain active engagement with the core team and are known to provide reliable maintenance of their packages.

[Purian23]

Hi @ahesford, thanks again for your time here. I’d like to take a moment to respectfully request some additional consideration for our team. Over the past year, we’ve shown a strong, consistent commitment to our project and to every distribution we’ve packaged for. This reflects not only broad coverage, but in the quality and reliability of our packaging work across all platforms.

As I understand, you maintain the niri wm here on Void. Our team collaborates in a shared Discord server and works closely with the niri developer so we can offer official first‑party support to those users. Quickshell, which appears to be maintained on Void by @classabbyamp is another package we use natively within DMS. I bring these up as our team is responsible first hand for listing and maintaining these packages and more on many distributions as can been seen in Fedora, Debian/openSUSE & Ubuntu.

The request from here would be to extend some additional consideration, or potentially join as one of the members who help verify our packages with the possibility of handing them off to us later once you’ve seen a consistent record of good standing.

Thank you, Purian23