On Thursday, July 11, 2024 2:20 PM, Emily Shaffer wrote: >> >> > +* You should run nightly tests against the `next` branch and >> >> > +publish breakage reports to the mailing list immediately when they happen. >> >> > +* It may make sense to automate these; if you do, make sure they >> >> > +are not noisy (you don't need to send a report when everything >> >> > +works, only when something breaks). >> >> > +* Breakage reports should be actionable - include clear error >> >> > +messages that can help developers who may not have access to >> >> > +test directly on >> >your platform. >> >> > +* You should use git-bisect and determine which commit >> >> > +introduced the breakage; if you can't do this with automation, >> >> > +you should do this yourself manually as soon as you notice a breakage >report was sent. >> >> >> >> All of the above are actually applicable to any active contributors >> >> on any platforms. If your group feeds custom builds of Git out of >> >> "master" to your $CORP customers, you want to ensure you catch >> >> badness while it is still in "next" (or better yet, before it hits "next"). >> >> If your internal builds are based on "next", you'd want to ensure >> >> that "next" stays clean, which means you'd need to watch "seen" (or >> >> better yet, patches floating on the list before they hit "seen"). >> >> Your group may build with unusual toolchain internal to your $CORP >> >> and may link with specialized libraries, etc., in which case >> >> maintaining such a build is almost like maintaining an exotic platform. >> > >> >Hits close to home ;) >> >> I hear that. Sometimes having an exotic platform and specialized libraries are >overlapping. I am still stuck with 32-bit git because some of the available DLLs on >NonStop are still only 32-bit - I'm working hard on changing that but it's not under >my budget control. >> >> On that subject, I think it is important to have known or designated platform >maintainers for the exotics. The downside is that some people expect miracles from >us - I just had one request to permanently preserve timestamps of files as they >were at commit time. We're into weeks of explanations on why this is a bad idea. >Nonetheless, there is a certain amount of responsibility that comes with >maintaining a platform, and knowing whom to ask when there are issues. The >platform maintainers also can provide needed (preemptive) feedback on >dependency changes. I'm not sure how to encode that in a compatible policy, >however. > >I think it's a pretty good idea to have a contact list written down somewhere, yeah. >Maybe something similarly-formatted to a MAINTAINERS file. I don't feel bad if it's >just appended to the bottom of this doc til we find a better place to put it... or >maybe we can put such a contact list in compat/, since someone lost trying to figure >out a compatibility thing might be looking there anyway? > >Who else would we put on there? I can think of you for NonStop from the top of >my head; that AIX breakage I dug up was reported by AEvar, but it's also a few years >old; and I could imagine putting Johannes down for Windows. Maybe that's enough >to start with. > >By the way, Randall, should I be waiting for a more complete review of this patch >from you before I reroll? Please reroll. --Randall
