At Wed, 20 Nov 2019 18:10:09 -0800, Peter Geoghegan <pg@bowt.ie> wrote in
> On Wed, Nov 20, 2019 at 6:07 PM Michael Paquier <michael@paquier.xyz> wrote:
> > Yep, agreed. This looks like an oversight. Peter?
>
> It's not an oversight. See the commit message of a6417078, and the
> additions that were made to the RELEASE_CHANGES file.
Mmm...
a6417078:
> * After feature freeze in each development cycle, run renumber_oids.pl
> to move all such OIDs down to lower numbers, thus freeing the high OID
> range for the next development cycle.
I thought that commits don't use the development OIDs and thought that
we won't have conflict perfectly.
So, still any ongoing patch can stamp on another when it is committed
by certain probability (even if it's rather low)). And consecutive
high-OID "hole"s are going to be shortened and decrease throgh a year.
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.
$ ./unused_oids
Suggested random unused OID: 8057 (133 consecutive OID(s) available starting here)
If you need more OIDs, try run this script again or unused_oids -v
(for example) to show the complete list of unused OIDs.
$ ./unused_oids
Suggested random unused OID: 8182 (8 consecutive OID(s) available starting here)
If you need more OIDs, try run this script again or unused_oids -v
(for example) to show the complete list of unused OIDs.
$ ./unused_oids -v
4 - 9
210
270 - 273
...
8191
8193 - 9999
Patches should use a more-or-less consecutive range of OIDs.
Best practice is to start with a random choice in the range 8000-9999.
Suggested random unused OID: 8342 (1658 consecutive OID(s) available starting here)
Thoughts?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
