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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-06-06 20:57:27

On Thu, 6 Jun 2019 at 22:20, stefan <stefan_at_[hidden]> wrote:
> On 2019-06-06 3:59 p.m., Mateusz Loskot wrote:
> > On Thu, 6 Jun 2019 at 19:45, stefan <stefan_at_[hidden]> wrote:
> >> On 2019-06-06 1:13 p.m., Mateusz Loskot wrote:
> >>> So, following our chat on Gitter, let's agree that a part of GSoC work is ready
> >>> to be submitted as PR against develop in upstream repo, iff:
> >>>
> >>> 1. The work is a complete feature.
> >>> 2. The work includes tests.
> >>> 3. The work includes at least basic documentation describing
> >>>       what a feature does and how to use it.
> >> All good.
> >>
> >>> 4. The work has been reviewed and approved
> >>>       (i.e. via PR in `BoostGSoC19/gil-{miral,olzhas}` repo).
> >> While I fully expect the development process prior to a PR to involve
> >> (informal) code reviews and even collaboration, I'm not sure mandating
> >> two PRs in a row (once to get it into the GSoC repo, then again to get
> >> it into upstream) is really necessary or useful.
> > It is not clear to me what workflow you propose above.
> >
> > As we discussed (I think on Gitter, then summarised in [1], esp. point 6.),
> >
> > 1. Completed features are submited as PRs from feature branch
> >      against develop branch in `BoostGSoC19/gil-{miral,olzhas}`
> > 2. The PRs undergo iterations or review-update-review.
> > 3. The PRs are approved and the features are merged into develop
> >       branch in `BoostGSoC19/gil-{miral,olzhas}`
>
> Ah, I think this is where we (slightly) disagree:
> [...]
> All the GSoC processes (reviewing code as part of the mentoring process)
> should be left to the mentor / student to agree upon among themselves,
> and not mandated formally. Nothing prevents you to formally require PRs
> and reviews like the above, but what works for you may not work for me.

> And as far as the overall code quality is concerned, it shouldn't matter
> as there already is one required code review in the workflow before it
> gets into the upstream repo.

Yes.

Initially, it was just me leading the discussions with Miral and
Olzhas on Gitter,
and since I had not assumed any merges to upstream before the end of GSoC,
I suggested to stick to PRs between branches within their repos at BoostGSoC19.

So, I just listed a bunch of steps as instruction that is easy to follow.
I did not aim to mandate anything.

> > [1] Notice, there was no reaction or objection to this
> > https://lists.boost.org/boost-gil/2019/05/0210.php
>
> True, sorry. I saw the mention of "kanban" and stopped reading. :-)

I just used GitHub's nomenclature. It's rubbish, I agree :)

The whole idea of making use of GitHub "Projects" came from Cem Bassoy
(you must have received that too) and I actually liked that as it is clear
way to organize tasks as issues and move them between ToDo, Progress, Done.
I also thought that having an issue for a task (e.g. algorithm) makes
up a focused
public space for comments about design, etc. And, progress report is generated
automagically :) So, I picked that idea from Cem.

> > Yesterday, AFAIU, you suggested to submit such merged features
> > via PRs to develop branch in boostorg/gil.
> >
> > Regarding the actual procedure to do the above:
> >
> > 1. Since BoostGSoC19/gil-miral is a fork of boostorg/gil,
> >      Miral can submit PR directly to boostorg/gil.
>
> Right. That's the process I had / have in mind.
>
> > 2. Since BoostGSoC19/gil-olzhas is a duplicate, not a fork,
> >      Olzhas needs to push to his own fork at simmplecoder/gil
> >      and from there submit PR to boostorg/gil
>
> I'm confused. https://github.com/BoostGSoC19/gil-olzhas/ looks like an
> ordinary fork of boostorg/gil to me. Is it not ?

No, it is not a fork.
It is a "duplicate" in GitHub terms.

Only Miral's is a fork, but that is because she created it first.
There can not be two forks of the same repo within the same GitHub organization:
https://github.community/t5/Support-Protips/Alternatives-to-forking-into-the-same-account/ba-p/7428

So, to keep things simple, I suggested Miral and Olzhas to unify our workflows
and consider both, Miral's and Olzhas' as "duplicates" (it also makes easier
to provide them with hand in using git, etc.).
This all we discussed on Gitter during the first days of GSoC.

Now, keeping up the notion of "duplicate" for both, there is no shortcut really
for submitting PR with completed features to develop in upstream.

Or, do you see a better way?

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