Re: [Pulp-dev] Disabling merge by commit

[David Davis]

I agree that merging by squash is potentially unsafe. I'll disable it for
pulpcore and pulp_file unless anyone objects.

David


On Thu, Sep 24, 2020 at 11:56 AM Brian Bouterse  wrote:

> I'm in favor of only the rebase & merge option everywhere. Our commit
> association machinery relies on commits not being modified, so I don't
> think the "squash and rebase" is a safe option for us. I am glad we are no
> longer using merge commits also.
>
> On Thu, Sep 24, 2020 at 11:39 AM Tatiana Tereshchenko 
> wrote:
>
>> pulp_rpm left only rebase & merge option.
>>
>> On Wed, Sep 23, 2020 at 7:46 PM Mike DePaulo 
>> wrote:
>>
>>> 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
>>>

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Also available here: https://hackmd.io/@pulp/rpm_meeting

General:


   - github merge options
  - leave only rebase option

Pulp 3:

   -

   https://pulp.plan.io/issues/7537
   - Would like to get into the pulp_rpm 3.8 if possible
 - +1
 - depending on the effort it might push back RBAC work
  -

   https://pulp.plan.io/issues/6926
   - does it depend on the changes which are needed in pulpcore?
 - can be worked on independently
  -

   https://pulp.plan.io/issues/7431
   - treat dist tree/comps as other content?
 -  yes

Pulp 2:

   - when reviewing Pulp 2 PRs, make sure to remove “Needs cherry-pick”
   label

Open PRs:

   - https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:

   - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] CLI team meeting notes

[Brian Bouterse]

On Wed, Sep 23, 2020 at 3:31 PM Robin Chan  wrote:

>
> 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.
>
I agree simplicity is key. Here are some questions/thoughts I have to try
to determine what simple looks like

One question I have is: will plugins have custom commands. I suspect the
answer is yes because even if the CLI package itself is smart enough to
auto-produce all the generic commands from the API spec, I suspect in most
cases plugins will want "custom commands".

So if that's a yes, how will they ship those? While it's simple to add them
to the one CLI repo, it's complicated for users to get the "right" version
for them when it's all in one package. In fact that may be impossible. So
not as simple, but likely more usable would be for any custom CLI commands
to ship as a "CLI plugin package" aka a python package that will give extra
commands and have this auto-release when the plugin itself releases. What
wouldn't be simple is an additional repo for each plugin that would require
additional complexity at each plugin release.

The final question I wonder about is testing: How will CI be done on these
commands? My take is probably simplistic, but CI it anywhere plugin bits
are released from so if that's one main repo for the CLI CI those parts
there, and then CI any custom commands from repos where they are released
from.

This is what I was thinking about, but I am ok with anything the CLI teams
would be better or simpler.


>
>> * 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
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] python-nectar 1.6.2 needed

[Ina Panova]

Evgeni,

Today Lai confirmed that he successfully synced the problematic repos with
the new builds.
So please feel free to proceed and push those to stable repos.

Thank you.

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 Tue, Sep 22, 2020 at 12:38 PM Ina Panova  wrote:

> Apparently the test does not check for the task status or wait until task
> finishes/fails
> https://github.com/pulp/Pulp-2-Tests/blob/master/pulp_2_tests/tests/puppet/api_v2/test_sync_publish.py#L232
> It takes some time for the task to fail, when it is in the running state
> `traceback` and `error` are Null, however once it fails I do see both of
> the keys https://pastebin.com/tE9NzPe6
> That's being said the issue is not related to the changes in nectar.
>
>
> 
> 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 Mon, Sep 21, 2020 at 5:30 PM Dennis Kliban  wrote:
>
>> The Jenkins job[0] that tested the 2.21 staging repo showed that all the
>> Docker related tests pass. However, there was a Puppet test that failed.
>> The failure was related to puppet plugin syncing from a bad URL. The test
>> has an assertion that an exception will be present in the Task status and
>> that exception is not there.
>>
>> Ina, could this be related to the Nectar changes?
>>
>> I am going to re-run this job now.
>>
>> [0]
>> https://pulp-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/pulp-2.21-dev-rhel7/15/
>>
>> On Mon, Sep 21, 2020 at 8:58 AM Lai Tran  wrote:
>>
>>> Hey Ina,
>>>
>>> I'm still working on it.  There was some db issues I've encountered with
>>> some machines and not others.  I'll let you know once I'm done testing.
>>>
>>> Lai
>>>
>>> On Mon, Sep 21, 2020 at 6:41 AM Ina Panova  wrote:
>>>
 Hi,
 Still waiting on the test results.

 I will keep you posted. Thanks!

 
 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 Mon, Sep 21, 2020 at 8:46 AM Evgeni Golov  wrote:

