re: going through open tickets - you can use the BK suggested algorithm and
monthly query for from some criteria (say last touched) and review & close
with the same message. We a pick a target by which we wish to close all of
the older Pulp 2 issues that won't be addressed and pick a criteria to
I was involved in the Satellite 5 to Satellite 6 bug triage. We brought
known issues foreward, and after a few months the language and usage was
so different that we ended up buk closing.
So, I could see moving over feature requests if they may sense, but if
the RFE is unique to pulp2 or if it is
I do like the idea to evaluate Pulp 2 issues and create tickets for Pulp 3
- mainly to avoid some known problems.
Perhaps, we could create a new label on pulp.plan.io to distinguish those
ones when migrated to Pulp 3. And file as a related issue to the previous
Pulp 2 one.
On Thu, Apr 4, 2019 at
At first I was thinking we could keep stories open and just close bugs and
tasks. However, I skimmed through open Pulp 2 stories and it seems a lot
(or most) aren't even applicable to Pulp 3.
It's easy enough for a user to re-open (or open) an issue if they feel like
it needs to be addressed in
Byan,
What you are saying makes a lot of sense to me. The architectural
differences between Pulp 2 and Pulp 3 are so great that most bugs don't
translate well from one to the other. I would prefer if we just mass close
Pulp 2 issues.
On Thu, Apr 4, 2019 at 9:27 AM Bryan Kearney wrote:
> I was
Hi Austin,
Thank you for pulling this all together and sharing it out.
2 thoughts:
1. What is the difference btween ln 34 & 127 of the [0] etherpad? Looks
like a repeat to me.
2. I'd like to hear more about this idea of not being able to distinguish
if a feature is documented in pulpcore or a
I think its possible you will have a url collision with variant 1. (We had
a similar problem trying to use /v3/publications/docker/)
variant 1: POST /pulp/v3/api/content/rpm/packages/copy/
content_units=[...] source="..." destination="..." [more params...]
Assuming that
General:
- ppicka joined RPM mini-team
- welcome :)
Pulp 2:
- dkliban to plan release of 2.19.1 soon to release the migration issue
https://pulp.plan.io/issues/4617 and other bugfixes which will be
completed in time for the release
- https://pulp.plan.io/issues/4631 Pulp
The latest pulpcore REST API documentation can be found here[0]. Similar
documentation + more is available with every install of pulpcore and the
plugins[1].
[0] https://docs.pulpproject.org/en/3.0/nightly/restapi.html
[1] https://pulpproject.org/pulp-3-plugins/
On Thu, Mar 28, 2019 at 2:04 PM
Hi Austin,
Thanks for working on this.
The division of the docs (between pulpcore and each plugin) requires prior
> knowledge and is not well communicated. Based on the consistency, the
> developers have a shared understanding of which features should be
> documented in pulpcore, and which
Content copy between repositories is critically important to Katello
integration and is something that we have not really addressed yet. It
also needs to be completed before the RPM plugin can begin work on
depsolving. The story that results from this discussion should probably be
put on one of
11 matches
Mail list logo
