Re: [PATCH v2 0/4] Enable Rust by default

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> This was actually sent out just before rc0, but Patrick requested some
> changes in v1.  (I forgot to thread it to the previous version,
> unfortunately.)

Proudly saying "It was sent before rc0", as if that gave community
plenty of time to adjust, is not something I was expecting to hear.

"This is expected to be a big impact change, so I am sending it
before -rc0 of this cycle, so that it can be in the first batch that
graduates to 'master' for the next cycle" would have been a lot more
understandable, though.

This, and other small things like writev() topic, reminds me what
I've been wondering for some time about our development process.

We have been operating this way:

 - There are 6 to 8 weeks of period, during which at any time
   anybody can send in any random changes, and as soon as a rough
   consensus is reached that it is a good idea, a topic is merged to
   'next' and after spending a week there merged down to 'master'.

 - There is a "cut-off" time at -rc1.  After that we go into
   "regression fix only" prerelease freeze.  We typically do an -rc2
   and the final after that, and this process typically takes 2.5
   weeks.

This forces topics that are apparently (even though in retrospect it
only was superficially) good topic that came late to spend too little
time to make the cut-off time.

I wonder if we should do this a bit differently.

We may want to have a mechanism to sift topics (as they come in)
into "architecturally important high impact" changes and the rest by
community concensus.  We require that the former be kept in 'next'
until the final release, unless they mature before '-rc0'.

Essentially, '-rc0'would become the new cut-off time for these high
impact topics, while '-rc1' will be the cut-off for the rest.

And we move '-rc0' way before '-rc1'.  Perhaps to week 3 or 4 of the
cycle, from the current week 6 to 8.  Currently "rc0" is no more
than "we happen to have accumulated these random topics during this
cycle and this is a preview", which is boring, but we can reframe it
as "there may be more smaller topics coming, but all architecturally
important high impact changes in the upcoming release are in here
and no more will be added until the final release." preview.  If you
are not in the mainstream (you are on a minority platform, or your
workflow is pecurilar, or you depend on some third-party tools on
top of Git, etc., etc.), this is the version to test and report
breakages in, to make sure that the next release won't hurt you.

Would that improve the process and allow us to experiment with
larger changes early in the cycle, with plenty time to correct
course, allowing us scramble less at the last minute during the
prerelease freeze period?

I dunno.