Re: Proposal for the transition timetable for the move to GIT

[Janne Blomqvist <blomqvist.janne@gmail.com>]

On Thu, Sep 19, 2019 at 5:43 PM Damian Rouson
<damian@sourceryinstitute.org> 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.

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