> Moin,
>
> is there a verdict about the builds?
>
> Evgeni
>
> On Thu, Sep 17, 2020 at 2:43 PM Evgeni Golov 
> wrote:
> >
> > and packaging is in https://github.com/pulp/pulp-packaging/pull/114
> >
> > the result is now available in the 2.21 stage repo, including the
> > fresh nectar from earlier this week.
> >
> > I kicked off
> https://pulp-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/pulp-2.21-dev-rhel7/
> > and
> https://pulp-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/pulp-2.21-dev-rhel7-fips/
> ,
> > enjoy!
> >
> > On Thu, Sep 17, 2020 at 1:02 PM Evgeni Golov 
> wrote:
> > >
> > > Yes I will ;-)
> > >
> > > pick PR for 3.2-release is up at
> https://github.com/pulp/pulp_docker/pull/462
> > >
> > > On Wed, Sep 16, 2020 at 4:56 PM Ina Panova 
> wrote:
> > > >
> > > > Hi Evgeni,
> > > > today it has been identified that pulp_docker also needs a
> release due to this related commit
> https://github.com/pulp/pulp_docker/commit/859ae5589b7bd5152814f001f4566d4a270cd3e8
> > > > Will you be able to work on the pulp_docker z stream
> release(3.2.7)?
> > > >
> > > > Thank you.
> > > > 
> > > > 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 Tue, Sep 15, 2020 at 4:50 PM Ina Panova 
> wrote:
> > > >>
> > > >> Hey,
> > > >> we should do some testing first.
> > > >> Please keep the build for now in stage, once it is confirmed
> that the patches fix the original issue we can push to stable.
> > > >>
> > > >> Thank you!
> > > >> 
> > > >> 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 Tue, Sep 15, 2020 at 8:19 AM Evgeni Golov 
> wrote:
> > > >>>
> > > >>> I've released nectar 1.6.2 RPMs to
> > > >>>
> https://repos.fedorapeople.org/repos/pulp/pulp/testing/automation/2-master/stage/
> > > >>> Do you want to do any testing, or should I push the same RPMs
> directly
> > > >>> to the stable 2.21 repo too (or first to staging 2.21)?
> > > >>>
> > > >>> On Mon, Sep 14, 2020 at 12:18 PM Evgeni Golov <
> evg...@redhat.com> wrote:
> > > >>> >
> 

Re: [Pulp-dev] Disabling merge by commit

[Brian Bouterse]

I'm in favor of only the rebase & merge option everywhere. Our commit
association machinery relies on commits not being modified, so I don't
think the "squash and rebase" is a safe option for us. I am glad we are no
longer using merge commits also.

On Thu, Sep 24, 2020 at 11:39 AM Tatiana Tereshchenko 
wrote:

> pulp_rpm left only rebase & merge option.
>
> On Wed, Sep 23, 2020 at 7:46 PM Mike DePaulo 
> wrote:
>
>> 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
>>
> 

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

[Brian Bouterse]

The 3.7.0 installer is released to galaxy.ansible.com, so I'll proceed with
the pulpcore, pulp_file, and pulp_ansible announcements to pulp-list now.
Once sent, that can unblock other plugin announcements.


On Thu, Sep 24, 2020 at 7:39 AM Tatiana Tereshchenko 
wrote:

