updating cron and atrun

[Josh Aas]

My recommendation after looking into the situation was that FreeBSD
just continue as things are going with cron/at (see my original email
for why), and as such I wasn't planning to work on it. I think FreeBSD
should remove it from the list of project ideas, or think of some more
compelling structural improvements to cron/at that bring more value
than just sloshing code and minor feature behavior around between the
various BSDs. They're close enough already for most purposes and the
last mile is expensive without much to gain.

Based on some replies I thought it was worth considering removing
"at", but there seems to be some disagreement and I don't have any
personal interest in whether or not that actually happens so I didn't
pursue it.




On Wed, Mar 4, 2020 at 5:18 AM Gordon Bergling <gbergling at gmail.com> wrote:
>
> Hi Josh,
>
> did you had the time to setup a code repository where we can have a look at the progress you made? You did a fairly detailed analysis of the current „CRON-situation“ and I hope you will make a step further on this.
>
> Kind regards,
>
> Gordon
>
> > Am 07.02.2020 um 15:19 schrieb Josh Aas <josh at kflag.net>:
> >
> > I was looking for a way to contribute to FreeBSD and I decided to look
> > into the cron/atrun project listed on this page:
> >
> > https://wiki.freebsd.org/IdeasPage#Improve_cron.288.29_and_atrun.288.29
> >
> > I looked into the current code, commits from the past decade, and the
> > lineage of other versions of cron to see if there is a reasonable plan
> > for updating FreeBSD’s cron based on another version. It doesn't seem
> > like there are any particularly productive new path to take here. ISC
> > cron is old and unmaintained, and I don’t think NetBSD or OpenBSD cron
> > is interesting enough to be worth entirely rebasing on. On top of
> > that, FreeBSD cron seems to have some FreeBSD-specific functionality
> > that we’d still need to maintain or “upstream” elsewhere.
> >
> > I’d recommend continuing with the current status quo - keep FreeBSD’s
> > version of cron and occasionally pull in security/stability patches as
> > applicable from OpenBSD or NetBSD. The other options are a lot of work
> > for little (if any) gain. Happy to hear other opinions though.
> >
> > Integrating atrun into cron might be nice but isn’t very interesting
> > IMO. Seems very possible that the cost of that churn outweighs the
> > benefit. I’d love to hear more about why this is a particularly good
> > idea if people believe it is. Maybe I’m missing something.
> >
> > If people agree I’d recommend removing the cron and atrun suggestion
> > on the Ideas Page. Maintaining that page seems like a pain though,
> > might I recommend keeping track of these ideas as bugzilla bugs,
> > tagged with something like “ideaslist”? Then you can just link to that
> > search.
> >
> > --
> > Josh Aas
> > _______________________________________________
> > freebsd-arch at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> > To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>


--
Josh Aas
(215) 206-2020