Re: [gsoc] Merging completed tasks to develop branch in upstream repo

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-06-07 19:13:56

On Fri, 7 Jun 2019 at 09:26, Mateusz Loskot <mateusz_at_[hidden]> wrote:
> On Fri, 7 Jun 2019 at 02:44, Olzhas Zhumabek <anonymous.from.applecity_at_[hidden]> wrote:
> >
> > I would still like to have one branch before develop for me though,
> > the gsoc2019 one.
>
> As Stefan said, you are free to decide on your workflow.
>
> As I mentioned earlier in [1] , the only question that is unclear to me is about
> flow and direction of PRs for partial submissions (of completed features,
> of course).
>
> For example, if you will do all your work in gsoc2019 branch, then how to
> approach the iterations of PRs for completed features for review? e.g.
>
> 1. Update gsoc2019 branch from upstream develop branch
> 2. Branch off gsoc2019 to create short-lived feature branch
> 3. Submit PR from feature branch to upstream develop branch for review
> 4. Once PR is merged into upstream develop, go to 1. to update your gsoc2019
> 5. Repeat steps 2 to 4
>
> Although Stefan expressed he is not enthusiastic about formal guidelines,
> I still believe it is important to outline some basic steps of workflow to avoid
> any Git mess and try to maintain clean history, and to make your, the students,
> life easier if a procedure is given as no-brainer instruction.
> That is the question I asked Stefan in [1] to clarify.
>
> [1] https://lists.boost.org/boost-gil/2019/06/0227.php

To approach this thread to some sort of conclusion and closure,
I will share my final thoughts.

------------------------------------------------------------------------------------
If I was a student, I'd work from my private fork this way:

1. Branches in fork `<owner>/gil`

- `gsoc2019/1-feature-a`
- `gsoc2019/2-feature-b`
- `gsoc2019/3-feature-c`
- ...
- `gsoc2019` <- `gsoc2019/[1..N]-feature` branches merged (in 1..N order)
- `develop` <- just updated from `boostorg/gil`

After GSoC is over, all intermediate `gsoc2019/[1..N]-feature` and
total `gsoc2019` is pushed to for archive.

2. PRs to `develop` in `boostorg/gil` upstream

Once feature work is completed, i.e. `gsoc2019/[1..N]-feature`
branch is ready for review and approval, PR is submitted
from `gsoc2019/[1..N]-feature` branch to to `develop` in `boostorg/gil`.

3. PR review

Once PR is approved, it is merged into to `develop` in `boostorg/gil`

Then, `develop` in `<owner>/gil` is updated from  `develop` in `boostorg/gil`.

Finally, `git branch -b gsoc2019/4-feature-d develop` to create new
branch for next feature.

The cycle repeats.

Benefits:

1. Features merged to upstream from feature branches
2. Each feature branch is archived as a milestone.
3. All milestones are accumulated and archived in chronological order.
4. Sum of 2. and 3. helps to achieve Olzhas goal to archive his work
at BoostGSoC19
5. Per feature, there is single PR, single review and approval process.
6. There is clear path from feature branch to develop that ensures
clear history maintenance.
7. It should be easy to reset, move back to any milestone, start over, etc.
------------------------------------------------------------------------------------

Miral, if you would prefer to move to your private fork and keep working
from there instead of BoostGSoC19, follow similar approach as
Stefan & Olzhas submitting PRs against upstream develop from
feature branches in your fork, then feel free to do so.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net