> pulp_rpm==3.7.0 is published but not announced.
>
> On Wed, Sep 23, 2020 at 11:11 PM Brian Bouterse 
> wrote:
>
>> 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:

Re: [Pulp-dev] Disabling merge by commit

[Tatiana Tereshchenko]

pulp_rpm left only rebase & merge option.

On Wed, Sep 23, 2020 at 7:46 PM Mike DePaulo  wrote:

> 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 mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] sphinx theme for docs.pulpproject.org

[Dennis Kliban]

Looks like dynaconf is no longer using Sphinx for the docs. Unfortunately
that is not an option for us at this time.

On Thu, Sep 24, 2020 at 8:57 AM Fabricio Aguiar 
wrote:

> I like the new dynaconf theme: https://www.dynaconf.com/
>
> Best regards,
> Fabricio Aguiar
> Software Engineer, Pulp Project
> Red Hat Brazil - Latam 
> +55 11 999652368
>
>
> On Thu, Sep 24, 2020 at 9:48 AM Dennis Kliban  wrote:
>
>> We are slowly rolling out plugin docs to docs.pulpproject.org. At this
>> time pulp_file and pulp_ansible are the only plugins publishing their docs
>> there. What I noticed is that they have completely different themes. We
>> need to pick a single theme to be used by all plugins. Does anyone have
>> suggestions for which theme that should be?
>>
>> https://docs.pulpproject.org/pulp_ansible/
>> https://docs.pulpproject.org/pulp_file/
>> ___
>> 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] sphinx theme for docs.pulpproject.org

[Melanie Corr]

Ar Déar 24 MFómh 2020 ag 15:03, scríobh Dennis Kliban :

>
> On Thu, Sep 24, 2020 at 8:59 AM Melanie Corr  wrote:
>
>> Hi Dennis,
>>
>> This reminds me that Pulp got feedback related to the difference in style
>> between the main website and the docs from the OSPO audit last year:
>>
>> "● Create consistent styles between main and docs domain"
>>
>> Would this be hard to achieve?
>>
>
> We would need to find a Jekyll theme (pulpproject.org) that is paired
> with a Sphinx theme (docs.pulpproject.org). This would most likely
> require us creating something custom for both. Seems like a big effort.
>
>

I don't think that the result would justify the effort.
Thanks, Dennis.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] sphinx theme for docs.pulpproject.org

[Dennis Kliban]

On Thu, Sep 24, 2020 at 9:01 AM Quirin Pamp  wrote:

> I don't have a strong opinion, but I feel like if we don't come up with
> anything better we could just  fall back to what the pulpcore docs are
> currently using.
>
> https://docs.pulpproject.org/pulpcore/
>
> https://github.com/pulp/pulpcore/blob/d31eb22453cd2d56b43ed884ec193fa166cafe62/docs/conf.py#L116
>
>
+1 to making everything consistent with pulpcore.


> quba42
> --
> *From:* pulp-dev-boun...@redhat.com  on
> behalf of Dennis Kliban 
> *Sent:* 24 September 2020 14:47
> *To:* Pulp-dev 
> *Subject:* [Pulp-dev] sphinx theme for docs.pulpproject.org
>
> We are slowly rolling out plugin docs to docs.pulpproject.org. At this
> time pulp_file and pulp_ansible are the only plugins publishing their docs
> there. What I noticed is that they have completely different themes. We
> need to pick a single theme to be used by all plugins. Does anyone have
> suggestions for which theme that should be?
>
> https://docs.pulpproject.org/pulp_ansible/
> https://docs.pulpproject.org/pulp_file/
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] sphinx theme for docs.pulpproject.org

[Dennis Kliban]

On Thu, Sep 24, 2020 at 8:59 AM Melanie Corr  wrote:

> Hi Dennis,
>
> This reminds me that Pulp got feedback related to the difference in style
> between the main website and the docs from the OSPO audit last year:
>
> "● Create consistent styles between main and docs domain"
>
> Would this be hard to achieve?
>

