Re: [Pulp-dev] 3.7.0 Release Timeline & Go/No-Go Chat Meeting

2020-09-23 Thread Brian Bouterse 
A lot of progress was made today, the final 3.7.0 and several plugin
compatibility releases should go out tomorrow.

* 3.6.4 pulpcore and its installer are fully published and announced
* pulpcore==3.7.0, pulp_file==1.3.0, and pulp_ansible==0.4.0 are published
but not announced (waiting on pulpcore announcement first)
* pulp_container==2.1.0 is publishing right now (thanks @ipanova and
@dkliban)
* 3.6.4 installer is not yet published, and this is what is holding up the
announcement. I will resume tomorrow, and then proceed to announce
* pulp-certguard should happen tomorrow, along with galaxy_ng upgrading to
the latest pulpcore, pulp_ansible, and pulp_container. pulp_rpm I also
think is likely




On Wed, Sep 23, 2020 at 12:29 PM Brian Bouterse  wrote:

> Through IRC discussion here's what we learned:
>
> * it's generally agreed plugins should not switch their pulpcore version
> in a z-stream
> * pulpcore 3.7.0 is on pypi so plugins can now use pulpcore>=3.7,<3.9 and
> start releasing. Bump your y-versions even if there are no changes (it's
> strange I know but ... bullet point one)
> * 3.6.3 is broken, and I am now going to release a 3.6.4 and an installer
> version 3.6.4 first, see this release tracker issue
> https://pulp.plan.io/issues/7557
> * We're waiting on pulp_file and pulp_rpm compat releases for 3.7.0 before
> the installer is released
> * Once the installer and pulpcore bits are available (both 3.7.0 and
> 3.6.4) announcements will go to pulp-list
>
>
>
>
> On Tue, Sep 22, 2020 at 7:15 PM Brian Bouterse 
> wrote:
>
>> 3.7.0 is technically released, but the pulp_file PR is failing due to a
>> variety of reasons. I'll continue on it (and the pulp_ansible release PR
>> also failing) tomorrow.
>>
>> I still need to release the installer, and then proceed with the
>> announcements.
>>
>> On Fri, Sep 18, 2020 at 1:13 PM Brian Bouterse 
>> wrote:
>>
>>> We had our final go/no-go check in today, and we determined 3.7.0 is
>>> on-track for the Sept 22nd release date.
>>>
>>> You can see the milestone's work items here:
>>> https://tinyurl.com/y6rqlufb
>>>
>>> * Everything except 7460 is expected to merge, or at least be in POST,
>>> by EOB today
>>> * 7460 is a very small piece of work that a meeting on Monday will
>>> coordinate
>>> * Selinux EL7 and EL8 policies (not in work query since it doesn't block
>>> the pulpcore release due to not being in pulpcore's bits) is also done!
>>>
>>> Thanks to everyone who put in so much hard work to get this release
>>> ready.
>>>
>>>
>>> On Tue, Sep 15, 2020 at 12:51 PM Brian Bouterse 
>>> wrote:
>>>
 At the go/no-go check in today, we determined the 3.7.0 is on-track for
 the Sept 22nd release date.

 The next check-in meeting on #pulp-meeting is set up for Friday Sept
 18th, 12pm - 12:30pm EDT. https://everytimezone.com/?t=5f63f880,3c0

 ## Notes

 * All remaining pulpcore and pulpcore installer items to be included
 are now tagged in the 3.7.0 milestone:
 https://pulp.plan.io/versions/126
 * You can see a query-based of the milestone sorted by status here:
 https://tinyurl.com/y6rqlufb
 * We believe all items at ASSIGNED will be merged at our current pace
 by Friday
 * The 4 items at NEW are all now marked HIGH prio
 * All code must be merged by the end of business on the 21st. The 22nd
 is just release day
 * The SELinux deliverables (EL7 and EL8 policies) are required for
 3.7.0 but are not included on this milestone because they are shipped
 separately from pulpcore and therefore do not need to block its release
 * No significant pulp_file items were discussed

 ## The four items at NEW

 7471 - The biggest risk. The installer team will be discussing this
 today and through the end of the week
 7460 - A small item. A meeting on monday was already set up to finalize
 it's merge. This will likely merge on the 21st
 7413 - To be done on docs day this Thursday the 17th
 7411 - Technically not blocking the release and will be removed if not
 merged by end of business on the 21st. It is still high prio though, for
 anyone who is on the CI mini-team and can work on it

 Thanks to everyone who participated in our release check in today!


 On Fri, Sep 4, 2020 at 3:20 PM Brian Bouterse 
 wrote:

> Per the new process, here's the tracker (with checklist) for 3.7.0's
> release: https://pulp.plan.io/issues/7463  Right now, the GA date is
> slated for Sept 22nd.
>
> The first go/no-go meeting will happen in #pulp-meeting at the time
> below:
>
> Tuesday Sept 15th, 12pm - 12:30pm EDT.
> https://everytimezone.com/s/68f4535a
>
> Thanks,
> Brian
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] pulpcore 3.6.4 is Generally Available

