Re: [PATCH] Documentation: add platform support policy

> >> > +* 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.