We would need to find a Jekyll theme (pulpproject.org) that is paired with
a Sphinx theme (docs.pulpproject.org). This would most likely require us
creating something custom for both. Seems like a big effort.


>
> Ar Déar 24 MFómh 2020 ag 13:48, scríobh Dennis Kliban  >:
>
>> We are slowly rolling out plugin docs to docs.pulpproject.org. At this
>> time pulp_file and pulp_ansible are the only plugins publishing their docs
>> there. What I noticed is that they have completely different themes. We
>> need to pick a single theme to be used by all plugins. Does anyone have
>> suggestions for which theme that should be?
>>
>> https://docs.pulpproject.org/pulp_ansible/
>> https://docs.pulpproject.org/pulp_file/
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> --
>
> Melanie Corr, RHCE
>
> Community Manager
>
> Red Hat 
>
> Remote, Ireland
>
> mc...@redhat.com
> M: +353857774436 IM: mcorr
> 
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] sphinx theme for docs.pulpproject.org

[Quirin Pamp]

I don't have a strong opinion, but I feel like if we don't come up with 
anything better we could just  fall back to what the pulpcore docs are 
currently using.

https://docs.pulpproject.org/pulpcore/
https://github.com/pulp/pulpcore/blob/d31eb22453cd2d56b43ed884ec193fa166cafe62/docs/conf.py#L116

quba42

From: pulp-dev-boun...@redhat.com  on behalf of 
Dennis Kliban 
Sent: 24 September 2020 14:47
To: Pulp-dev 
Subject: [Pulp-dev] sphinx theme for docs.pulpproject.org

We are slowly rolling out plugin docs to 
docs.pulpproject.org. At this time pulp_file and 
pulp_ansible are the only plugins publishing their docs there. What I noticed 
is that they have completely different themes. We need to pick a single theme 
to be used by all plugins. Does anyone have suggestions for which theme that 
should be?

https://docs.pulpproject.org/pulp_ansible/
https://docs.pulpproject.org/pulp_file/
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] sphinx theme for docs.pulpproject.org

[Matthias Dellweg]

I like the one used by ansible more, but is desperately lacking a big pulp
logo.
Would it be feasible to have a theme that looks like
https://pulpproject.org/ ?

On Thu, Sep 24, 2020 at 2:48 PM Dennis Kliban  wrote:

> We are slowly rolling out plugin docs to docs.pulpproject.org. At this
> time pulp_file and pulp_ansible are the only plugins publishing their docs
> there. What I noticed is that they have completely different themes. We
> need to pick a single theme to be used by all plugins. Does anyone have
> suggestions for which theme that should be?
>
> https://docs.pulpproject.org/pulp_ansible/
> https://docs.pulpproject.org/pulp_file/
> ___
> 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] sphinx theme for docs.pulpproject.org

[Fabricio Aguiar]

I like the new dynaconf theme: https://www.dynaconf.com/

Best regards,
Fabricio Aguiar
Software Engineer, Pulp Project
Red Hat Brazil - Latam 
+55 11 999652368


On Thu, Sep 24, 2020 at 9:48 AM Dennis Kliban  wrote:

> We are slowly rolling out plugin docs to docs.pulpproject.org. At this
> time pulp_file and pulp_ansible are the only plugins publishing their docs
> there. What I noticed is that they have completely different themes. We
> need to pick a single theme to be used by all plugins. Does anyone have
> suggestions for which theme that should be?
>
> https://docs.pulpproject.org/pulp_ansible/
> https://docs.pulpproject.org/pulp_file/
> ___
> 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] sphinx theme for docs.pulpproject.org

[Dennis Kliban]

We are slowly rolling out plugin docs to docs.pulpproject.org. At this time
pulp_file and pulp_ansible are the only plugins publishing their docs
there. What I noticed is that they have completely different themes. We
need to pick a single theme to be used by all plugins. Does anyone have
suggestions for which theme that should be?

https://docs.pulpproject.org/pulp_ansible/
https://docs.pulpproject.org/pulp_file/
___
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

[Tatiana Tereshchenko]

pulp_rpm==3.7.0 is published but not announced.

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

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