Re: [Pulp-dev] 2.15.3 dev freeze -- 22:00 UTC Tuesday, March 6th
Per the release schedule, the code for 2.15.3 is now frozen. There are a total of 8 issues spread across core, rpm, and docker. This is ready for release engineering. The current beta date for 2.15.3 is March 13th. https://pulp.plan.io/issues?query_id=59 @milan, these two issues [0][1] are shown as stories so they are not included in 2.15.3. They should be included in 2.16 though since they are already merged. Will that work? [0]: https://pulp.plan.io/issues/3353 [1]: https://pulp.plan.io/issues/3339 Thanks, Brian On Mon, Mar 5, 2018 at 11:18 AM, Brian Bouterse wrote: > Any Pulp2 core or plugin code that you want included in the 2.15.3 release > must be: > > a) merged to master by 22:00 UTC, March 6th > b) be associated with a bugfix issue. stories, refactors, and tasks are > not included in z-stream releases. > > If you want/need to adjust this date, please reply reply on-list. > > Thanks! > Brian > On Mon, Mar 5, 2018 at 11:18 AM, Brian Bouterse wrote: > Any Pulp2 core or plugin code that you want included in the 2.15.3 release > must be: > > a) merged to master by 22:00 UTC, March 6th > b) be associated with a bugfix issue. stories, refactors, and tasks are > not included in z-stream releases. > > If you want/need to adjust this date, please reply reply on-list. > > Thanks! > Brian > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
Thanks for all the feedback! With many +1s and no -1s, I'm going to make this change tomorrow. I'll send out links to the result when it is done. -Brian On Mon, Mar 5, 2018 at 12:43 PM, Jeff Ortel wrote: > +1 > > > On 03/02/2018 04:17 PM, Brian Bouterse wrote: > > Redmine's milestone feature allows for roadmap pages to be published for > each project on pulp.plan.io like this one [0]. Currently all projects > use a single set of milestones from the main 'Pulp' project on Redmine > which is what defines the Sprints, e.g. 'Sprint 22'. This creates a few > problems: > > 1. Redmine projects can't use the milestone feature of Redmine for release > planning. This is unfortunate since the milestone feature is a good release > planning and roadmapping tool. > > 2. Any project that does use milestones can't have issues associated with > milestones also on a sprint. Like pulp_rpm pulp3 issues [0]. > > I'm interested in hearing any solution on resolving these issues, but I > also have one to share: > > 1. We could create a custom field called 'Sprint' and make that available > to all projects. > 2. Populate the custom field with all existing Sprint values > 3. We then port the existing historic sprint issues to the correct custom > field which preserves all past sprints. > 4. Clear the milestone for all isues on plan.io > 5. Delete the old, unused milestones > 6. enjoy > > At least one issue at the upcoming sprint planning meeting won't be able > to be added because of this so I'm hoping we can resolve in the next few > days. > > [0]: https://pulp.plan.io/versions/50 > > Thanks! > Brian > > > ___ > Pulp-dev mailing > listPulp-dev@redhat.comhttps://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
Re: [Pulp-dev] scrum status
Whoops, wrong list On Tue, Mar 6, 2018 at 4:51 PM, Bihan Zhang wrote: > 3/6/18 > - tracked down an answer to https://forums.suse.com/sho > wthread.php?11748-What-happens-when-suse-erratum-is-updated& > p=51367#post51367 > - SUSE does update errata in place, but they increment version > attribute in the erratum > - will work on this tomorrow, after @ttereshc checks in with rcm to > make sure this is ok for rh errata > - Container source scrum > - amended #3377 PR [0] > - continue reading through container source design documents > > 3/5/18 > - Team meeting > - Docker meeting > - Python meeting > - #3377 > - read through some details for RCM project- it's not pulp related \o/ > mostly python scripting to make source code in container images available > > [0] https://github.com/pulp/pulp_rpm/pull/1088 > > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] scrum status
3/6/18 - tracked down an answer to https://forums.suse.com/sho wthread.php?11748-What-happens-when-suse-erratum-is-updated& p=51367#post51367 - SUSE does update errata in place, but they increment version attribute in the erratum - will work on this tomorrow, after @ttereshc checks in with rcm to make sure this is ok for rh errata - Container source scrum - amended #3377 PR [0] - continue reading through container source design documents 3/5/18 - Team meeting - Docker meeting - Python meeting - #3377 - read through some details for RCM project- it's not pulp related \o/ mostly python scripting to make source code in container images available [0] https://github.com/pulp/pulp_rpm/pull/1088 ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Pulp3 Ansible Installer Temporarily Removal and Unification
There has been discussion on how to unify the 3-4 different Ansible installers. I want to recap the current thinking and planned changes that have come out of those discussions. The following 3 pieces of work are being proposed, in hopes of being groomed by another core member barring any -1s. Delete the ansible installation section from the Pulp3 docs ( https://pulp.plan.io/issues/3437) Strip down the dev environment to match a vanilla install ( https://pulp.plan.io/issues/3438) Update Jenkins Jobs to not use Ansible Installer ( https://pulp.plan.io/issues/3439) ^ will remove Pulp's existing usages of the Ansible installer to free it up to be unified and then brought back sometime after core is in beta. @PieterLexis has contributed to this role ( https://github.com/pulp/ansible-pulp3/pull/6) which likely will be the best role/playbook to adopt to do both source and pypi installs while the others would be deleted. I hope these three issues can be groomed and all added to this sprint. Any feedback, questions, ideas are welcome either here or on the issue. Thanks! Brian ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Plugin triage
It makes sense to let to mini-teams to triage the issues, but the decision whether to put or not on the sprint still should be addressed by whole team, or at least acknowledged. Regards, Ina Panova 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, Mar 6, 2018 at 3:29 AM, Daniel Alley wrote: > I'm fine with this. I dislike the idea of multiple meetings but I think > that what will end up happening is that the issue load for each project > individually will be low enough that they will can and will all end up > being handled asynchronously as they come in. I also think that letting > each plugin decide what is best for them. > > But just to throw this out there, there are a few other things we could do > to help address the problem. > > We could modify the triage bot to group the issues by type instead of > listing them chronologically by number. All core issues would be handled > first, followed by the plugin with the largest number of issues, followed > by the plugin with the next largest, etc. The triage bot could know the > composition of the plugin teams and ping the relevant members when a group > of issues that concerns them comes up. > > Pros: > > - No concerns about lack of cross-pollination, everything is still > completely transparent > - Community members could still be involved and/or observe the > process, which they can't do if every plugin meeting is separate and done > in email or IRC > > Cons: > > - If you're involved in triaging issues a couple minutes apart, what can > you _really_ do in that time? > - Multiple interruptions, not *necessarily* gaining much efficiency > - Triage lead still would still have to be involved the entire time, > whereas ideally someone directly involved with that plugin would be in > control > - Triage would still take a long time, and would hold up #pulp-dev for > that duration > > > On Mon, Mar 5, 2018 at 6:05 PM, Brian Bouterse > wrote: > >> Currently the biweekly triage query includes a large number of unrelated >> topics: Pulp, RPM, Puppet, Python, Ansible (the pulp3 role plugin), >> Packaging, OS Tree, Crane, Docker, External, and File Support. These are >> all different top-level pulp.plan.io projects in Redmine. These are so >> many specializations I think it makes sense to have issues triaged by just >> the people who focus on them. Also once per week may or may not be the >> right frequency for all of these things which could bring people into >> meetings they may not contribute to or benefit from. +1 to having plugin >> teams triage issues how they want. >> >> For Ansible for example, @daviddavis and I can just talk about issues as >> they come it. I have it set to email me when they are filed, so we don't >> need a meeting at all. >> >> What about a gradual transition? If/when plugin/project committers decide >> to do it differently, then can email pulp-dev asking to be removed and >> someone can update the query. >> >> What do you think? >> >> >> On Tue, Feb 27, 2018 at 11:47 AM, David Davis >> wrote: >> >>> At our last retrospective, we discussed the possibility of not triaging >>> plugin issues as part of our biweekly triage sessions. We didn’t reach an >>> agreement so I took the action item to start a discussion on pulp-dev. >>> >>> First off some benefits of not triaging plugin issues as part of our >>> triage sessions: >>> >>> - If we let plugin teams triage their own issues, they can select a time >>> when the whole team is able to meet. Our biweekly meeting tends to only >>> involve a subsets of plugin teams. >>> - Time is wasted when plugin issues come up and usually just the plugin >>> team members discuss it. >>> - We don’t have a consistent policy around which plugin issues we >>> triage. For instance, we don’t triage pulp_deb. >>> >>> There are some downsides however: >>> >>> - I think the biggest issue is that there’ll be less transparency into >>> plugins. This could lead to more siloing and less cross-pollination. >>> - Potentially more meetings if all plugins decide to schedule their own >>> triage meetings. >>> - Plugin issues could go untriaged if plugin teams aren’t responsible. >>> >>> A couple solutions to the problem that were proposed: >>> >>> - Ask plugin teams schedule their own triage meetings. They could >>> probably do this on a less regular basis. >>> - Have plugin teams triage their issues how they want. This could even >>> be asynchronously as issues come in. Could be done via IRC/email/etc. >>> >>> I think at the least it might be worth trying out an alternative >>> approach for a limited time (e.g. 2 months) and then reevaluating. Thoughts? >>> >>> David >>> >>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> ___ >> Pulp-dev mailing list
