Maintainer worklog

[adam-rocska]

This thread is a lightweight maintainer worklog for Kitura.

Use it for short notes about maintenance activity that does not need its own issue or pull request: triage sweeps, cleanup work, release prep, repository settings changes, dependency audits, CI observations, and project housekeeping.

Please keep actionable bugs, feature requests, and regressions in Issues or Pull Requests. This thread is for coordination and visibility, not task tracking.

2026-05-18 - @adam-rocska

• Started a maintainer cleanup pass across the Kitura GitHub organization.
• Created a local workspace README with the current Kitura repository inventory.
• Verified and deleted two empty org-level GitHub Projects after confirming they had no items, no descriptions, no readmes, and only default fields/views.
• Swept repository-level Projects: no current Projects v2 were attached to Kitura repositories.
• Closed and locked six high-confidence spam issues in Kitura/Health, and added a spam label there for future cleanup.
• Verified that normal closed issues remain open for follow-up comments as long as they are not locked, so users can ask maintainers to reopen stale/probably-fixed issues.
• Reviewed GitHub Discussions usage: Discussions are currently enabled only on Kitura/Kitura; this thread will be used as the shared maintainer activity log.
• Started a lightweight dependency-map audit based on static scanning of Package*.swift files across the org.
• Started the first concrete CI migration experiment in Kitura/SwiftKafka.
  • Opened and merged Kitura/SwiftKafka#17: migrated CI from Travis CI to GitHub Actions.
  • Removed stale Travis-specific setup paths, including setupKafka.sh and Package-Builder usage.
  • Added a conservative GitHub Actions baseline using Swift 5.0.1, Ubuntu Xenial, Kafka/Zookeeper 5.2.2, swift build, and swift test.
  • Updated README and generated documentation badges from Travis CI to GitHub Actions.
  • Constrained swift-log to 1.0.0..<1.2.0 so Swift 5.0.1 resolves a compatible version.
• Linked the SwiftKafka CI migration back to Kitura/Kitura#1560 as the first concrete step toward replacing Travis across the organization.
• Continued stale issue triage across multiple repositories.
  • Closed obsolete, non-actionable, unclear, or stale issues in Kitura, BlueSocket, BlueCryptor, BlueSSLService, and SwiftKafka.
  • Kept some older but still structurally relevant issues open for later modernization review instead of blindly closing everything.
• Triage examples:
  • Closed Kitura/Kitura#868 as no longer feasible in the current maintenance state.
  • Closed Kitura/Kitura#995 as obsolete/stale.
  • Kept Kitura/Kitura#897 on the radar as a future quality-control / memory regression testing item.
  • Kept Kitura/Kitura#729 on the radar as a future listener/threading modernization item.
  • Closed Kitura/BlueCryptor#19 as stale and not aligned with modern Swift API direction.
  • Closed stale or unclear BlueSocket issues including #204, #213, and #216.
  • Closed empty/non-actionable BlueSSLService#102.

[adam-rocska]

2026-05-19 - @adam-rocska

Continued the Kitura organization maintenance cleanup pass, focusing mainly on issue hygiene, stale issue review, and separating actionable technical debt from old support noise.

The goal of this pass was not to erase history, but to make the open issue lists useful again: close obsolete/non-actionable/support-only threads, keep technically relevant issues visible, and identify future modernization work.

Scope

• Reviewed open issues across the Kitura GitHub organization.
• Continued the issue triage started on 2026-05-18.
• Focused on:
  • stale support requests
  • already-resolved issues
  • environment/toolchain-specific historical reports
  • unclear or empty issues
  • valid bugs still worth preserving
  • modernization-relevant technical debt
• Avoided locking normal closed issues unless there was a spam/moderation reason, so users can still comment if a closed issue needs to be reconsidered.

Issue triage policy used

Issues were generally closed when they were:

• very old and no longer actionable;
• missing reproduction details;
• clearly usage/configuration support rather than a framework bug;
• already answered in the thread;
• tied to obsolete toolchain/platform states;
• duplicated by broader modernization work;
• announcements or coordination notes that no longer need to remain open.

Issues were generally kept open when they were:

• specific and reproducible;
• likely still technically valid;
• good candidates for future maintenance PRs;
• related to diagnostics, correctness, security, compatibility, or modernization;
• useful as design/architecture input for a future major cleanup.

Confirmed individual decisions

• Closed Kitura/Kitura#1493 as resolved/stale.

  • The reported static file/template path issue was caused by Xcode working-directory configuration.
  • The thread already contained the fix: enable a custom working directory.
  • The original reporter acknowledged the suggestion.

• Kept Kitura/SwiftKueryMySQL#60 open.

  • This is still a valid diagnostics bug.
  • The MySQL driver loses the original database error message and exposes a generic SwiftKuery.QueryError error 2.
  • The issue is specific, actionable, previously acknowledged by maintainers, and later confirmed by another user.
  • Good future candidate for a small correctness / developer-experience PR.

• Kept Kitura/Kitura-redis#75 open.

  • This appears to be a real command-construction bug.
  • zrangebyscore(_ key:min:max:) accepts a key parameter but does not pass it into the emitted ZRANGEBYSCORE command.
  • Good future candidate for a small low-risk bugfix.

• Closed Kitura/SwiftyRequest#77 as stale and not actionable.

  • The issue only had a title.
  • No body, reproduction, expected behavior, actual behavior, versions, or environment details were provided.
  • It may have represented a real semantic question, but the issue itself was not actionable.

• Closed Kitura/Kitura-Credentials#41 as stale/resolved.

  • This was an old provider-specific Google auth/offline-access API design discussion.
  • The maintainers did not consider adding request headers to UserProfileDelegate.update the right generic API direction.
  • Middleware / type-safe middleware was suggested as the appropriate way to extract request-specific header data.
  • A later commenter confirmed that the middleware approach worked.

Larger Kitura repo sweep

Closed or triaged multiple old Kitura/Kitura issues, including historical support requests, stale Travis-era CI reports, obsolete environment-specific failures, and old project coordination items.

Examples of closed/stale items included:

• Kitura/Kitura#1181 — old SSL response hang report, workaround existed, historical environment.
• Kitura/Kitura#1183 — old API documentation support/request thread.
• Kitura/Kitura#1311 — old z/OS / SwiftPM UTF-8 build issue, not actionable for current Kitura maintenance.
• Kitura/Kitura#1328 — old library not found for -lssl.1.0.0 support/build issue.
• Kitura/Kitura#1493 — resolved Xcode working-directory issue.
• Kitura/Kitura#1499 — old Travis / Kitura-NIO macOS CI failure, superseded by CI modernization work.
• Kitura/Kitura#1500 — old Swift 5.1.x JSON serialization vulnerability notice; toolchain-era warning rather than current actionable Kitura issue.
• Kitura/Kitura#1504 — old support question about POST limit.
• Kitura/Kitura#1508 — old “Kitura Is Alive” announcement issue; useful historical note, but no longer needs to remain open.
• Kitura/Kitura#1523 — old kitura.io → kitura.dev link migration tracker.
• Kitura/Kitura#1525 — old CLA discussion; still historically useful, but not actionable as an open issue in current form.
• Kitura/Kitura#1526 — old kitura.dev certificate/common-name report.
• Kitura/Kitura#1530 — old Xcode 12 static package dependency build report.
• Kitura/Kitura#1536 — old dependency URL/build issue involving IBM-Swift redirects and generated apps.
• Kitura/Kitura#1538 — old support/design question about rendering HTML strings.
• Kitura/Kitura#1544 — old Travis/newer Swift/NIO test investigation note.

Kept or mentally preserved older technical themes that still look relevant to future modernization, including:

• request/response diagnostics;
• memory/stress testing;
• NIO behavior;
• connection lifecycle;
• HTTP semantics;
• header handling;
• serviceability and debugging;
• test reliability;
• documentation quality.

BlueSocket sweep

Continued cleanup of old BlueSocket issues.

Closed stale or support-heavy issues where the reports were old, unclear, environment-specific, already explained, or not actionable in their current form.

Examples touched during the broader sweep included:

• old iOS/localhost usage questions;
• partial-read / long-message support questions;
• old unowned self README/sample concerns;
• old socket lifecycle/support questions;
• old environment-specific iOS reports;
• old TLS/stunnel cross-repo confusion;
• old “how do I use this” support threads.

