[Pulp-dev] Repo versions with no changes

[Fabricio Aguiar]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20191105/ebdde719/attachment.htm>