From: Jeff Law <law@redhat.com>
To: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>,
Damian Rouson <damian@sourceryinstitute.org>,
Janne Blomqvist <blomqvist.janne@gmail.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Proposal for the transition timetable for the move to GIT
Date: Fri, 25 Oct 2019 16:32:00 -0000 [thread overview]
Message-ID: <5fc4a638-0b6e-fcbe-7920-85c6eecb0a44@redhat.com> (raw)
In-Reply-To: <a5a428d8-7a0b-6cff-1938-23610b917244@arm.com>
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
>> <blomqvist.janne@gmail.com>
>> 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. 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?
>>
>>
>>> 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.
>>
>> 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.
>>
>>
>>> 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). 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. I recommend "git merge" over manually applying patches.
>>
>>
>>> 4d) Something else entirely?
>>>
>>
>> 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.
>>
>> Damian
>>
>
> 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").
>
> 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. As Segher said, NO SCOPE
> 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
next prev parent reply other threads:[~2019-10-25 16:32 UTC|newest]
Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 12:02 Richard Earnshaw (lists)
2019-09-17 12:24 ` Richard Biener
2019-09-17 13:50 ` Richard Earnshaw (lists)
2019-09-17 16:35 ` Joseph Myers
2019-09-17 17:51 ` Richard Earnshaw (lists)
2019-09-17 16:33 ` Joseph Myers
2019-09-19 12:04 ` Janne Blomqvist
2019-09-19 14:43 ` Damian Rouson
2019-09-19 15:30 ` Janne Blomqvist
2019-10-25 14:10 ` Richard Earnshaw (lists)
2019-10-25 16:32 ` Jeff Law [this message]
2019-09-19 15:30 ` Richard Earnshaw (lists)
2019-09-19 15:49 ` Damian Rouson
2019-09-19 15:35 ` Maxim Kuvyrkov
2019-12-06 14:44 ` Maxim Kuvyrkov
2019-12-06 17:21 ` Eric S. Raymond
2019-12-06 17:39 ` Richard Biener
2019-12-06 19:46 ` Eric S. Raymond
2019-12-06 20:43 ` Sandra Loosemore
2019-12-07 2:57 ` Segher Boessenkool
2019-12-09 18:19 ` Joseph Myers
2019-12-09 18:40 ` Bernd Schmidt
2019-12-09 20:45 ` Joseph Myers
2019-12-09 22:12 ` Eric S. Raymond
2019-12-09 19:28 ` Eric S. Raymond
2019-12-11 14:40 ` Maxim Kuvyrkov
2019-12-11 15:03 ` Richard Earnshaw (lists)
2019-12-11 15:19 ` Jonathan Wakely
2019-12-11 15:21 ` Richard Earnshaw (lists)
2019-12-11 15:36 ` Joseph Myers
2019-12-11 16:02 ` Jonathan Wakely
2019-12-11 17:47 ` Eric S. Raymond
2019-12-16 2:19 ` Joseph Myers
2019-12-11 15:30 ` Dennis Luehring
2019-12-11 15:36 ` Richard Earnshaw
2019-12-11 17:36 ` Eric S. Raymond
2019-12-06 20:49 ` Bernd Schmidt
2019-12-16 9:53 ` Mark Wielaard
2019-12-16 11:29 ` Joseph Myers
2019-12-16 12:43 ` Mark Wielaard
2019-12-16 13:36 ` Segher Boessenkool
2019-12-16 13:54 ` Eric S. Raymond
2019-12-16 14:05 ` Segher Boessenkool
2019-12-16 14:13 ` Joseph Myers
2019-12-16 15:37 ` Segher Boessenkool
2019-12-16 16:36 ` Joseph Myers
2019-12-16 17:40 ` Jeff Law
2019-12-25 8:12 ` Alexandre Oliva
2019-12-25 12:07 ` Eric S. Raymond
2019-12-25 12:24 ` Segher Boessenkool
2019-12-25 14:16 ` Joseph Myers
2019-12-25 18:50 ` Eric S. Raymond
2019-12-25 19:18 ` Segher Boessenkool
2019-12-26 6:09 ` Alexandre Oliva
2019-12-26 11:04 ` Joseph Myers
2019-12-26 11:17 ` Jakub Jelinek
2019-12-26 12:10 ` Joseph Myers
2019-12-26 16:11 ` Maxim Kuvyrkov
2019-12-26 16:58 ` Joseph Myers
2019-12-26 18:36 ` Jakub Jelinek
2019-12-26 18:59 ` Joseph Myers
2019-12-27 11:21 ` Richard Earnshaw (lists)
2019-12-27 11:33 ` Andrew Pinski
2019-12-27 13:35 ` Segher Boessenkool
2019-12-27 11:35 ` Joseph Myers
2019-12-27 12:37 ` Richard Earnshaw (lists)
2019-12-28 2:27 ` Eric S. Raymond
2019-12-28 11:23 ` Joseph Myers
2019-12-28 12:19 ` Segher Boessenkool
2019-12-28 17:11 ` Richard Earnshaw (lists)
2019-12-28 20:28 ` Segher Boessenkool
2019-12-29 1:45 ` Julien "FrnchFrgg" Rivaud
2019-12-29 10:41 ` Segher Boessenkool
2019-12-29 11:02 ` Richard Biener
2019-12-29 11:47 ` Julien '_FrnchFrgg_' RIVAUD
2019-12-29 13:31 ` Segher Boessenkool
2019-12-29 13:51 ` Julien '_FrnchFrgg_' RIVAUD
2019-12-29 12:15 ` Segher Boessenkool
2019-12-29 16:32 ` Richard Earnshaw
2019-12-29 16:37 ` Julien '_FrnchFrgg_' RIVAUD
2019-12-29 11:42 ` Julien '_FrnchFrgg_' RIVAUD
2019-12-29 13:26 ` Segher Boessenkool
2019-12-29 13:48 ` Julien '_FrnchFrgg_' RIVAUD
2019-12-29 15:01 ` Segher Boessenkool
2019-12-29 17:31 ` Ian Lance Taylor via gcc
2019-12-30 0:31 ` Julien "FrnchFrgg" Rivaud
2019-12-29 21:31 ` Thomas Koenig
2019-12-29 23:57 ` Jeff Law
2019-12-27 13:29 ` Segher Boessenkool
2019-12-26 20:31 ` Richard Biener
2019-12-27 1:32 ` Joseph Myers
2019-12-27 10:14 ` Maxim Kuvyrkov
2019-12-28 1:55 ` Eric S. Raymond
2019-12-29 18:31 ` Maxim Kuvyrkov
2019-12-29 18:55 ` Joseph Myers
2019-12-29 22:47 ` Eric S. Raymond
2019-12-29 23:00 ` Joseph Myers
2019-12-29 23:13 ` Segher Boessenkool
2019-12-30 15:36 ` Richard Earnshaw (lists)
2019-12-30 22:37 ` Segher Boessenkool
2019-12-30 22:58 ` Joseph Myers
2019-12-31 0:23 ` Segher Boessenkool
2019-12-31 12:48 ` Segher Boessenkool
2019-12-31 3:09 ` Eric S. Raymond
2019-12-29 22:24 ` Richard Earnshaw (lists)
2019-12-30 0:18 ` Joseph Myers
2019-12-30 0:44 ` Julien "FrnchFrgg" Rivaud
2019-12-30 12:39 ` Maxim Kuvyrkov
2019-12-30 13:01 ` Maxim Kuvyrkov
2019-12-30 15:31 ` Richard Earnshaw (lists)
2019-12-30 15:49 ` Maxim Kuvyrkov
2019-12-30 16:08 ` Richard Earnshaw (lists)
2020-01-02 2:59 ` Alexandre Oliva
2020-01-02 10:58 ` Richard Earnshaw (lists)
2020-01-08 20:46 ` Maxim Kuvyrkov
2020-01-08 22:11 ` Eric S. Raymond
2020-01-08 23:34 ` Joseph Myers
2020-01-09 2:38 ` Segher Boessenkool
2020-01-09 12:12 ` Richard Earnshaw (lists)
2020-01-09 14:01 ` Eric S. Raymond
2020-01-11 11:30 ` Segher Boessenkool
2020-01-10 7:33 ` Maxim Kuvyrkov
2020-01-10 9:49 ` Richard Earnshaw (lists)
2020-01-10 11:38 ` Richard Biener
2020-01-10 12:09 ` Iain Sandoe
2020-01-10 13:11 ` Joseph Myers
2020-01-10 12:53 ` Nathan Sidwell
2020-01-10 14:13 ` Martin Liška
2020-01-11 11:57 ` Segher Boessenkool
2020-01-11 11:52 ` Segher Boessenkool
2020-01-10 13:31 ` Bernd Schmidt
2020-01-10 15:27 ` Eric S. Raymond
2020-01-10 15:09 ` Maxim Kuvyrkov
2020-01-10 15:16 ` Joseph Myers
2020-01-10 15:33 ` Maxim Kuvyrkov
2020-01-11 7:04 ` Gerald Pfeifer
2020-01-09 5:07 ` Jeff Law
2020-01-09 12:30 ` Joseph Myers
2020-01-10 15:27 ` Joseph Myers
2020-01-11 7:06 ` Gerald Pfeifer
2020-01-14 8:21 ` Jeff Law
2019-12-26 22:33 ` Joseph Myers
2019-12-26 19:16 ` Eric S. Raymond
2019-12-26 20:08 ` Alexandre Oliva
2019-12-26 20:28 ` Joseph Myers
2019-12-27 12:06 ` Alexandre Oliva
2019-12-27 12:21 ` Joseph Myers
2019-12-28 2:33 ` Eric S. Raymond
2019-12-26 21:19 ` Eric S. Raymond
2019-12-25 12:10 ` Segher Boessenkool
2019-12-25 14:13 ` Joseph Myers
2019-12-29 16:47 ` Mark Wielaard
2019-12-29 22:42 ` Joseph Myers
2019-12-16 16:27 ` Eric S. Raymond
2019-12-16 16:47 ` Segher Boessenkool
2019-12-16 16:04 ` Jeff Law
2019-12-16 16:37 ` Eric S. Raymond
2019-12-16 16:47 ` Jeff Law
2019-12-31 13:43 ` Joseph Myers
2019-12-31 14:13 ` Richard Earnshaw (lists)
2019-12-31 17:26 ` Segher Boessenkool
2019-12-16 13:56 ` Joseph Myers
2019-12-16 14:17 ` Mark Wielaard
2019-12-16 16:29 ` Joseph Myers
2019-12-16 13:53 ` Joseph Myers
2019-12-16 16:39 ` Jeff Law
2019-12-16 17:57 ` Richard Biener
2019-12-16 16:55 ` Jeff Law
2019-12-16 17:08 ` Joseph Myers
2019-12-16 19:15 ` Eric S. Raymond
2019-12-16 21:59 ` Segher Boessenkool
2019-12-16 22:14 ` Jeff Law
2019-12-16 22:42 ` Segher Boessenkool
2019-12-16 23:26 ` Joseph Myers
2019-12-16 23:44 ` Eric S. Raymond
2019-12-18 18:07 ` Jeff Law
2019-12-18 18:24 ` Joseph Myers
2019-12-19 0:57 ` Eric S. Raymond
2019-12-18 19:50 ` Segher Boessenkool
2019-12-18 20:43 ` Jeff Law
2019-12-20 16:28 ` Segher Boessenkool
2019-12-19 2:34 ` Unix philosopy vs. poor semantic locality Eric S. Raymond
2019-12-19 3:16 ` Joseph Myers
2019-12-19 5:46 ` Eric S. Raymond
2019-12-19 0:46 ` Proposal for the transition timetable for the move to GIT Eric S. Raymond
2019-12-16 23:34 ` Eric S. Raymond
2019-12-16 23:18 ` Joseph Myers
2019-12-16 23:19 ` Eric S. Raymond
2019-12-18 17:27 ` Segher Boessenkool
2019-12-16 13:33 ` Segher Boessenkool
2019-09-19 17:04 ` Paul Koning
2019-10-25 14:02 ` Richard Earnshaw (lists)
2019-09-20 15:49 ` Jeff Law
2019-09-21 9:11 ` Segher Boessenkool
2019-09-21 9:39 ` Andreas Schwab
2019-09-21 9:51 ` Segher Boessenkool
2019-09-21 10:04 ` Andreas Schwab
2019-09-21 9:26 ` Segher Boessenkool
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=5fc4a638-0b6e-fcbe-7920-85c6eecb0a44@redhat.com \
--to=law@redhat.com \
--cc=Richard.Earnshaw@arm.com \
--cc=blomqvist.janne@gmail.com \
--cc=damian@sourceryinstitute.org \
--cc=gcc@gcc.gnu.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).