[almighty] almighty-jobs merge policy

[Aslak Knutsen]

Ah! Well, yes. :)

-aslak-

On Thu, Sep 1, 2016 at 1:54 PM, Pavol Pitonak <ppitonak at redhat.com> wrote:

> I'm sorry for not being clear enough.
>
> I was referring to change in Github merge policy... IMHO changes in
> settings of GitHub repository that might influence team's workflow should
> be done after discussion in team.
>
> On Thu, Sep 1, 2016 at 1:36 PM, Aslak Knutsen <aslak at redhat.com> wrote:
>
>>
>>> No matter what your opinion is, IMHO this kind of changes should be
>>> discussed in team *before* applying changes to Github repo.
>>>
>>>
>> The best way to discuss code is to have some code to discuss. A Review
>> can happen at any time during the codes lifetime; just a rough idea to a
>> polished feature. Regardless of which lifecycle you Review in, the process
>> is similar; Here is Code, comment comment comment, change change comment
>> change change...
>>
>> A PR can be used in my different ways; A Notification of Work In
>> Progress, Tracking Work in Progress, Idea/approach sharing, Move change
>> upstream etc.. GitHub has only really thought about the "Move Change
>> upstream" part, GitLab is including the "Work In Progress" part as well.
>>
>>
> I completely agree
>
>
>> -aslak-
>>
>>
>>
>>>
>>> On Thu, Sep 1, 2016 at 12:26 PM, Aslak Knutsen <aslak at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Sep 1, 2016 at 11:54 AM, Karanbir Singh <kbsingh at redhat.com>
>>>> wrote:
>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 01/09/16 02:03, Aslak Knutsen wrote:
>>>>> > I'm assuming this change is related to PR to Master CI auto merge
>>>>> > or similar, but any particular reason why 'merge' vs
>>>>> > 'squash/rebase' for this part? (beyond 'that's what the software
>>>>> > supports') ?
>>>>>
>>>>> This was really just to make sure that if a PR comes through, the
>>>>> commit history for the PR is retained once its merged in - otherwise
>>>>> in the squash model, github will consolidate all the commits down to 1
>>>>> ; atleast to me that seems counter productive.
>>>>>
>>>>
>>>> Yeah, GitHub get's that wrong. :)
>>>>
>>>> With merge, you assume the PR history is relevant to upstream;
>>>> https://github.com/almighty/almighty-core/pull/111/commits
>>>>
>>>> The GitHub Squash allow you to do a PR cleanup in UI before it going
>>>> upstream,
>>>> with Merge you're forced to do it locally. (assuming you want a commit
>>>> to have any meaning
>>>> in upstream and not just be a developers braindump/error log)
>>>>
>>>> But Squash is really just intended to be a manual thing as a automated
>>>> process
>>>> wouldn't know how to make any sense out of it anyway.
>>>>
>>>> -aslak-
>>>>
>>>>
>>>>
>>>>>
>>>>> regards,
>>>>>
>>>>> - --
>>>>> Karanbir Singh, Project Lead, The CentOS Project, London, UK
>>>>> Red Hat Ext. 8274455 | DID: 0044 207 009 4455
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v2.0.22 (GNU/Linux)
>>>>>
>>>>> iQEcBAEBAgAGBQJXx/ryAAoJEI3Oi2Mx7xbtD8cH/1nqVwaRRvEyMOOND6oIQdb8
>>>>> nQrDLqBAjeKwywTAgf8G2or3Fk7nB/Y7e5vWzsx2tvyEMWg6stCPypydFqKdtvkk
>>>>> eoQiWK3HI5lIhbpRDmIc/YZjy+09Xf4yPaZs690dTiK1B0m3Zkgm2J0MJ6WRWpxn
>>>>> AVmhT9qgTQMR6fWqa1N+Hut59Qi6N1dGbEXEsBZslP7pD96HJocEBwkkaKMY8Ay0
>>>>> OwBHph3r1NddI2uhg9I78oVCCeNj6RDseIQOK/26MymYp5FCsiBiCUuRHIA/+42W
>>>>> EHGmO51xwMmREyZ3hvYAZZ9dPjF/5J+iskp6hMfgW5Z4nTdvToEpkb8cRwNR4Ns=
>>>>> =gc97
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> almighty-public mailing list
>>>> almighty-public at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160901/cb11d1f6/attachment.htm>