Some BlueSocket topics remain technically important for future review, especially:

• partial reads and stream framing;
• socket lifecycle and memory behavior;
• blocking vs non-blocking behavior;
• UDP edge cases;
• safer examples and documentation.

BlueSSLService sweep

Continued cleanup of old BlueSSLService issues.

Closed stale/environment-specific support issues where appropriate, especially old macOS/iOS/TLS configuration reports that no longer had enough current context.

Preserved the general need to revisit TLS/SSL behavior later, especially around:

• Apple SecureTransport deprecations;
• Network.framework implications;
• PEM/PKCS12 platform asymmetry;
• certificate verification behavior;
• TLS client examples;
• SSL read/write semantics;
• macOS/iOS-specific behavior.

Not all TLS-related issues should be blindly closed. Some remain meaningful as modernization signals, even if old.

BlueCryptor sweep

Continued cleanup of old BlueCryptor feature/support requests.

Earlier stale API-style requests were closed where they no longer aligned with modern Swift API direction.

Preserved the need to treat current crypto issues carefully. Anything involving cryptographic correctness, modern Swift compatibility, or test failures should not be closed casually.

SwiftKuery / database ecosystem sweep

Reviewed database-related issues and separated stale support from valid bugs.

Important retained item:

• Kitura/SwiftKueryMySQL#60 remains open because it is a real diagnostics bug: the original MySQL error should not be discarded.

This area should likely receive a later focused pass because the database packages are useful, but old enough that compatibility, diagnostics, and dependency freshness need careful review.

Kitura-redis sweep

Important retained item:

• Kitura/Kitura-redis#75 remains open because it appears to be a concrete ZRANGEBYSCORE command construction bug.

This is a good candidate for a future small PR.

SwiftyRequest sweep

Closed at least one non-actionable stale issue:

• Kitura/SwiftyRequest#77 — empty issue body; only title present; no reproduction or environment.

SwiftyRequest likely needs a later focused compatibility and dependency review, but empty/non-actionable historical issues should not remain open.

Kitura-Credentials sweep

Closed old API-design/support discussion:

• Kitura/Kitura-Credentials#41 — old Google auth/offline-access request-header discussion.
  • The thread already had a suggested architectural direction: middleware/type-safe middleware.
  • The issue no longer represents a concrete current implementation task.

Credentials/auth packages should still be treated carefully in later modernization because they touch security-sensitive flows.

Kitura-Cache modernization

Started a focused modernization pass on Kitura/Kitura-Cache, chosen as a low-risk package in the dependency graph and a good proving ground for the broader Kitura modernization pattern.

Opened and merged Kitura/Kitura-Cache#39: Migrate CI to GitHub Actions.

• Replaced stale Travis CI with GitHub Actions.
• Preserved historical Linux Swift release coverage using Docker jobs for:
  • Swift 4.0.3
  • Swift 4.1.3
  • Swift 4.2.4
  • Swift 5.0.3
  • Swift 5.1
• Added a current macOS smoke build/test job.
• Removed .travis.yml.
• Updated README and generated documentation badges from Travis CI to GitHub Actions.
• Kept the PR intentionally conservative: restore a working CI signal first, modernize separately.
• Incorporated review feedback about Docker containers writing root-owned workspace artifacts by running containers with the runner UID/GID and using a temporary HOME.
• Validated the workflow locally and on GitHub Actions.
• Merged after review/commentary from LowAmmo and Copilot.

Opened Kitura/Kitura-Cache#40: Modernize KituraCache for Swift 6.

This PR performs a minimal Swift 6 modernization pass while keeping the package small and focused.

Main changes:

• Updates the package to Swift tools 6.
• Declares current Apple platform baselines:
  • macOS 14
  • iOS 17
  • tvOS 17
  • watchOS 10
  • Mac Catalyst 17
  • visionOS 1
