On Thu, Jul 18, 2024 at 3:46 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: [..snipped nits, I have fixed them for v4] > > +* You should run nightly tests against the `next` branch and publish breakage > > + reports to the mailing list immediately when they happen. > > Can't it be daily instead of nightly ;-), or is it better than > nothing if you can afford to run only once every other day? > > A topic (unless it is during the shuffle time around -rc0) usually > spends no less than 7 calendar days in 'next', so while I would > appreciate if somebody runs tests twice a day, in practice you > should be able to catch a new breakage in 'next' if you run a full > and thorough test twice a week. I ended up adding a sub-point to explain cadence preference and reasoning, since that's a lot to fit into a parenthetical. Thanks. > > > +* You should either: > > + > > +** Provide VM access on-demand to a trusted developer working to fix the issue, > > + so they can test their fix, OR > > "VM access on-demand" -> "on-demand access to your platform" (iow, > physical iron is also fine for our purpose). Done, thanks. > > +Minimum Requirements > > +-------------------- > > + > > +Even if platform maintainers are willing to add tests or CI runners, we will > > +not consider helping to support platforms that do not meet these minimum > > +requirements: > > + > > +* Has C99 or C11 > > OK. > > > +* Has dependencies which were released in the past 10 years > > This is hard to understand and I wonder if we can clarify. I get > what you want to say: suppose we rely on library X that is getting > regular feature and security updates in reasonable cadence, say > every 6 months there is an upstream release of library X, but a > niche platform has ported the library only once long time ago, and > hasn't updated it ever since. Now the Git project may consider > helping a port to such a platform if the initial port of library X > was 8 years ago, but will not if it was 12 years ago. > > But if Git depends on an ultra stable library whose last public > release was 12 years ago, disqualify everybody is not what this > requirement wants to do. > > I attempted to formulate my version along ... > > Keep up with the versions of dependencies (libraries, etc.) and > not to lag behind compared to typical mainstream platforms by > more than X years. > > ... the above line, but to me it is no better than the original, so > I failed miserably. But the idea I am bringing to the table here is > that time of release is not absolute. If typical mainstream > platforms consider a release of a library made 8 years ago from the > upstream performant, functional, and secure enough and fit for use, > we do not consider that they are approaching the limit. But if > another platform uses the same library from 12 years ago, i.e. > lagging behind others by 4 years is a problem at the same graveness > using another library that was released 6 years ago, when other > platforms are using a much younger vintage of the same library > released at 2 years ago. Yeah, I think it makes sense to relax just a little bit more, and give ourselves flexibility to use common sense. I ended up with: """ * Uses versions of dependencies which are generally accepted as stable and supportable, e.g., in line with the version used by other long-term-support distributions """ It's not quite my favorite, still, because I guess that LTS distros could get to a point we don't want to support (do we really want to provide cutting-edge git features to a 25-year-old LTS distro, for example?). Plus, "just look at everyone else's homework and use that" feels a little weird. Will keep thinking on this, I'd welcome other suggestions for phrasing. > > Having said all that, everything I removed from my quote I found > agreeable. Very well written. Thanks. :) - Emily
