[Pulp-dev] Repo versions with no changes

[Ina Panova]

+1 to create a repo version only when there is content set change.


--------
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, Nov 6, 2019 at 3:42 PM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

> +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
>>
> _______________________________________________
> 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/0f4e8eef/attachment.htm>