From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55096 invoked by alias); 25 Oct 2019 16:32:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 54753 invoked by uid 89); 25 Oct 2019 16:32:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=H*f:sk:a5a428d, H*MI:sk:a5a428d, H*i:sk:a5a428d X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Oct 2019 16:32:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572021147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:openpgp:autocrypt:autocrypt; bh=YLBwb5Ilzfj0bS+4YSymH5ZoMJPCBZYDJIQzpCa7Kgk=; b=Jh4x99a6AZkDEZhmuOX+4cQvXiRdieYEDQORApZo62WHAbHCsIxt47z01aTBdqo+zSxb7u h+BdCS86GKrhixL1bfg+oHoRlY22Hmp0rV3hLGHr4TfPBALvGE6d9o2OprMGvNxGe+VREe 3EvaVgnzbszWc+iYGv3HPWHiv/XtjL4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-339-su7uJFkgNhiamUKN93FpEQ-1; Fri, 25 Oct 2019 12:32:23 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 96BF580183D; Fri, 25 Oct 2019 16:32:22 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-8.rdu2.redhat.com [10.10.112.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D7B55C1B5; Fri, 25 Oct 2019 16:32:21 +0000 (UTC) Subject: Re: Proposal for the transition timetable for the move to GIT To: "Richard Earnshaw (lists)" , Damian Rouson , Janne Blomqvist Cc: gcc mailing list References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <5fc4a638-0b6e-fcbe-7920-85c6eecb0a44@redhat.com> Date: Fri, 25 Oct 2019 16:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00159.txt.bz2 On 10/25/19 8:10 AM, Richard Earnshaw (lists) wrote: > On 19/09/2019 15:42, Damian Rouson wrote: >> On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist >> >> wrote: >> >>> >>> One thing that's unclear to me is how should I actually make my stuff >>> appear in the public repo? Say I want to work on some particular >>> thing: >>> >> >> This is essentially a git workflow question.=C2=A0 A simple and useful >> workflow >> to consider is the >> GitHub Flow: https://guides.github.com/introduction/flow/.=C2=A0 Others = to >> consider are on the >> GitLab Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html >> and >> on Atlassian's >> Git Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html.=C2= =A0 >> Where >> will the GCC >> git repository be hosted? >> >> >>> 1. git checkout -b pr1234-foo=C2=A0=C2=A0 # A private branch based on l= atest trunk >>> 2. Then when I'm happy, I send out a patch for review, either manually >>> or with git format-patch + send-email. >>> >> >> Will GCC allow workflows other than emailing patches?=C2=A0 It could make >> contributing more >> inviting to new developers.=C2=A0=C2=A0 A large community of developers = has >> grown up >> around the >> above workflows and are used to using the related tools.=C2=A0 I realize >> emailing patches >> probably seems simple to GCC developers, but that practice is one of the >> main reasons I >> haven't contributed code to GCC even though I have supported GCC >> development financially >> and I frequently interact with GCC developers. My problems with email >> have >> been many. >> I have often forgotten to set my emails to plain text so my emails to GCC >> lists bounce and >> I have to resend them (often hours later if I didn't see the bounce right >> away).=C2=A0 When I >> receive patches from GCC developers, I get frustrated with determining >> what >> -p argument >> to pass when applying the patch. I'm equally daunted with the process of >> searching through >> emails to find related discussions rather than having all the dialogue >> about a pull request >> (which contains the same information as a patch) in one place.=C2=A0 And= with >> plain-text emails >> as the medium, I really miss the ability to format dialogues with >> Markdown, >> including inserting >> hyperlinks but also to tie comments to specific lines of code in a >> browser >> interface to the >> pull request, etc. >> >> 3. Patch goes through a few revisions, and is approved. >>> 4. Now what? >>> 4a) Do I merge my private branch to master (err, trunk?), then commit >>> and >>> push? >>> >> >> It's safer to first merge master into your branch and then retest with >> all >> the new commits >> that have hit master since you branched.=C2=A0 If you test right after m= erging >> and find no >> problems (and no new commits hit master while you're testing), then the >> head of your >> branch will reflect the state master will reach when you merge into >> master >> so you know >> it's safe to do so. >> >> >>> 4b) Or do I first rebase my branch on top of the latest master, to >>> produce a slightly less branchy history? >>> >> >> A lot of people find rebasing to be overly complicated and error-prone >> (with the exception >> of interactive rebasing for the purpose of squashing commits that haven't >> been pushed to >> the remote repository).=C2=A0 The above merging steps are easier at the >> expense >> of having >> merge commits in the history, which I think is good to better document >> the >> branching >> history. >> >> >>> 4c) Or do I (manually?) apply my patch on master, to create a linear >>> history? >> >> >> See above.=C2=A0 I recommend "git merge" over manually applying patches. >> >> >>> 4d) Something else entirely? >>> >> >> A lot of the testing can be automated.=C2=A0 For example, on GitHub, git= hooks >> can be set up >> to ensure that if a branch has an open pull request against master (or >> other designated >> branches), tests run for that branch every time a new commit is pushed to >> it. >> >> Damian >> >=20 > There will be NO changes to the basic workflow at the time of the > transition, other than those that are strictly required by using git > instead of SVN (ie you now have to type "git clone" rather than "svn > checkout" and, for committers, "git push" rather than "svn checkin"). >=20 > This is not to suggest that at some later date the workflows cannot > change, but at this point in time the only change will be the underlying > storage mechanism for the master repository.=C2=A0 As Segher said, NO SCO= PE > CREEP. Agreed. Let's deal with the conversion and only the conversion. Any discussion about changing the workflows should be deferred until after the conversion is done. jeff