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

From: stefan (stefan_at_[hidden])
Date: 2019-06-06 20:20:16

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: I wouldn't mandate any 
of the above. Or rather, I wouldn't formalize how the work is done 
within the BoostGSoC19 repos. As far as the formal workflow is 
concerned, I'd treat them like any other contributor's repo. The code is 
formally reviewed as usual, i.e. when the PR (to the upstream repo) is 
processed.

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.

>
> [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. :-)

> 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 ?

Stefan

--
       ...ich hab' noch einen Koffer in Berlin...