2020-09-23 Thread Brian Bouterse 
pulpcore 3.6.4 is available on PyPI[0]. This release fixes bindings issues
caused by a dependency that released backwards incompatible changes[1].

# Installation and Upgrade

Users should use the 3.6.4 release of pulp_installer[2] to install or
upgrade their installations. This version of the installer will check
compatibility of all installed plugins with pulpcore 3.6. The installer
will abort if any plugin is incompatible.

The pulp_installer collection can be installed from Ansible Galaxy with the
following command:

ansible-galaxy collection  install --force pulp.pulp_installer

The --force flag will upgrade the collection if you had a previous version
installed.

# Plugin API

There are no plugin API changes.

# Client libraries

Both the Python[3] and Ruby[4] clients are available also.

[0] https://pypi.org/project/pulpcore/3.6.4/
[1] https://docs.pulpproject.org/pulpcore/en/3.6.4/changes.html#id1
[2] https://galaxy.ansible.com/pulp/pulp_installer
[3] https://pypi.org/project/pulpcore-client/3.6.4/
[4] https://rubygems.org/gems/pulpcore_client/versions/3.6.4/
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] CLI team meeting notes

2020-09-23 Thread Robin Chan 
Robin Chan

She/Her/Hers

Satellite Software Engineering Manager - Pulp

Red Hat 

IRC: rchan

Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.




On Wed, Sep 23, 2020 at 12:45 PM David Davis  wrote:

> ## Sept 23, 2020
>
> * [david] Finish CLI PoC demo and upload to asciinema
> * Send out email to pulp-list about PoC?
> * Include asciinema
> * How to install, use CLI
> * Ask for feedback
> * Contact mcorr first and see what she recommends
> * Should we meet regularly?
> * Meet again in two weeks
> * Hopefully have some user feedback
> * We need a decision about where to have the cli code
> * it's not urgent.
> * for now, keep using a single repo
>
I was hoping someone would chime in here on what would be the cli
experience of a plugin that isn't in the pulp org - say debian or chef?
What would be simplest? Or is there an option that would be hard to change
back the other way? This seems like a pretty important decision. I'd like
to see some use cases or requirements that might help determine a decision
or rule out any. And I'd like to hear from other stakeholders.


> * Supporting multiple versions of pulpcore and plugins
> * For now, use conditional statements when needed
> * Versioning of the CLI
> * Needs more thought
>
> David
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Disabling merge by commit

2020-09-23 Thread Mike DePaulo 
On Wed, Sep 23, 2020 at 9:52 AM Justin Sherrill  wrote:

>
> On 9/23/20 7:18 AM, David Davis wrote:
>
> I think the two main things for me are (1) it makes git history more
> linear and (2) it cuts down on the number of commits. Both of these make
> git history more readable.
>
> 3rd main thing for me:
3. It removes extra work when rewriting history. Rewriting history is
desirable in case secret keys, huge binary blobs (that degrade git
performance), etc accidentally get through.

> The 'rebase and merge' option provides a nice balance of letting you
> provide multiple commits and maintain commit history while not creating a
> merge commit and  making a hard to read commit history.  Sometimes it is
> more expressive to have two (or three) commits that make up one pr to make
> it into the source tree.
>
I agree with rebase and merge. Often I need multiple commits for that
reason, or for multiple closely related (pulp_installer) tickets.

I've done this both on the X2Go Project ,
and at a previous job with a big ansible codebase.

-Mike


David


On Wed, Sep 23, 2020 at 6:48 AM Ina Panova  wrote:

