On Thu, Jul 18, 2024 at 4:45 PM <rsbecker@xxxxxxxxxxxxx> wrote: > > On Thursday, July 18, 2024 6:46 PM, Junio C Hamano wrote: > >Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > > >> Supporting many platforms is only easy when we have the right tools to > >> ensure that support. > > > >"easy" -> "possible". > > > >> +Compatible by next release > >> +-------------------------- > >> + > >> +To increase probability that compatibility issues introduced in a > >> +release will be fixed in a later release: > >> + > >> +* You should send a bug report as soon as you notice the breakage on > >> +your > >> + platform. The sooner you notice, the better; watching `seen` means > >> +you can > >> + notice problems before they are considered "done with review"; > >> +whereas > >> + watching `master` means the stable branch could break for your > >> +platform, but > >> + you have a decent chance of avoiding a tagged release breaking you. > >> +See "The > >> + Policy" in the link:../howto/maintain-git.txt[maintainer's guide] > >> +for an > > > >Running > > > > $ make -C Documentation howto/maintain-git.html > > $ lynx Documentation/howto/maintain-git.html > > > >tells me that the title of the document is "How to maintain Git". > > > >> + overview of which branches are used in git.git, and how. > > > >"git.git" -> "the Git project" > > > >> +Compatible on `master` and releases > >> +----------------------------------------- > > > >Underline that signals what level the header is is drawn to the same column as the > >header title itself, or you'd confuse the formatter. > > > > > >> +To make sure all stable builds and regular releases work for your > >> +platform the first time, you can make sure `master` doesn't break for your > >platform: > > > >"can" -> "want to"? > > > >But "to make sure X, you can make sure Y" feels a bit awkward. > > > > To make sure ... work for your platform, help us avoid breaking the > > tip of `master` by merging topics that break your platform. > > > >> +* 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. > > > >> +* 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). > > > >> +Compatible on `next` > >> +-------------------- > >> + > >> +To avoid reactive debugging and fixing when changes hit a release or > >> +stable, you can aim to ensure `next` works for your platform. (See > >> +"The Policy" in the link:../howto/maintain-git.txt[maintainer's > >> +guide] for an overview of how `next` is used in the Git project.) To do that: > >> + > >> +* You should add a runner for your platform to the GitHub Actions or > >> +GitLab CI > >> + suite. This suite is run when any Git developer proposes a new > >> +patch, and > >> + having a runner for your platform/configuration means every > >> +developer will > >> + know if they break you, immediately. > >> + > >> +** If adding it to an existing CI suite is infeasible (due to architecture > >> + constraints or for performance reasons), any other method which runs as > >> + automatically and quickly as possible works, too. For example, a service > >> + which snoops on the mailing list and automatically runs tests on new [PATCH] > >> + emails, replying to the author with the results, would also be within the > >> + spirit of this requirement. > > > >It would be very nice if they did this, indeed. Explaining that something that > >mechanically looks vastly different is within the spirit is a very good move. > > > >> +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. > > > >Having said all that, everything I removed from my quote I found agreeable. Very > >well written. > > I am concerned about setting a specific limit here. The reason is that, as a platform/community maintainer: > 1. I do not control the library versions that are available - in most cases > 2. I do not control the available toolchain - in all cases > 3. Support is required for all OS releases dating back 5 years from the close of sales - this is not actually a huge problem except for #1 and #2. However, it does not serious constraints on what toolchains are available. Most of what we do is use static linkage to avoid a lot of compatibility issues, other than OpenSSL that has to be flexible based on the rate of CVEs raised and solved. > 4. Porting some new tools (e.g., GO, Rust, gcc, libc, glibc), is usually impossible no matter what my skill level based on platform prohibitions. I actually think what level of control the platform maintainer has is beside the point. The intent of this line in the doc is to say: even if there is an active maintainer and there are active users, Git developers need to be able to use relatively modern tooling to be able to keep Git healthy and evolving. The more Git development is locked into past tooling, the less it can keep up with the needs of most of the industry, and the higher the risk comes of Git being abandoned because the cost to overhaul it to meet industry needs is too high. So, if a platform isn't compatible with those reasonably modern tools (and I do think "a C compiler that's less than 10 years out-of-date" is really stretching the meaning of "modern"), sorry, but it's not workable for us. That is, it's not about whether the maintainer is virtuous and doing everything in their power; it's about whether the platform itself is feasible to support and whether the abilities of the platform line up with the Git project's needs to make forward progress and keep up with the times. Whether or not that paraphrasal is something the rest of the Git community agrees with, though, is the whole reason I sent this doc up for review ;) So far I haven't seen any other disagreement than this mail, but we also haven't gotten a ton of reviews on this patch, less than half a dozen individuals. (By the way, "others may find Git too far gone and build something new instead" is actually already happening[1][2], including at Google.) > I'm sorry to have to complain about this, but it is a reality of exotic, non-linux, platforms that are still being maintained and active (the last major NonStop OS release was 11 months ago, and another is due to drop imminently, so this is not a dead or dying platform). The last thing I want to have is having users locked out of future git versions, based on the increasing adoption of git on NonStop that has been (immodestly said) mostly my fault. Can we solve this in some acceptable way? As it stands, we currently don't have any tooling available to make sure that changes we make work on NonStop, anyway - we basically need to take your word for it when something breaks, and that's quite difficult for the contributor base to cater to. So even if we were to relax the minimum requirement bits here, we'd have difficulty supporting NonStop in the capacity that you sound interested in. Do you have any suggestions to make NonStop easier to support in that regard? I wonder if it is better worth explaining what maintenance branch support users can expect - how long a given version will receive security patches, what kind of backporting work platform maintainers could reasonably do, and so on. Thoughts? - Emily 1: https://github.com/martinvonz/jj 2: https://sapling-scm.com/
