<div dir="ltr"><div><div>tl;dr @daviddavis and I will try to handle the announcing of the builds and document a process to have others help do in the future.<br></div><div><br></div><div>In some conversations with the folks who make the Pulp2 builds, they want to focus only on building and transition the announcing of builds back to developers. I think overall it will improve the quality by having devs a bit more involved in the release/prep and announcement. The responsibilities we would be accepting fall into a few areas.<br></div><div><br></div><div># announcement content. This needs to be created all of this content pre-build so that when the build completes a Pulp dev can publish it<br></div><span class="m_-7437881771935810331gmail-author-p-80551">* Blog Post<br>*</span><span class="m_-7437881771935810331gmail-author-p-80551"> Email Announcement</span><span class="m_-7437881771935810331gmail-author-p-80551"></span><br>*<span class="m_-7437881771935810331gmail-author-p-80551"> Docs builder updates<br></span></div><span class="m_-7437881771935810331gmail-author-p-80551">* Updates to <a href="http://pulpproject.org/docs" target="_blank">pulpproject.org/docs</a> page<br></span><div><span class="m_-7437881771935810331gmail-author-p-80551">*</span><span class="m_-7437881771935810331gmail-author-p-80551"> Tweeting</span><span class="m_-7437881771935810331gmail-author-p-80551"></span></div><div><br></div><div># just before the build</div><div>* Look over the release notes</div><div>* Ensure that for a z release, there are no features included by reading redmine</div><div>* Ensure that for y releases, each feature has a release note<br></div><div><br></div><div># redmine automation<br></div><div>@daviddavis and I would be setting the "Platform Target Release" field so that the build machinery can assemble the build from that field and its associated commits. Developers would continue to leave it unset, which is the same process as we have today. We can mostly automate these things and we should because its a lot of manual work otherwise.<br></div><div><br></div><div><span class="m_-7437881771935810331gmail-author-p-80551">This script would run frequently (like hourly), which should keep things always up to date. Also it would verify that each issue has an associated commit because the build machinery will fail if there are fewer commits. I'll write up this work in Redmine and work to get it groomed.</span></div><div><span class="m_-7437881771935810331gmail-author-p-80551"><br></span></div><div><span class="m_-7437881771935810331gmail-author-p-80551">@daviddavis and I are going to handle this for both 2.15.2 and 2.16 and drive our schedule from the dates on the release wiki pages:  <a href="https://pulp.plan.io/projects/pulp/wiki/Release_Schedule" target="_blank">https://pulp.plan.io/projects/<wbr>pulp/wiki/Release_Schedule</a><br></span></div><div><span class="m_-7437881771935810331gmail-author-p-80551"><br></span></div><div><span class="m_-7437881771935810331gmail-author-p-80551">Any feedback or ideas are welcome. We'll share out links as we document the process.<br></span></div><div><span class="m_-7437881771935810331gmail-author-p-80551"><br></span></div><div><span class="m_-7437881771935810331gmail-author-p-80551">-Brian</span></div><div><span class="m_-7437881771935810331gmail-author-p-80551"><br></span></div></div>