[almighty] almighty-jobs merge policy

[Karanbir Singh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

note that this github repo in question was being provisioned, and if
it had an impact on someone's workflow, I would have brought it up
before making the change.

but ofcourse, everyone's looked at the github repo in question and
knows this already :)

- - KB

On 01/09/16 13:01, Aslak Knutsen wrote:
> Ah! Well, yes. :)
> 
> -aslak-
> 
> On Thu, Sep 1, 2016 at 1:54 PM, Pavol Pitonak <ppitonak at redhat.com 
> <mailto: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 
> <mailto: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
> <mailto:aslak at redhat.com>> wrote:
> 
> 
> 
> On Thu, Sep 1, 2016 at 11:54 AM, Karanbir Singh <kbsingh at redhat.com
> <mailto:kbsingh at redhat.com>> wrote:
> 
> 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 
>> <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,
> 
> 
> 
> 
> _______________________________________________ almighty-public
> mailing list almighty-public at redhat.com 
> <mailto:almighty-public at redhat.com> 
> https://www.redhat.com/mailman/listinfo/almighty-public 
> <https://www.redhat.com/mailman/listinfo/almighty-public>
> 
> 
> 
> 
> 

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

iQEcBAEBAgAGBQJXyCBGAAoJEI3Oi2Mx7xbtsiEIAJ/P4rRfGUMLkOUik/u2hp4d
R9gT1sdO4W0WOimV+qvjOvYm67dadjaqivnxTsmXKkKNuAa90RiZOUSdpfuaJW8v
hUKwcUfSGBimIJSg9Iv0fYX5HmRjk5HPgybxze6iiiJgse7e5AaRHYPmM0Jpp20V
1KQs8MhomTvXexCf3U58wcOe5wyzVCuTJ1ZcnaeEkpyC0dCVyIHHoZs+6roEi0TU
AN+Iu1k11/QH0mPTSflVTuxlsRoSC4oCC0+MigENl07xADmasGi6dBWJ9mP3Sw/Q
LkLkd2eWXwhvSnEREJRnyFqGxjiDPfRjXp/eixqXcEwAyZgGQZTY4jGwZyMEP7Q=
=ZxZU
-----END PGP SIGNATURE-----