> Hi Quirin,
>
>
> 
> Regards,
>
> Ina Panova
> Senior Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
>
> On Wed, Sep 23, 2020 at 10:47 AM Quirin Pamp  wrote:
>
>> "I'd encourage plugins to consider disabling merge by commit as well."
>>
>> In order to evaluate this it would be great, if you could explain why
>> this was decided for pulpcore and pulp_file.
>> You have posted a lot of general information about the different merge
>> type (the "What?"), but not so much on the "Why?".
>>
>> As far as I can tell the main advantage of squish and rebase, is that it
>> leads to a more tidy history in master, at the cost of losing some
>> information on how the sausage was made.
>> As a result squish and rebase becomes increasingly advantageous with
>> increasing PR volume.
>> However, I fail to see an advantage for pulp_deb, which does not have a
>> large PR volume.
>>
>> Or am I missing some relevant part of the argument?
>>
>
> I think your understanding is correct. In my perspective it is important
> to have a tidy history in master no matter how high/low PR traffic you have.
>
> pulp_container has disabled merge by commit as well.
>
>>
>> Quirin
>> --
>> *From:* pulp-dev-boun...@redhat.com  on
>> behalf of David Davis 
>> *Sent:* 22 September 2020 17:16
>> *To:* Pulp-dev 
>> *Subject:* Re: [Pulp-dev] Disabling merge by commit
>>
>> Here's some more information about PR merges as well:
>>
>>
>> https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges
>>
>> David
>>
>>
>> On Tue, Sep 22, 2020 at 11:11 AM David Davis 
>> wrote:
>>
>> Today at open floor, we decided to disable merging by commit for pulpcore
>> and pulp_file PRs. Instead, developers will rebase or squash PRs to merge
>> them. This adds the changes to HEAD instead of interspersing commits and
>> creating a merge commit. This picture of git history comparing pulpcore to
>> foreman (which doesn't merge by commit) illustrates the differences:
>>
>> https://imgur.com/a/uiIa0Mr
>>
>> I'd encourage plugins to consider disabling merge by commit as well. To
>> do so, go to the settings page for your github repo and look under the
>> Merge Button section.
>>
>> David
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
___
Pulp-dev mailing
listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev

___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>


-- 

Mike DePaulo

He / Him / His

Service Reliability Engineer, Pulp

Red Hat 

IM: mikedep333

GPG: 51745404

___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Katello/Pulp 3 integration scrum

2020-09-23 Thread David Davis 
September 23, 2020

Pulp

   -

   Pulpcore
   -

  3.7.0 released
  -

  3.6.4 to be released with drf-spectacular fix
  -

  Plugins compatible with 3.7 will also be compatible with 3.8
  -

   Is there a Pulp 3 release and/or date we can target to ensure
   integration is in time?
   -


  https://community.theforeman.org/t/foreman-2-3-schedule-and-planning/20604
  -

  No features needed for Katello 3.18
  -

   RPM
   -

  Large copy operations issue https://pulp.plan.io/issues/7483 is
  solved, will be in 3.7
  -

  3.7.0 is going out today, compatible with pulpcore 3.7.0
  -

   Migration
   -

  Fixing incoming bugs
  -

  Done
  -

 done -ish https://github.com/pulp/pulp-2to3-migration/pull/236
 -

 https://github.com/pulp/pulp-2to3-migration/pull/239
 -

  In progress
  -

 https://pulp.plan.io/issues/7540
 -

   Selinux & FIPS
   -

  Selinux EL7 and EL8 policies are ready for katello testing via rpm
  rebuild of https://github.com/pulp/pulp-selinux
  -

  Pulp_rpm needs FIPS support, even though pulpcore 3.7 supports it
  -

 Next step: pulp team to add that, and then test against a matrix
 of repos with specific checksums disallowed


Katello


   -

   Current issues:
   -

  https://pulp.plan.io/issues/7538
  -

  https://pulp.plan.io/issues/7540  (biggest blocker for user db
  testing)
  -

   Migration memory fixes are working great!
   -

   Pulp 3.6 mini retro
   -

  Possibility for regular pulp demos?
  -

 David - Added this to next pulp team meeting agenda
 -

  Setting up nightly/weekly job of running integration tests with pulp3
  and nightly bindings/builds
  -

 Justin - set up meeting to work on this


