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.
>
>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?