Date: Thu, 22 Oct 2020 07:56:57 -0600 From: Warner Losh <imp@bsdimp.com> To: "Greg 'groggy' Lehey" <grog@freebsd.org> Cc: Stefan Esser <se@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <CANCZdfpmUmk1FBG5SgHq_Kz_1GBH1Rxu4MBH262QhVnsfcZQ1A@mail.gmail.com> In-Reply-To: <20201022063536.GG59592@eureka.lemis.com> References: <20201020035420.GA59361@eureka.lemis.com> <CANCZdfrbq54H2iCHqsD2B3_7KGOQ0AW-tY4%2BJ1irAJgrr4TdaA@mail.gmail.com> <20201021012323.GA59592@eureka.lemis.com> <ed9abe81-7282-25a0-c5ab-dbda2f2b5ee8@freebsd.org> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <CANCZdfqHGD1QByrYs4_Mnn0vihjM50RQEXi3dDgXd8xZ=qQGRQ@mail.gmail.com> <20201022041212.GE59592@eureka.lemis.com> <CANCZdfqe7%2B-m_yMEgNdHt2QBAk8wHhqZNKvcNEQc9mVkhd95wg@mail.gmail.com> <20201022044930.GF59592@eureka.lemis.com> <CANCZdfohU3o_tQ_6ym54b-0T4wzLPAKH71nUZdHzpPe=JUM4CA@mail.gmail.com> <20201022063536.GG59592@eureka.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 22, 2020 at 12:35 AM Greg 'groggy' Lehey <grog@freebsd.org> wrote: > On Wednesday, 21 October 2020 at 22:54:39 -0600, Warner Losh wrote: > > On Wed, Oct 21, 2020, 10:49 PM Greg 'groggy' Lehey <grog@freebsd.org> > wrote: > > > >> On Wednesday, 21 October 2020 at 22:23:08 -0600, Warner Losh wrote: > >>> On Wed, Oct 21, 2020, 10:12 PM Greg 'groggy' Lehey <grog@freebsd.org> > wrote: > >>> > >>>> The change to calendar(1) looks fine, but I have my issues with the > >>>> port. It seems that we're not alone. On the one hand, both Apple and > >>>> Linux have used our data files for their packages, so removing the > >>>> data files would violate POLA. On the other hand, Apple, Linux, > >>>> NetBSD and OpenBSD are maintaining their own versions of these files, > >>>> along with calendar(1). My guess is that Linux has them hidden on > >>>> GitHub. I'm trying to find out where they maintain the files (can any > >>>> Linuxheads help?), so that we can come to a general agreement about > >>>> how to maintain them. This could include removing calendar(1) from > >>>> the tree entirely and installing from a port. Once again I'm > >>>> concerned about jumping the gun. > >>> > >>> Where we pull them from doesn't affect that. > >> > >> But where other people pull them from *is* relevant. > >> > >>> They can pull from github easily enough. > >> > >> Once they know, yes. But maybe they already have it on GitHub. > >> > >>> And our users can install a port easily enough. It's done all the > >>> time, so wouldn't be that surprising even from that perspective. > >> > >> First they need to know that they have to install a port to get what > >> they got automatically in the past. > >> > >>> This issue has been simmering for years, but has flared up in the > >>> last 6 months. > >> > >> I haven't seen any flare. > > > > Then you've not been paying attention. > > > >>> So, unless you have a competing plan, > >> > >> Sorry, I thought I had explained that. > > > > It seemed less a firm plan than a sketch. > > > >> with a firm timeline, > >> > >> I don't think that's important. > > > > And that is the problem. > > What I see is a somewhat emotional response without clear reasoning. > FWIW, yes, I've been paying attention, and saving all relevant emails. > My proposal is about as good as it goes without input from other > projects. And nobody has explained why 24 years is OK, but suddenly 6 > months is too long. > It's decayed for 24 years. The issue has actually been a lack of curating for about 5 years when the rumblings started now with no motion in 6 months on the problem. The lack of urgency on your part doesn't make it any less a problem. Calling it emotional on my part is a way to deflect from the issue: these files are badly curated and should be discarded or modernized or something in between. The fact that this issue has been brought up many times, only to have it ignored is what's getting people upset. The fact that there's no firm timeline to a fix is also troubling. > In principle se@'s proposal is good. But my concern is > that then the matter will be forgotten, and the problem will be left > half fixed. > Then undertake the time to fix them if you are worried. Let's summarize: > > 1. We have an program from 4BSD with old, mouldy data files that have > outlived their purpose. > > 2. But we can't just discard them without finding a better > alternative. > We can, actually. We do it all the time for stuff whose maintenance exceeds its benefit. > 3. Not just FreeBSD, but also Linux and Mac OS use these files, and > they appear to get them from us. NetBSD and OpenBSD also have > variants on these files, including errors that I've fixed over the > years. > Sounds like the perfect project to cleave off to allow all groups to contribute without it becoming a partisan 'which os' affair. > 4. Unnamed people in the FreeBSD project are upset about the > continuing presence of our version of these files in the FreeBSD > tree. > > 5. There are claims that it has to be fixed Right Now, with no delay. > The claim is that you've been ignoring concerns that have been raised going back years, and that you seem poised to continue to do so since there's no articulated timeline. > 6. The "fix" involves moving the files somewhere else, without fixing > them. > The "fix" is to create a centralized location for all groups to contribute and curate rather than to continue to have the efforts diluted by segregation. > What I see is an opportunity. We should get the other projects on > board and agree on a central repository for all projects. Probably > this would be GitHub, as you have suggested. But maybe there's one > there already, and if we want to get the other projects on board, we > should discuss it with them. > > So why not just accept se@'s proposal? It has the obvious advantages > of making sense and silencing the spirits which are tormenting you. > My concern is that it will then be forgotten, and we will miss the > opportunity to unify the data. > I wouldn't say so much tormenting as a recognition that the current structure provides too much friction to fix things. Other groups that just take from us do not create an obligation for the project to do anything in particular. It's the nice thing to do to help them out, but it's really the wrong mindset and structure. We learned from the 'tar' rewrite that it's sometimes better to locate bits of the project outside the project to give them a life of their own. In so doing, libarchive grew up to be a widely deployed thing, with bug fixes coming in from all over making it better than it would have been had it remained inside the project. Same with jemalloc. > So: a concrete proposal. > > 1. We accept se@'s split as a first step. > > 2. You personally agree to follow up with the other projects and > ensure that the data will end up on an OS-neutral platform from > which all projects can draw their data. > So your proposal is for me to do more work? I'll setup the github repo, give people permissions to do the work. Others will need to do the work. > 3. You agree to do this with a firm timeline. Since it seems that 6 > months is too long, how about by the end of 2020? > So now your timeline is for me to do more work? That sounds like my timeline, not yours. > You're still involved with NetBSD and OpenBSD, right? That should > make things easier. I'll happily chase up the Linux people, and > presumably there are people here who can get Apple involved, if > they're still interested. > Or we could just create a github repo, publicize it and see what happens? I'm not so involved in OpenBSD and NetBSD these days, so can't help much there. > How does that sound? > I think it sounds lousy, honestly. It's a lot of bother that you're trying to stick me with when you've held yourself out as the maintainer of this software. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpmUmk1FBG5SgHq_Kz_1GBH1Rxu4MBH262QhVnsfcZQ1A>