Pumukit Timed Pub Decisions Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing to flag is a stack mismatch: despite being catalogued as a "Laravel/PHP package," teltek/pumukit-timed-pub-decisions-bundle is a Symfony bundle, and specifically a satellite module for Pumukit, Teltek's Symfony-based open-source video management platform. It is not installable into a Laravel application as-is. It expects Symfony's bundle registration model (AppKernel/bundles.php), the Symfony DI container, and — critically — Pumukit's domain model (MultimediaObject/Series, publication workflow, admin UI) and its MongoDB/Doctrine ODM persistence layer. Architectural fit is therefore binary: strong if and only if the target platform is Pumukit; near-zero for any Laravel or generic PHP stack.

Integration feasibility. The bundle's job is narrow and legible: time-bounded publication decisions — scheduling when an object becomes visible or is retracted, with an approval/decision step. That is a well-understood concern. The practical blocker is not the feature, it is the dependency graph: you must first stand up Pumukit with a compatible Symfony major version and MongoDB, then wire this bundle into the admin surface and a scheduler. With 1 star, 0 dependents, and a score of 0.005, there is no observable evidence of production use, no downstream projects to learn from, and no community troubleshooting trail.

Technical risk. High, concentrated in three areas:

• Maintenance risk — essentially no adoption signal. Assume unmaintained until proven otherwise; verify last commit date, open issues, and branch/tag hygiene before committing.
• Version drift — Pumukit and Symfony have both moved significantly (Symfony 3/4-era bundles rarely survive to 6/7 without work). The ODM document model and container wiring are the common break points.
• Operational correctness — time-based publication is a correctness-critical feature (content appearing or disappearing at the wrong moment is a user-visible incident). Scheduled-job reliability, timezone handling, and idempotency need explicit validation.

Key questions to resolve before any commitment.

1. What Pumukit and Symfony versions does this bundle target, and is there a maintained branch?
2. Is execution cron/worker-driven or request-triggered? What happens on a missed run?
3. What does the "decision" workflow actually model — who approves, and is there an audit trail?
4. Test coverage and CI status? License? Any documented public API or admin UI?
5. Who owns it internally at Teltek, and is there a support path?
6. Does it write directly to Pumukit's publication state, or through the core service layer (upgrade-safety)?

TPM recommendation. Do not adopt on the basis of the package itself. Treat it as reference material for a timed-publication capability and make a build-vs-adopt call against your actual stack.

Integration Approach

Stack fit. If the platform is already Pumukit, this bundle is a plausible low-effort add: Composer-require it, register the bundle, configure parameters, apply any MongoDB indexes, and hook the admin UI. If the platform is Laravel — or anything non-Pumukit — the honest answer is do not port it. The concept maps cleanly onto Laravel's native primitives: a PublicationDecision model, a scheduled command or queued job, Horizon/Scheduler for execution, and policies/gates for the approval step. That reimplementation is likely smaller, better tested, and maintainable by your own team than a Symfony-into-Laravel transplant.

Migration path (Pumukit case).

1. Baseline the environment: pin Pumukit core, Symfony, PHP, and the MongoDB extension; confirm the bundle's declared constraints against that baseline.
2. Vendor the package (fork to an internal namespace) so you control patches — assume upstream is dormant.
3. Stand up in staging against a copy of production data; validate bundle registration and container compilation.
4. Configure the scheduler/cron entry point and confirm timezone and clock assumptions.
5. UAT the publication transitions end-to-end (publish, unpublish, retract, edit-after-schedule).

Compatibility. The hard constraints are Symfony major version, Pumukit core version, and PHP. Treat all three as pinned, and gate upgrades behind a regression run of the timed-publication scenarios. Watch for ODM mapping changes after any core bump.

Sequencing. Confirm the stack decision (Pumukit yes/no) → verify the bundle builds and boots in staging → validate the scheduling mechanism → UAT → only then production. Do not sequence this behind other Pumukit work; the version-alignment spike should happen first because it can invalidate the whole path.

Operational Impact

Maintenance. Plan for ownership from day one. With no dependents and minimal stars, the realistic operating model is an internally forked, internally patched bundle. Budget a named owner and a recurring line item for dependency and security patching; the cost is small but non-zero and must be explicit, not absorbed silently.

Support. There is no meaningful ecosystem to lean on. Upstream is a single vendor (Teltek) with a niche platform; response times and roadmap influence are uncertain. Escalation paths should be documented before go-live.

Scaling. The load profile is scheduler- and database-bound rather than request-bound: periodic evaluation of pending decisions, writes to MongoDB, and admin UI reads. Watch worker concurrency, index coverage on the decision/date fields, and MongoDB write contention during bulk scheduling windows. The feature scales fine at typical VMS volumes; the risk is bursty admin activity, not steady-state throughput.

Failure modes to instrument.

• Missed or delayed execution (cron down, worker backlog) → content published or retracted at the wrong time. This is the primary user-visible failure; alert on scheduler lag and job age.
• Clock/timezone drift → off-by-hours publication. Enforce UTC internally and test DST boundaries explicitly.
• Orphaned or conflicting decisions → two schedules on one object, or a decision referencing a deleted object. Needs a reconciliation check.
• Silent no-op after upgrade → bundle loads but listeners no longer fire. Cover with a canary object in staging on every deploy.
• Data integrity on retraction → confirm whether unpublishing preserves or removes access and assets.

Ramp-up. A mid-level Symfony developer is productive in this bundle in roughly one to two weeks; add two to four weeks for Pumukit domain fluency (object model, publication semantics, admin conventions) and MongoDB/ODM familiarity. Without existing Pumukit experience on the team, the effective ramp is dominated by platform learning, not by this bundle — factor that into the cost case, because it usually dwarfs the integration effort itself.