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
