> >> > +* 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? - Emily
