[Pulp-dev] Repo versions with no changes

[David Davis]

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