<div dir="ltr"><div>I agree, it's fine to do nothing until the state of the redmine issue is critical for Pulp 3 release process.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019 at 3:47 PM David Davis <<a href="mailto:daviddavis@redhat.com">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br clear="all"><div><div dir="ltr" class="gmail-m_311256652703567837m_6701717046095465719gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at 12:38 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>After some more IRC discussion here's another option.</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at 10:46 AM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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:</div><div><br></div><div>a) introduce a new state now? What would it be called?</div><div>b) use CLOSED - CURRENT RELEASE for now, and revisit the state addition as we get closer to GA?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2019 at 10:26 AM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>What do you think?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2019 at 9:32 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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?<div><br></div><div>[0] <a href="https://pulp.plan.io/projects/pulp/wiki/Pulp_2_Release_Planning#Beta-Announcing" target="_blank">https://pulp.plan.io/projects/pulp/wiki/Pulp_2_Release_Planning#Beta-Announcing</a><br clear="all"><div><div dir="ltr" class="gmail-m_311256652703567837gmail-m_6701717046095465719gmail-m_-5237396366434914846gmail-m_3578287443376626755gmail-m_7245270591440482753gmail-m_-1510174893597146487gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019 at 12:14 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div># Plugin Updates Required</div><div>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.<br></div><div><br></div><div>Any feedback or ideas are welcome (either on list or off).</div><div><br></div><div>[0]: <a href="https://etherpad.net/p/pulpcore_rc3_blocker_list" target="_blank">https://etherpad.net/p/pulpcore_rc3_blocker_list</a></div><div>[1]: <a href="https://pulp.plan.io/issues/4990" target="_blank">https://pulp.plan.io/issues/4990</a></div><div><br></div><div>Thanks!</div><div>Brian<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 14, 2019 at 11:57 AM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div># rc3 timeline and blockers<br></div><div>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: <a href="https://etherpad.net/p/pulpcore_rc3_blocker_list" target="_blank">https://etherpad.net/p/pulpcore_rc3_blocker_list</a></div><div><br></div><div># stable, committed migrations</div><div>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.</div><div><br></div><div># release notes</div><div>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.</div><div><br></div><div># version in source</div><div>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 <a href="http://3.0.0rc3.dev" target="_blank">3.0.0rc3.dev</a> and <a href="http://0.1.0rc3.dev" target="_blank">0.1.0rc3.dev</a> 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 <a href="http://3.0.0rc4.dev" target="_blank">3.0.0rc4.dev</a>, etc.<br></div><div><br></div><div># releasing rc3 compatible plugins</div><div>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.</div><div><br></div><div># exclusively importing from pulpcore.plugin</div><div>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.<br></div><div><br></div><div># When is GA?</div><div>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:  <a href="https://tinyurl.com/y395d4gn" target="_blank">https://tinyurl.com/y395d4gn</a></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div># Feedback</div><div>Please send it any way you feel comfortable. If you feel we're not doing something right please tell us!<br></div><div><br></div><div>Thank you,</div><div>Brian<br></div><div><br> </div></div>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>