• Removes obsolete Swift 4 / Swift 5 era metadata.
• Removes stale Travis CI remnants.
• Removes Jazzy configuration and generated legacy documentation artifacts.
• Migrates tests from XCTest / LinuxMain-era structure to Swift Testing.
• Migrates API documentation from Jazzy to Swift-DocC.
• Refreshes README badges, requirements, SwiftPM usage, community links, and license references.
• Replaces the long-form legacy Apache boilerplate in Package.swift with concise SPDX metadata.
• Keeps the repository under Apache-2.0; this is not a relicensing change.
• Gates Dispatch-specific internals so Dispatch-backed platforms keep the existing timer behavior while Dispatch-less Swift SDKs can compile.
• Updates GitHub Actions to validate:
  • Linux
  • Apple platform cross-builds
  • Swift-DocC documentation generation
  • Android compile checks
  • Wasm compile checks

CI strategy for the Swift 6 PR:

• Linux tests run on Swift 6.0 and current Swift 6.3.2 containers.
• Apple platforms are validated using SwiftPM cross-builds against installed Xcode SDKs instead of expensive simulator matrices.
• Android and Wasm are compile checks using official Swift SDK bundles with pinned checksums.
• The workflow is deliberately budget-conscious for a community-maintained project.

Validation recorded for the Swift 6 PR:

• swift test
• Swift-DocC generation with --warnings-as-errors
• documentation coverage
• SwiftPM cross-builds for macOS, iOS, tvOS, watchOS, Mac Catalyst, and visionOS
• workflow YAML parsing
• whitespace checks
• stale-reference sweep for:
  • Travis
  • Jazzy
  • XCTest/LinuxMain
  • Swift 4/5 remnants
  • dead Swift@IBM/Bluemix Slack links
  • old license paths
  • old Swift conditionals
  • old API documentation links
• GitHub Actions passes Linux, Apple platforms, DocC, Android, and Wasm on the current PR head.

Licensing/header cleanup observations

The Kitura-Cache#40 work also started practical cleanup of legacy licensing boilerplate.

• Package.swift was substantially rewritten as a modern SwiftPM manifest.
• The old long-form IBM/Apache header was replaced with concise SPDX metadata.
• The repository remains Apache-2.0.
• This does not relicense the project.
• The working rule remains:
  • rewritten manifest/config files can use concise SPDX metadata;
  • legacy source files with substantive IBM-era code should not blindly drop IBM copyright notices;
  • broader license/header normalization should be handled deliberately in a separate policy pass.

Outcome

The open issue lists should now be substantially more useful.

The cleanup reduced old noise while preserving issues that still appear to represent real technical debt or future modernization candidates.

The org is moving toward a clearer maintenance state:

• fewer abandoned support threads left open;
• clearer distinction between bugs, stale support, and future modernization work;
• better visibility into remaining real issues;
• less historical clutter before deeper CI, dependency, Swift-version, documentation, and release workflow work;
• first concrete CI migrations completed or underway;
• Kitura-Cache now has a real modernization path after years of inactivity. It'll serve as a pattern for the rest.

Follow-up candidates

Potential follow-up work identified during triage and modernization:

• Fix Kitura/Kitura-redis#75.
• Fix or redesign diagnostics for Kitura/SwiftKueryMySQL#60.
• Continue CI migration after the successful Kitura/SwiftKafka#17 and Kitura/Kitura-Cache#39 experiments.
• Finish and merge Kitura/Kitura-Cache#40.
• Decide whether Kitura-Cache should later grow a v2 API around:
  • Cacheable
  • Codable
  • explicit cache stores
  • async/concurrency-safe abstractions
  • clearer in-process cache semantics
• Create a consistent stale-issue policy for the organization.
• Create an org-wide licensing/header normalization policy before mass SPDX cleanup.
• Add or normalize labels such as:
  • bug
  • stale
  • not actionable
  • support
  • good first issue
  • modernization
  • diagnostics
  • security
  • documentation
• Later review old but structurally relevant Kitura core issues around:
  • NIO behavior
  • HTTP semantics
  • serviceability
  • logging
  • test reliability
  • memory/stress testing
  • request body handling
  • headers
  • template/static-file behavior
• Later review TLS-related issues as a dedicated BlueSSLService modernization pass.
• Later review database packages as a dedicated SwiftKuery/Redis/CouchDB compatibility pass.