+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 <[email protected]> wrote: > +1 to not create empty repo versions for now > > On Tue, Nov 5, 2019 at 2:34 PM Fabricio Aguiar <[email protected]> > 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 <[email protected]> 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 < >>> [email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Nov 4, 2019 at 4:50 PM Mike DePaulo <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 4, 2019 at 4:39 PM Brian Bouterse <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> tl;dr I'm +1 to making this switch. >>>>>>> >>>>>>> On Mon, Nov 4, 2019 at 3:51 PM David Davis <[email protected]> >>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> [email protected] >>>>>>> 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 >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
