git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Patrick Steinhardt <ps@pks.im>
Cc: Junio C Hamano <gitster@pobox.com>, Taylor Blau <me@ttaylorr.com>,
	Luca Milanesio <luca.milanesio@gmail.com>,
	git@vger.kernel.org
Subject: Re: When should we release Git 3.0?
Date: Tue, 7 Oct 2025 12:36:47 +0200	[thread overview]
Message-ID: <aOTtPxsdzJLPCruk@kitsune.suse.cz> (raw)
In-Reply-To: <aOTrC8CRZm5hERgr@pks.im>

On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
> On Thu, Oct 02, 2025 at 06:10:22PM +0200, Michal Suchánek wrote:
> > On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:
> > > 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
> > 
> > I suppose that's already the case to some extent. git does support
> > sha256, some forges do as well, and some people want it to the point
> > that they install such forge, and create the sha256 repositories
> > although it is not the default.
> > 
> > There is some tradeoff here. When it's nice to have but not required
> > people will use it when convenient. When it's really required people
> > will use even an obscure implementation to get the requested feature.
> 
> True. In any case, I think that for now we should just wait how such
> roadmaps would look like and then discuss based on the findings.
> 
> The question of course is how to get such roadmaps. The easiest way to
> do it is probably to gather a list of known projects that would be
> impacted and just shoot maintainers or representatives of those an
> email? From the top of my head, that would include:
> 
>   - Implementations
>       - libgit2
          - pygit2
>       - JGit
>       - Gitoxide
>       - go-git
>   - Forges
>       - GitHub
>       - GitLab
>       - Bitbucket
>       - Forgejo
        - Gitea
>       - SourceHut

Thanks

Michal

  reply	other threads:[~2025-10-07 10:36 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-30 23:07 When should we release Git 3.0? brian m. carlson
2025-10-01  7:13 ` Luca Milanesio
2025-10-01 16:04   ` Taylor Blau
2025-10-01 19:31     ` rsbecker
2025-10-08 21:44       ` Taylor Blau
2025-10-08 21:55         ` rsbecker
2025-10-02 13:31     ` Patrick Steinhardt
2025-10-02 15:32       ` Junio C Hamano
2025-10-02 16:10         ` Michal Suchánek
2025-10-07 10:27           ` Patrick Steinhardt
2025-10-07 10:36             ` Michal Suchánek [this message]
2025-10-07 13:21               ` Patrick Steinhardt
2025-10-07 13:40                 ` Michal Suchánek
2025-10-07 17:11                 ` Junio C Hamano
2025-10-07 17:28                   ` Michal Suchánek
2025-10-08 20:44             ` SZEDER Gábor
2025-10-09  5:56               ` Patrick Steinhardt
2025-10-02 16:54       ` Ben Knoble
2025-10-07 10:27         ` Patrick Steinhardt
2025-10-07 17:36           ` rsbecker
2025-10-08 22:05           ` Taylor Blau
2025-10-09  5:59             ` Patrick Steinhardt
2025-10-16 21:32             ` brian m. carlson
2025-10-08 21:59       ` Taylor Blau
2025-10-16 21:42         ` brian m. carlson
2025-10-02 22:33   ` brian m. carlson
2025-10-01 16:01 ` Taylor Blau
2025-10-01 16:20   ` Michal Suchánek
2025-10-01 22:16     ` brian m. carlson
2025-10-02 12:13       ` Michal Suchánek
2025-10-02 13:09         ` Michal Suchánek
2025-10-01 20:36   ` Junio C Hamano
2025-10-01 22:42     ` brian m. carlson
  -- strict thread matches above, loose matches on Subject: below --
2025-10-08 19:06 James Frost
2025-10-09  5:30 ` Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aOTtPxsdzJLPCruk@kitsune.suse.cz \
    --to=msuchanek@suse.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=luca.milanesio@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).