[Pulp-dev] [Meeting Minutes] Sprint 88 Planning

[Robin Chan]

8-Jan-2021

New Sprint 88 query: https://pulp.plan.io/issues?query_id=124

New Agile board: https://pup.plan.io/agile/board?query_id=151


Stats on how we did in previous in between sprints Sprint 88 Query


 New - 21

 Assigned - 18

 Post - 9

 Modified - 7

Closed - CURRENTRELEASE -

Closed - WORKSFORME -

Closed - NOTABUG -

Closed - DUPLICATE -

Closed - WONTFIX -

Closed - COMPLETE -


Action Items:

   -

   - rchan: send out planning minutes
   - Rchan update agile board for sprint & Move new, assigned, post issues
   to new sprint (not needed)
   - Rchan: Publish https://pulp.plan.io/projects/pulp/wiki/Sprint_Plans
   - Update 3 month planning current quarter line item status


Stakeholder Delivery Dates:

   -

   Katello
   
:
   Keeping short term deadlines and started discussing
   -

  3.18 branching:  Nov 2nd, Targeting Pulp 3.7
  -

  4.0 branching ~February 2021 (dry-run needed by end-of-Dec)
  -

  4.1 branching ~May 2021
  -

 Potentially last compatibility release with the migration plugin
 -

  4.2 branching ~August 2021
  -

  4.3 Branching ~Nov 2021
  -

   Ansible
   -

  Feature freeze end of January
  -

   tagging feature 3.10 or 3.11 at latest



Non-redmine tasks:

   -

   working on talk recordings


Dates & Content:

https://pulp.plan.io/projects/pulp/wiki/Sprint_Plans

Sprint candidates:

https://pulp.plan.io/issues?query_id=26

  * moved out - Orphan cleanup running along-side other tasks (?)(medium)

* https://pulp.plan.io/issues/7659

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

Re: [Pulp-dev] Backports and LTS

[David Davis]

There are some great features that have been added to Github Actions--one
of them being manual triggers for workflows (before we weren't sure how we
could trigger the entire release process). So I think we're in a good
position now that we're on Github Actions to automate the rest of the
release process.

The problem is finding the time. I think we're all spread thin and we're
talking about a week or two...? I would love to see this happen though as I
think it would pay for itself after a couple releases.

David


On Tue, Jan 12, 2021 at 3:48 PM Brian Bouterse  wrote:

> Stakeholder's won't agree on a single "LTS" (agreed daniel that's not a
> great name for it) so I think option 3 is a non-starter. Option 2 is what
> we do today and I agree it has the issues already mentioned.
>
> So +1 to option 1, but as already mentioned, practically speaking, I
> believe we can't release any more than we are without fully automating the
> process. Can we fully automate the release process first, and then
> re-discuss a policy change after?
>
>
>
> On Wed, Jan 6, 2021 at 12:12 PM Daniel Alley  wrote:
>
>> Matt, that is a good observation and meanwhile with pulp2 we had such a
>>> policy, we cannot adopt it with pulp3. Release fast and release often is
>>> something we are trying to stick to.
>>>
>>
>> I don't think Matt was suggesting in any way that we not release fast and
>> often, it's just that we have to pick a combination of cadance and # of
>> supported releases that works for everyone.  This is basically Option 1
>> with a pre-determined number of supported releases (rather than "backport
>> to whatever version the stakeholder is using + all the others in between"
>> which is how I interpret Option 1).
>>
>> I totally agree with David that it would be a pain to manage without
>> automation though, same as Option 1.
>>
>> I think what would most likely happen under that plan is that we would
>> see each stakeholder will take a release, stick to it until it is about to
>> be dropped and then upgrade to the newest one, which is roughly the same as
>> the LTS plan except that each stakeholder can choose their own "LTS"
>> version and they could do an mid-cycle upgrade if there was ever a good
>> reason to.
>>
>> Whatever option we choose, I'm kind of negative about actually using the
>> term "LTS" given that I don't think we'd be supporting any version for more
>> than 5-7 months.  The timeframe is a bit short for how the LTS moniker is
>> typically used.
>>
>> On Wed, Jan 6, 2021 at 8:58 AM Ina Panova  wrote:
>>
>>> Matt, that is a good observation and meanwhile with pulp2 we had such a
>>> policy, we cannot adopt it with pulp3. Release fast and release often is
>>> something we are trying to stick to.
>>>
>>> It would be best to agree on the LTS version that would make all the
>>> stakeholders happy but as it was pointed out not sure how we'd make this
>>> possible, everyone has a different pace and release cycle.
>>> Having that said, we should probably stick to option1 which puts more
>>> burden on us but in return users and stakeholders are happy and the
>>> project's upgrade path is stable.
>>> One thing we could possibly do about the backport requests is to really
>>> be thorough about which ones to accept by assessing the impact of the
>>> stakeholder who has created the request and their possibility to upgrade if
>>> any.
>>> 
>>> 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, Jan 6, 2021 at 2:18 PM Matt Pusateri 
>>> wrote:
>>>
 Another option is Current Version minus X (N-1, N-2, etc.) If for
 instance you say we support N-1, and current version is 3.9, then you'll
 back port to latest 3.8.x.  N-2 at current version 3.9, would backport to
 3.8.x, 3.7.x, etc.  The advantages here are that you already set the
 expectation for everyone, you limit the versions you support, you force
 people to stay current to get fixes.  The downside is that people have to
 upgrade and or it could impact downstream schedules.  The impact with going
 this route is affected by the release velocity.  So if you're rapidly
 releasing major versions, then it's more likely people won't keep up, or
 that they'll have to upgrade and are not able to for some reason.

 Matt P.


 On Wed, Jan 6, 2021 at 6:05 AM Matthias Dellweg 
 wrote:

> Thanks for putting all the options together.
> I would say that option 2 is a recipe for very bad user experience,
> and i'd vote strongly against it.
> I am ok with option 1, but I would add that the backport to the
> intermediate minor releases _must_ be performed (as in released) counting
> down, to always meet that upgrade expectation. Remember releasing can be
> delayed unexpectedly due to reasons.
> If we go for option 3, I think it's 

Re: [Pulp-dev] Backports and LTS

[Brian Bouterse]

Stakeholder's won't agree on a single "LTS" (agreed daniel that's not a
great name for it) so I think option 3 is a non-starter. Option 2 is what
we do today and I agree it has the issues already mentioned.

So +1 to option 1, but as already mentioned, practically speaking, I
believe we can't release any more than we are without fully automating the
process. Can we fully automate the release process first, and then
re-discuss a policy change after?



On Wed, Jan 6, 2021 at 12:12 PM Daniel Alley  wrote:

> Matt, that is a good observation and meanwhile with pulp2 we had such a
>> policy, we cannot adopt it with pulp3. Release fast and release often is
>> something we are trying to stick to.
>>
>
> I don't think Matt was suggesting in any way that we not release fast and
> often, it's just that we have to pick a combination of cadance and # of
> supported releases that works for everyone.  This is basically Option 1
> with a pre-determined number of supported releases (rather than "backport
> to whatever version the stakeholder is using + all the others in between"
> which is how I interpret Option 1).
>
> I totally agree with David that it would be a pain to manage without
> automation though, same as Option 1.
>
> I think what would most likely happen under that plan is that we would see
> each stakeholder will take a release, stick to it until it is about to be
> dropped and then upgrade to the newest one, which is roughly the same as
> the LTS plan except that each stakeholder can choose their own "LTS"
> version and they could do an mid-cycle upgrade if there was ever a good
> reason to.
>
> Whatever option we choose, I'm kind of negative about actually using the
> term "LTS" given that I don't think we'd be supporting any version for more
> than 5-7 months.  The timeframe is a bit short for how the LTS moniker is
> typically used.
>
> On Wed, Jan 6, 2021 at 8:58 AM Ina Panova  wrote:
>
>> Matt, that is a good observation and meanwhile with pulp2 we had such a
>> policy, we cannot adopt it with pulp3. Release fast and release often is
>> something we are trying to stick to.
>>
>> It would be best to agree on the LTS version that would make all the
>> stakeholders happy but as it was pointed out not sure how we'd make this
>> possible, everyone has a different pace and release cycle.
>> Having that said, we should probably stick to option1 which puts more
>> burden on us but in return users and stakeholders are happy and the
>> project's upgrade path is stable.
>> One thing we could possibly do about the backport requests is to really
>> be thorough about which ones to accept by assessing the impact of the
>> stakeholder who has created the request and their possibility to upgrade if
>> any.
>> 
>> 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, Jan 6, 2021 at 2:18 PM Matt Pusateri  wrote:
>>
>>> Another option is Current Version minus X (N-1, N-2, etc.) If for
>>> instance you say we support N-1, and current version is 3.9, then you'll
>>> back port to latest 3.8.x.  N-2 at current version 3.9, would backport to
>>> 3.8.x, 3.7.x, etc.  The advantages here are that you already set the
>>> expectation for everyone, you limit the versions you support, you force
>>> people to stay current to get fixes.  The downside is that people have to
>>> upgrade and or it could impact downstream schedules.  The impact with going
>>> this route is affected by the release velocity.  So if you're rapidly
>>> releasing major versions, then it's more likely people won't keep up, or
>>> that they'll have to upgrade and are not able to for some reason.
>>>
>>> Matt P.
>>>
>>>
>>> On Wed, Jan 6, 2021 at 6:05 AM Matthias Dellweg 
>>> wrote:
>>>
 Thanks for putting all the options together.
 I would say that option 2 is a recipe for very bad user experience, and
 i'd vote strongly against it.
 I am ok with option 1, but I would add that the backport to the
 intermediate minor releases _must_ be performed (as in released) counting
 down, to always meet that upgrade expectation. Remember releasing can be
 delayed unexpectedly due to reasons.
 If we go for option 3, I think it's advisable to try to sync up
 stakeholders, because we don't want to maintain consecutive minor versions
 as LTS, and again, backporting a fix must traverse all maintained LTS in
 backward order. We should add expectations to how long we can keep an LTS
 version alive, and how often we bless one.

 On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko 
 wrote:

> With more and further away backport requests coming in, there is more
> need for a clear policy/docs to set expectations for users and to define
> requirements for those performing a backport.
>
> The question which hasn't been answered yet (in documented way) is:
>

[Pulp-dev] Pulpcore team meeting

[David Davis]

# January 12, 2021

## Previous action items
* [dkliban] to close out pulp_file 1.5.0
* Done
* [ttereshc] start discussion about LTS versions of pulp
* https://www.redhat.com/archives/pulp-dev/2021-January/msg3.html
* Done

## Topics
* Download and verify - https://pulp.plan.io/issues/7683
* Needs to be implemented in pulpcore
* bmbouter to ask for deadline
* Deadline for https://pulp.plan.io/issues/7659?
* Would like to fix by march/april
* write api for users
* All agreed to proceed - AI open a story
* Restrict default permissions to admin users
* https://github.com/pulp/pulpcore/pull/1064

## Action Items
* [bmbouter] to ask find out if/when this is needed
https://pulp.plan.io/issues/7683
* [ipanova] open story to add write api for users
* [daviddavis] schedule fips check in meeting

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