David
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] 3.7.0 Release Timeline & Go/No-Go Chat Meeting

2020-09-23 Thread Brian Bouterse 
Through IRC discussion here's what we learned:

* it's generally agreed plugins should not switch their pulpcore version in
a z-stream
* pulpcore 3.7.0 is on pypi so plugins can now use pulpcore>=3.7,<3.9 and
start releasing. Bump your y-versions even if there are no changes (it's
strange I know but ... bullet point one)
* 3.6.3 is broken, and I am now going to release a 3.6.4 and an installer
version 3.6.4 first, see this release tracker issue
https://pulp.plan.io/issues/7557
* We're waiting on pulp_file and pulp_rpm compat releases for 3.7.0 before
the installer is released
* Once the installer and pulpcore bits are available (both 3.7.0 and 3.6.4)
announcements will go to pulp-list




On Tue, Sep 22, 2020 at 7:15 PM Brian Bouterse  wrote:

> 3.7.0 is technically released, but the pulp_file PR is failing due to a
> variety of reasons. I'll continue on it (and the pulp_ansible release PR
> also failing) tomorrow.
>
> I still need to release the installer, and then proceed with the
> announcements.
>
> On Fri, Sep 18, 2020 at 1:13 PM Brian Bouterse 
> wrote:
>
>> We had our final go/no-go check in today, and we determined 3.7.0 is
>> on-track for the Sept 22nd release date.
>>
>> You can see the milestone's work items here:
>> https://tinyurl.com/y6rqlufb
>>
>> * Everything except 7460 is expected to merge, or at least be in POST, by
>> EOB today
>> * 7460 is a very small piece of work that a meeting on Monday will
>> coordinate
>> * Selinux EL7 and EL8 policies (not in work query since it doesn't block
>> the pulpcore release due to not being in pulpcore's bits) is also done!
>>
>> Thanks to everyone who put in so much hard work to get this release ready.
>>
>>
>> On Tue, Sep 15, 2020 at 12:51 PM Brian Bouterse 
>> wrote:
>>
>>> At the go/no-go check in today, we determined the 3.7.0 is on-track for
>>> the Sept 22nd release date.
>>>
>>> The next check-in meeting on #pulp-meeting is set up for Friday Sept
>>> 18th, 12pm - 12:30pm EDT. https://everytimezone.com/?t=5f63f880,3c0
>>>
>>> ## Notes
>>>
>>> * All remaining pulpcore and pulpcore installer items to be included are
>>> now tagged in the 3.7.0 milestone:  https://pulp.plan.io/versions/126
>>> * You can see a query-based of the milestone sorted by status here:
>>> https://tinyurl.com/y6rqlufb
>>> * We believe all items at ASSIGNED will be merged at our current pace by
>>> Friday
>>> * The 4 items at NEW are all now marked HIGH prio
>>> * All code must be merged by the end of business on the 21st. The 22nd
>>> is just release day
>>> * The SELinux deliverables (EL7 and EL8 policies) are required for 3.7.0
>>> but are not included on this milestone because they are shipped separately
>>> from pulpcore and therefore do not need to block its release
>>> * No significant pulp_file items were discussed
>>>
>>> ## The four items at NEW
>>>
>>> 7471 - The biggest risk. The installer team will be discussing this
>>> today and through the end of the week
>>> 7460 - A small item. A meeting on monday was already set up to finalize
>>> it's merge. This will likely merge on the 21st
>>> 7413 - To be done on docs day this Thursday the 17th
>>> 7411 - Technically not blocking the release and will be removed if not
>>> merged by end of business on the 21st. It is still high prio though, for
>>> anyone who is on the CI mini-team and can work on it
>>>
>>> Thanks to everyone who participated in our release check in today!
>>>
>>>
>>> On Fri, Sep 4, 2020 at 3:20 PM Brian Bouterse 
>>> wrote:
>>>
 Per the new process, here's the tracker (with checklist) for 3.7.0's
 release: https://pulp.plan.io/issues/7463  Right now, the GA date is
 slated for Sept 22nd.

 The first go/no-go meeting will happen in #pulp-meeting at the time
 below:

 Tuesday Sept 15th, 12pm - 12:30pm EDT.
 https://everytimezone.com/s/68f4535a

 Thanks,
 Brian


___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Disabling merge by commit

2020-09-23 Thread Justin Sherrill 


On 9/23/20 7:18 AM, David Davis wrote:
I think the two main things for me are (1) it makes git history more 
linear and (2) it cuts down on the number of commits. Both of these 
make git history more readable.


The 'rebase and merge' option provides a nice balance of letting you 
provide multiple commits and maintain commit history while not creating 
a merge commit and  making a hard to read commit history.  Sometimes it 
is more expressive to have two (or three) commits that make up one pr to 
make it into the source tree.





David


On Wed, Sep 23, 2020 at 6:48 AM Ina Panova > wrote:


Hi Quirin,



Regards,

Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."


On Wed, Sep 23, 2020 at 10:47 AM Quirin Pamp mailto:p...@atix.de>> wrote:

"I'd encourage plugins to consider disabling merge by commit
as well."

In order to evaluate this it would be great, if you could
explain why this was decided for pulpcore and pulp_file.
You have posted a lot of general information about the
different merge  type (the "What?"), but not so much on the
"Why?".

As far as I can tell the main advantage of squish and rebase,
is that it leads to a more tidy history in master, at the cost
of losing some information on how the sausage was made.
As a result squish and rebase becomes increasingly
advantageous with increasing PR volume.
However, I fail to see an advantage for pulp_deb, which does
not have a large PR volume.

Or am I missing some relevant part of the argument?


I think your understanding is correct. In my perspective it is
important to have a tidy history in master no matter how high/low
PR traffic you have.

pulp_container has disabled merge by commit as well.


Quirin

*From:* pulp-dev-boun...@redhat.com

mailto:pulp-dev-boun...@redhat.com>> on behalf of David Davis
mailto:davidda...@redhat.com>>
*Sent:* 22 September 2020 17:16
*To:* Pulp-dev mailto:pulp-dev@redhat.com>>
*Subject:* Re: [Pulp-dev] Disabling merge by commit
Here's some more information about PR merges as well:


https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges

David


On Tue, Sep 22, 2020 at 11:11 AM David Davis
mailto:davidda...@redhat.com>> wrote:

Today at open floor, we decided to disable merging by
commit for pulpcore and pulp_file PRs. Instead, developers
will rebase or squash PRs to merge them. This adds the
changes to HEAD instead of interspersing commits and
creating a merge commit. This picture of git history
comparing pulpcore to foreman (which doesn't merge by
commit) illustrates the differences:

https://imgur.com/a/uiIa0Mr

I'd encourage plugins to consider disabling merge by
commit as well. To do so, go to the settings page for your
github repo and look under the Merge Button section.

David

___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev


___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Disabling merge by commit

2020-09-23 Thread David Davis 
I think the two main things for me are (1) it makes git history more linear
and (2) it cuts down on the number of commits. Both of these make git
history more readable.

David


On Wed, Sep 23, 2020 at 6:48 AM Ina Panova  wrote:

> Hi Quirin,
>
>
> 
> Regards,
>
> Ina Panova
> Senior Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
>
> On Wed, Sep 23, 2020 at 10:47 AM Quirin Pamp  wrote:
>
>> "I'd encourage plugins to consider disabling merge by commit as well."
>>
>> In order to evaluate this it would be great, if you could explain why
>> this was decided for pulpcore and pulp_file.
>> You have posted a lot of general information about the different merge
>> type (the "What?"), but not so much on the "Why?".
>>
>> As far as I can tell the main advantage of squish and rebase, is that it
>> leads to a more tidy history in master, at the cost of losing some
>> information on how the sausage was made.
>> As a result squish and rebase becomes increasingly advantageous with
>> increasing PR volume.
>> However, I fail to see an advantage for pulp_deb, which does not have a
>> large PR volume.
>>
>> Or am I missing some relevant part of the argument?
>>
>
> I think your understanding is correct. In my perspective it is important
> to have a tidy history in master no matter how high/low PR traffic you have.
>
> pulp_container has disabled merge by commit as well.
>
>>
>> Quirin
>> --
>> *From:* pulp-dev-boun...@redhat.com  on
>> behalf of David Davis 
>> *Sent:* 22 September 2020 17:16
>> *To:* Pulp-dev 
>> *Subject:* Re: [Pulp-dev] Disabling merge by commit
>>
>> Here's some more information about PR merges as well:
>>
>>
>> https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges
>>
>> David
>>
>>
>> On Tue, Sep 22, 2020 at 11:11 AM David Davis 
>> wrote:
>>
>> Today at open floor, we decided to disable merging by commit for pulpcore
>> and pulp_file PRs. Instead, developers will rebase or squash PRs to merge
>> them. This adds the changes to HEAD instead of interspersing commits and
>> creating a merge commit. This picture of git history comparing pulpcore to
>> foreman (which doesn't merge by commit) illustrates the differences:
>>
>> https://imgur.com/a/uiIa0Mr
>>
>> I'd encourage plugins to consider disabling merge by commit as well. To
>> do so, go to the settings page for your github repo and look under the
>> Merge Button section.
>>
>> David
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Disabling merge by commit

2020-09-23 Thread Ina Panova 
Hi Quirin,



Regards,

Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."


On Wed, Sep 23, 2020 at 10:47 AM Quirin Pamp  wrote:

> "I'd encourage plugins to consider disabling merge by commit as well."
>
> In order to evaluate this it would be great, if you could explain why this
> was decided for pulpcore and pulp_file.
> You have posted a lot of general information about the different merge
> type (the "What?"), but not so much on the "Why?".
>
> As far as I can tell the main advantage of squish and rebase, is that it
> leads to a more tidy history in master, at the cost of losing some
> information on how the sausage was made.
> As a result squish and rebase becomes increasingly advantageous with
> increasing PR volume.
> However, I fail to see an advantage for pulp_deb, which does not have a
> large PR volume.
>
> Or am I missing some relevant part of the argument?
>

I think your understanding is correct. In my perspective it is important to
have a tidy history in master no matter how high/low PR traffic you have.

pulp_container has disabled merge by commit as well.

>
> Quirin
> --
> *From:* pulp-dev-boun...@redhat.com  on
> behalf of David Davis 
> *Sent:* 22 September 2020 17:16
> *To:* Pulp-dev 
> *Subject:* Re: [Pulp-dev] Disabling merge by commit
>
> Here's some more information about PR merges as well:
>
>
> https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges
>
> David
>
>
> On Tue, Sep 22, 2020 at 11:11 AM David Davis 
> wrote:
>
> Today at open floor, we decided to disable merging by commit for pulpcore
> and pulp_file PRs. Instead, developers will rebase or squash PRs to merge
> them. This adds the changes to HEAD instead of interspersing commits and
> creating a merge commit. This picture of git history comparing pulpcore to
> foreman (which doesn't merge by commit) illustrates the differences:
>
> https://imgur.com/a/uiIa0Mr
>
> I'd encourage plugins to consider disabling merge by commit as well. To do
> so, go to the settings page for your github repo and look under the Merge
> Button section.
>
> David
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Disabling merge by commit

2020-09-23 Thread Quirin Pamp 
"I'd encourage plugins to consider disabling merge by commit as well."

In order to evaluate this it would be great, if you could explain why this was 
decided for pulpcore and pulp_file.
You have posted a lot of general information about the different merge  type 
(the "What?"), but not so much on the "Why?".

As far as I can tell the main advantage of squish and rebase, is that it leads 
to a more tidy history in master, at the cost of losing some information on how 
the sausage was made.
As a result squish and rebase becomes increasingly advantageous with increasing 
PR volume.
However, I fail to see an advantage for pulp_deb, which does not have a large 
PR volume.

Or am I missing some relevant part of the argument?

Quirin

From: pulp-dev-boun...@redhat.com  on behalf of 
David Davis 
Sent: 22 September 2020 17:16
To: Pulp-dev 
Subject: Re: [Pulp-dev] Disabling merge by commit

Here's some more information about PR merges as well:

https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges

David


On Tue, Sep 22, 2020 at 11:11 AM David Davis 
mailto:davidda...@redhat.com>> wrote:
Today at open floor, we decided to disable merging by commit for pulpcore and 
pulp_file PRs. Instead, developers will rebase or squash PRs to merge them. 
This adds the changes to HEAD instead of interspersing commits and creating a 
merge commit. This picture of git history comparing pulpcore to foreman (which 
doesn't merge by commit) illustrates the differences:

https://imgur.com/a/uiIa0Mr

I'd encourage plugins to consider disabling merge by commit as well. To do so, 
go to the settings page for your github repo and look under the Merge Button 
section.

David
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev