[Pulp-dev] Repo versions with no changes

Tatiana Tereshchenko ttereshc at redhat.com
Wed Nov 6 14:42:01 UTC 2019


+1 to not create empty repo versions for now

On Tue, Nov 5, 2019 at 2:34 PM Fabricio Aguiar <fabricio.aguiar at redhat.com>
wrote:

> Sounds good to me.
>
> Best regards,
> Fabricio Aguiar
> Software Engineer, Pulp Project
> Red Hat Brazil - Latam <https://www.redhat.com/>
> +55 11 999652368
>
>
> On Tue, Nov 5, 2019 at 1:38 PM David Davis <daviddavis at redhat.com> wrote:
>
>> That sounds good to me. What if for the GA, we just not create a new
>> version if content hasn't changed and then create an issue for post-GA to
>> add a setting to always create a new version?
>>
>> David
>>
>>
>> On Tue, Nov 5, 2019 at 3:28 AM Fabricio Aguiar <
>> fabricio.aguiar at redhat.com> wrote:
>>
>>> how about making a default setting and document, adverting why the
>>> default is (bump/not bump the version).
>>> This way we give autonomy to users to decide whether to bump or not the
>>> version
>>>
>>> Best regards,
>>> Fabricio Aguiar
>>> Software Engineer, Pulp Project
>>> Red Hat Brazil - Latam <https://www.redhat.com/>
>>> +55 11 999652368
>>>
>>>
>>> On Mon, Nov 4, 2019 at 10:52 PM Mike DePaulo <mikedep333 at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Nov 4, 2019 at 4:50 PM Mike DePaulo <mikedep333 at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 4, 2019 at 4:39 PM Brian Bouterse <bmbouter at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> tl;dr I'm +1 to making this switch.
>>>>>>
>>>>>> On Mon, Nov 4, 2019 at 3:51 PM David Davis <daviddavis at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Currently in pulp, syncs always create repository versions
>>>>>>> regardless of whether or not any content changed. One of the tasks[0] for
>>>>>>> 3.0 GA is to document this behavior. However, I've heard several complaints
>>>>>>> about this from users so I wonder if it's worth reconsidering.
>>>>>>>
>>>>>> I love making users happy, but the complaints didn't resonate as much
>>>>>> with me because another user with a different subjective preferences could
>>>>>> walk up and complain after we switch it. I try to listen for user
>>>>>> complaints that come with objective claims of usability.
>>>>>>
>>>>>>
>>>>>>> Here are some reasons against always creating repo versions:
>>>>>>> - They were meant to serve as a historical record but this
>>>>>>> information is available by looking at the tasks api
>>>>>>> - It creates additional, unnecessary versions and bumps the latest
>>>>>>> version number of the repo
>>>>>>> - If we ever have a feature to retain only the latest X repo
>>>>>>> versions, it'll be less useful since some repo versions may not have any
>>>>>>> changes
>>>>>>>
>>>>>> This last bullet I see an objective reason to make no-content-change
>>>>>> repo versions not increment. Users concerned about their cron jobs not
>>>>>> running can check the task records. Users get RepositoryVersions that
>>>>>> always include change and are therefore more meaningful (perhaps that was
>>>>>> Bin Li's objective claim). Also future users could get a repo-version
>>>>>> retention option which would be difficult to create if we don't switch this.
>>>>>>
>>>>>
>>>>> From a black-box perspective, how about some sort of compromise
>>>>> solution? Like a minor version number being bumped if there is a no-change
>>>>> sync. Or a separate field like "1st identical repo version."
>>>>>
>>>>
>>>> Whether we implement a compromise or not, this current proposal should
>>>> be implemented 1st.
>>>>
>>>> +1
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> Any thoughts? I'd like to get this on the sprint by Wednesday so it
>>>>>>> can be changed before the dev freeze date of Nov 12.
>>>>>>>
>>>>>> +1 to making this change
>>>>>>
>>>>>>>
>>>>>>> [0] https://pulp.plan.io/issues/3308
>>>>>>>
>>>>>>> David
>>>>>>> _______________________________________________
>>>>>>> Pulp-dev mailing list
>>>>>>> Pulp-dev at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Pulp-dev mailing list
>>>>>> Pulp-dev at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Mike DePaulo
>>>>>
>>>>> He / Him / His
>>>>>
>>>>> Service Reliability Engineer, Pulp
>>>>>
>>>>> Red Hat <https://www.redhat.com/>
>>>>>
>>>>> IM: mikedep333
>>>>>
>>>>> GPG: 51745404
>>>>> <https://www.redhat.com/>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Mike DePaulo
>>>>
>>>> He / Him / His
>>>>
>>>> Service Reliability Engineer, Pulp
>>>>
>>>> Red Hat <https://www.redhat.com/>
>>>>
>>>> IM: mikedep333
>>>>
>>>> GPG: 51745404
>>>> <https://www.redhat.com/>
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20191106/6425ebed/attachment.htm>


More information about the Pulp-dev mailing list