On 2025-10-08 at 22:05:04, Taylor Blau wrote:
> I am not sure what our proposal would be other than max(proposed_dates),
> clamped to some reasonable range that we are comfortable with so as not
> to delay the transition to use SHA-256 by default too far into the
> future.
> 
> I think a more interesting question is:
> 
>  - What do we do for implementations that do not have a roadmap, or
>    whose roadmap is too far into the future?
> 
>  - What do we do for implementations that have a roadmap, have a date
>    that is palatable to the project, but end up slipping and are unable
>    to meet that date?
> 
> I generally agree that we have to draw a line in the sand *somewhere*,
> but I don't think we should be so inflexible as to say "if you don't
> have SHA-256 done by X date, you are out of luck". Of course, if the
> amended timeline is too far beyond the initial deadline that's one case.
> But if someone is a release cycle or so behind, I think it's reasonable
> that the project should be flexible enough to accommodate that.

I agree that it would be appropriate to be somewhat flexible.  My
personal view is that we should inform stakeholders relatively soon
(preferably within the next month) and expect them to promptly and
diligently undertake the necessary work to get started (maybe within
another month) and provide a rough roadmap.

If that happens, I expect most stakeholders will be done in about a year
to a year and a half, tops.  Assuming a reasonable release cycle, I
think it should be fine to give people some grace to do a release with
those changes as long as they can communicate a reasonable timeline to
us and show that they're making a reasonably diligent effort.

I also think there will be some stakeholders, probably including some
forges, that will not promptly undertake the work.  In my view, the
answer then is that we won't consider their readiness as affecting our
timeline.

There are also some implementations that I know already have SHA-256
support.  I believe libgit2 and Forgejo both have at least some
functionality there, so we may want to just give them a heads up that
they may want to polish any support they have before Git 3.0.

If we want to set a hard cap, then I'd say two years.  I know that's
what we said in 2024, but we didn't communicate it well at the time.
What I have been communicating elsewhere is that Git 3.0 is tentatively
planned for a year from now, so that may be a good initial phrasing to
set expectations, with the clarifications we've specified.  I think a
year from now would be good if all the relevant stakeholders are
finished before then (which is possible, but unlikely).
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA