+1 to option C
-------- 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 Tue, Jul 2, 2019 at 4:42 PM Tatiana Tereshchenko <ttere...@redhat.com> wrote: > I agree, it's fine to do nothing until the state of the redmine issue is > critical for Pulp 3 release process. > > On Tue, Jul 2, 2019 at 3:47 PM David Davis <davidda...@redhat.com> wrote: > >> I think doing nothing for now makes sense. ON_QA doesn't seem to fit the >> state of the issues and users can use the changelog for now. >> >> David >> >> >> On Mon, Jul 1, 2019 at 12:38 PM Brian Bouterse <bbout...@redhat.com> >> wrote: >> >>> After some more IRC discussion here's another option. >>> >>> c) do nothing and if users want to know what is in the RC, look in the >>> changelog. If users want to know what is in source, look in the CHANGES >>> directory in master (which contains uncut changelog entries). The creation >>> of the changelog deletes the CHANGES directory's files. >>> >>> On Mon, Jul 1, 2019 at 10:46 AM Brian Bouterse <bbout...@redhat.com> >>> wrote: >>> >>>> After some off-list discussion, it sounds like we want a new state, and >>>> that new state shouldn't be called ON_QA. Would people rather: >>>> >>>> a) introduce a new state now? What would it be called? >>>> b) use CLOSED - CURRENT RELEASE for now, and revisit the state addition >>>> as we get closer to GA? >>>> >>>> >>>> On Thu, Jun 27, 2019 at 10:26 AM Brian Bouterse <bbout...@redhat.com> >>>> wrote: >>>> >>>>> Fixing this would improve our process, so I want to do something. I >>>>> get stuck on the name ON_QA though. The Pulp3 release process is so >>>>> different from the Pulp2 one, the label doesn't make as much sense to me >>>>> for Pulp3. Is marking them as CLOSED - CURRENT RELEASE an option? Or maybe >>>>> introducing a new label called PRE-RELEASE? For now we could use CURRENT >>>>> RELEASE as a simple option until we get into the GA. >>>>> >>>>> What do you think? >>>>> >>>>> On Thu, Jun 27, 2019 at 9:32 AM David Davis <davidda...@redhat.com> >>>>> wrote: >>>>> >>>>>> I noticed in redmine that it's impossible to track which issues have >>>>>> been released in an RC vs what has been completed but not yet released. >>>>>> In >>>>>> both cases, the status of these issues is MODIFIED. In Pulp 2, we set the >>>>>> status to ON_QA when changes have been released in a beta[0]. I wonder if >>>>>> it would make sense to set Pulp 3 issues to ON_QA once they have been >>>>>> released with an RC? Would it make sense to start this practice with RC3? >>>>>> >>>>>> [0] >>>>>> https://pulp.plan.io/projects/pulp/wiki/Pulp_2_Release_Planning#Beta-Announcing >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On Fri, Jun 21, 2019 at 12:14 PM Brian Bouterse <bbout...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> The RC3 has several items on its blockers list [0], so we will not >>>>>>> be releasing on Monday the 24th. The plan is to release when either the >>>>>>> blockers are all resolved or on Friday the 28th, whichever comes first. >>>>>>> Any >>>>>>> remaining blockers will go onto an RC4 blockers list. >>>>>>> >>>>>>> # Plugin Updates Required >>>>>>> One new issue #4990 [1] discussed today during open floor will >>>>>>> require a small-but-necessary change for any plugin that implements >>>>>>> on-demand policy='streamed' or policy='on_demand'. Specifically you'll >>>>>>> need >>>>>>> to override the 'policy' field on your detail Remote's serializer to >>>>>>> allow >>>>>>> for those values. #4990 will include these docs (likely done Mon/Tues), >>>>>>> but >>>>>>> I wanted to give a heads up. Without this change RC3 will break lazy for >>>>>>> your users because they won't be able to make the Remote. >>>>>>> >>>>>>> Any feedback or ideas are welcome (either on list or off). >>>>>>> >>>>>>> [0]: https://etherpad.net/p/pulpcore_rc3_blocker_list >>>>>>> [1]: https://pulp.plan.io/issues/4990 >>>>>>> >>>>>>> Thanks! >>>>>>> Brian >>>>>>> >>>>>>> On Fri, Jun 14, 2019 at 11:57 AM Brian Bouterse <bbout...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Next Thursday will be 1-month since the pulpcore and >>>>>>>> pulpcore-plugin rc2 releases, so it's time to start coordinating rc3. >>>>>>>> Please give feedback on any aspect here that could be improved. >>>>>>>> Feedback >>>>>>>> and changes are welcome. >>>>>>>> >>>>>>>> # rc3 timeline and blockers >>>>>>>> I'm proposing June 24th as the rc3 release date. If there is some >>>>>>>> issue you want to block pulpcore or pulpcore-plugin's rc3 release >>>>>>>> please >>>>>>>> add the Redmine link onto this blockers etherpad: >>>>>>>> https://etherpad.net/p/pulpcore_rc3_blocker_list >>>>>>>> >>>>>>>> # stable, committed migrations >>>>>>>> Based on feedback with RC3 pulpcore and pulpcore-plugin will start >>>>>>>> committing migrations and not modifying/rebasing them. We are asking >>>>>>>> plugin >>>>>>>> writers to do the same. This will make consuming new release candidates >>>>>>>> easier. It does not mean we are committing that a user could upgrade a >>>>>>>> RC >>>>>>>> system to a GA system. >>>>>>>> >>>>>>>> # release notes >>>>>>>> If you want the rc3 release notes to reflect a piece of work that >>>>>>>> does not have an entry in the CHANGES directory, you can still add >>>>>>>> them. >>>>>>>> Put your entries in the CHANGES directory. This should be true of your >>>>>>>> core >>>>>>>> and also plugins who have adopted the towncrier tooling for release >>>>>>>> notes. >>>>>>>> >>>>>>>> # version in source >>>>>>>> Users are becoming confused in the /status/ API about what bits >>>>>>>> they have with source checkouts. To resolve this pulpcore and >>>>>>>> pulpcore-plugin will contain the nextVersion.dev as its version going >>>>>>>> forward. So today we're applying versions 3.0.0rc3.dev and >>>>>>>> 0.1.0rc3.dev to pulpcore and pulpcore-plugin in source control >>>>>>>> respectively. We are asking plugin writers to also adopt this >>>>>>>> approach. On >>>>>>>> release day we will will drop the .dev, and then increment it to >>>>>>>> 3.0.0rc4.dev, etc. >>>>>>>> >>>>>>>> # releasing rc3 compatible plugins >>>>>>>> I don't believe rc3 has any breaking changes in the plugin API >>>>>>>> requiring significant updates. For your users to use the RC3, you'll >>>>>>>> need >>>>>>>> to ensure your plugin's setup.py will allow that newer version to be >>>>>>>> installer. Please reach out on-list or on IRC if you want any help with >>>>>>>> this. >>>>>>>> >>>>>>>> # exclusively importing from pulpcore.plugin >>>>>>>> Please update your plugins to import from pulpcore.plugin >>>>>>>> exclusively. Any import that imports from another package underneath >>>>>>>> pulpcore is not part of the plugin API. For example imports 'from >>>>>>>> pulpcore.app.models import X' should become 'from >>>>>>>> pulpcore.plugin.models >>>>>>>> import X'. this is important to ensure we've got all the necessary >>>>>>>> objects >>>>>>>> plugins use available via the plugin API. >>>>>>>> >>>>>>>> # When is GA? >>>>>>>> There are issues being discovered by Katello as they integrate >>>>>>>> against Pulp3. These usability issues also affect general Pulp users. >>>>>>>> It's >>>>>>>> nothing epic, but the changes do produce small backwards incompatible >>>>>>>> changes. We'll have more confidence once there are no open Katello >>>>>>>> integration blockers. You can see that list here: >>>>>>>> https://tinyurl.com/y395d4gn >>>>>>>> >>>>>>>> Also the migration tooling plan is coming along very nicely, but >>>>>>>> going to GA requires that work to have progressed further also (I >>>>>>>> feel). >>>>>>>> GA-ing Pulp3 and then realizing we can't migrate pulp2 content >>>>>>>> effectively >>>>>>>> into it would be good to avoid. >>>>>>>> >>>>>>>> Finally, the RPM plugin, the mainstay of Pulp2's usage, has a few >>>>>>>> significant features to develop which could produce some >>>>>>>> not-insignificant >>>>>>>> changes in core. One GA perspective is to wait on rpm to make those >>>>>>>> feature >>>>>>>> and for katello to integrate those too to have full confidence Pulp3 is >>>>>>>> ready for Katello. FWIW, those efforts are underway already. >>>>>>>> >>>>>>>> # Feedback >>>>>>>> Please send it any way you feel comfortable. If you feel we're not >>>>>>>> doing something right please tell us! >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Brian >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> Pulp-dev@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
