At Thu, 21 Nov 2019 10:35:25 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> > If we don't intend what Peter pointed (arrangement of low-OIDs at
> > feature freeze), it can be done by moving OIDs to lower values at
> > commit. (I don't mean commiters should do that, it may be bothersome.)
>
> Yes, that's exactly the point: when we discussed this new policy,
> it was agreed that making committers deal with the issue in each
> commit was an unreasonable burden. Aside from just being more
> work, there's the risk that two committers working on different
> patches concurrently would choose to map the development OIDs to
> the same "final" OIDs. It seems better to deal with the problem
> once at feature freeze.
>
> Anyway, we've only had this policy in place for a few months.
> I'm not eager to redesign it until we've had more experience.
Thanks for the explantion. I understood and agreed.
> >>> By the way even if we work this way, developers tend to pick up low
> >>> range OIDs since it is printed at the beginning of the output. I think
> >>> we should hide the whole list of unused oids defaultly and just
> >>> suggest random one.
>
> >> -1, that pretty much destroys the point of the unused_oids script.
>
> > Is the "point" is what the name suggests? The tool is, for developers,
> > a means of finding OIDs *usable for their project*. It doesn't seem
> > appropriate to show OIDs that developers are supposed to refrain from
> > using. In my proposal the tool still shows all unused OIDs as the name
> > suggests when some option specified.
>
> The existing output seems perfectly clear to me. What you propose
> just adds complication and reduces usefulness.
For clarity, it's perfect also to me. I don't insist on the change
since no supporters come up.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
