Re: When should we release Git 3.0?

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Once we have roadmaps, we should set a strict deadline that takes them
> > into account. Any hosting provider or implementation of Git that doesn't
> > provide a roadmap will not be taken into account in our planning.
> 
> Works fine as long as we assume everybody that matters will
> eventually want to move away from SHA-1.
> 
>  - If a stakeholder gives a roadmap that has no SHA-256 in their
>    future, in other words, if they are content to serve only the
>    SHA-1 projects, what's the impact to them?  We are not dropping
>    the support for SHA-1 in the sense that if you clone from an
>    existing SHA-1 repository you'll get an SHA-1 repository and you
>    can push and fetch between them just fine, so presumably that is
>    fine as well.
> 
>  - If a stakeholder gives a roadmap with SHA-256 so far into the
>    future that we cannot wait, what's the impact to them?  Their
>    customers that want SHA-256 earlier than they can supply could
>    move to other hosting or implementation, but not really.  Both

>    hosting providers and Git implementations have components that
>    are move than Git that are hard to migrate, like issue trackers,
>    CI services, workflow tools, etc., that make their customers
>    captive audience [*].
> 
>  - If a stakeholder has a roadmap with SHA-256 in line with our
>    timeframe, do we still need to assess the impact to them, or as
>    long as we and they work hard to stick to the plan, we all will
>    be happy?
> 
> > We should of course actively reach out to the projects that we're aware
> > of so that they have a chance to provide such a roadmap in the first
> > place.
> 
> 
> [Footnote]
> 
>  * Issue trackers and review logs that are federated, possibly using
>    Git database for storage and transfer, may allow projects and
>    users to freely roam across hosting sites, but there is no strong
>    incentive for the hosting sites to fund such an effort X-<.