From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29208 invoked by alias); 19 Sep 2019 15:30:37 -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 29199 invoked by uid 89); 19 Sep 2019 15:30:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=academic, browser, more!, more X-HELO: mail-yb1-f193.google.com Received: from mail-yb1-f193.google.com (HELO mail-yb1-f193.google.com) (209.85.219.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2019 15:30:34 +0000 Received: by mail-yb1-f193.google.com with SMTP id o80so1480218ybc.6 for ; Thu, 19 Sep 2019 08:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qxt9J0CpCp28s6BqN2ghImAtOtFrT3z9Diw9TVf8L0w=; b=nyWKU5IMGzGecxeDpXchcKpRyvYLoBE784UKuVkuba9Tc+acMbKL3ZWg9c0pjElPqM 6OupeBoPnH7oo0+te2mHiiQP6pLOK0qr/+O2W8Zyu+QIEy49ZLSgiLtm4I5ugYZsLUN/ MjNWFWwnu2Lf2QHPkOdtcUG8uSpOZHIFdM7DoUbSO/Xm04xlki11kKtdX/Dj9MP7w8ZI QEo/GvU3QD6O1J5KvN3vQXHYLYm73yP7rD+S7qCHpEWMfcYjJ5/wdRZZhqRS9ZXlwulc tUtsSjTxdaZ6x+SwhHM90cce3/qT1l18DkdEwbsvfHvl2G2hCj0tzs9DFbXQ/MbCTrts PECQ== MIME-Version: 1.0 References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> In-Reply-To: From: Janne Blomqvist Date: Thu, 19 Sep 2019 15:30:00 -0000 Message-ID: Subject: Re: Proposal for the transition timetable for the move to GIT To: Damian Rouson Cc: "Richard Earnshaw (lists)" , gcc mailing list Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00145.txt.bz2 On Thu, Sep 19, 2019 at 5:43 PM 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. Yes. What I'm saying is we ("we" as in whoever is responsible for the git conversion, or the gcc development community in general) should have some kind of workflow documented. Doesn't have to be an academic paper or a best-seller book written by some self-styled "thought leader", but there should be some guidance. A page in the wiki or in wwwdocs is good enough for me. > A simple and useful workflow to consider is the > GitHub Flow: https://guides.github.com/introduction/flow/. 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. Where will the GCC > git repository be hosted? Yes, I'm aware (though I do think gitflow is a bit too overcomplicated for its own good, but YMMV). >> 1. git checkout -b pr1234-foo # A private branch based on latest 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? It could make contributing more > inviting to new developers. A large community of developers has grown up around the > above workflows and are used to using the related tools. 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). 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. 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. I do see the attractiveness of these kinds of tools, however as the original message in this thread stated, at this point we have enough to chew on just getting the git transition done. Spending another year (or more!) bikeshedding various other workflow improvements to tack on to the git transition would be a mistake. After the git transition is done and the smoke has settled, we can start thinking whether we want to move away from the current email-based workflow. As for the email-based workflow, the nice thing with git is that it has nice support for it, via the format-patch, send-email, am, and apply commands. So at least it will be an improvement upon the current svn-based workflow. >> 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. If you test right after merging 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. Ugh. Merging master into your branch and then merging your branch back into master makes the history somewhat convoluted, IMHO. > A lot of the testing can be automated. 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. Sure. Again, something to look into once the git transition itself is done, IMHO. -- Janne Blomqvist