Re: [Pulp-dev] Merging forward commits

+1 On Mon, Feb 6, 2017 at 12:09 PM, Ina Panova wrote: > Seems like we are trying to choose/figure out what's more important - > linear commit history which is readable or confidence and ability to track > where exactly change had been applied? > > I agree with Mike and think that merging forward

Re: [Pulp-dev] "Internal" periodic tasks in Pulp3?

I concur with everything Brian has said here. Our reliance on hacking the internals of the Celery scheduler means that we are susceptible to breakages when they change those internals [0] which we must work around [1]. It would be best to stick with public, stable interfaces. [0] https://pulp.pl

Re: [Pulp-dev] PyPI names for Pulp3

___ >>> 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 >> >> > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > -- Daniel Alley Associate Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig> ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PyPI names for Pulp3

I would prefer pulp3 over pulpproj, nice idea Bihan! On Wed, Apr 12, 2017 at 1:47 AM, Dennis Kliban wrote: > I like using the pulp3 namespace. > > On Tue, Apr 11, 2017 at 9:13 AM, Bihan Zhang wrote: > >> What about pulp3 as a potential namespace? With this naming we can >> communicate that this

Re: [Pulp-dev] PyPI names for Pulp3

I'm not a fan of plp, it does look too much like pip IMO On Wed, Apr 12, 2017 at 3:32 PM, Austin Macdonald wrote: > Another alternative: plp > > Pros: > - super short! > - pinky typing exercise > > Cons: > - Fonts are silly: plp (PLP) looks like pIp (PIP) > - sounds "web 2.0" > > > On Wed, A

Re: [Pulp-dev] Proposal to use google style docstrings (PUP-2)

+1 from me as well On Mon, Apr 17, 2017 at 1:20 PM, Brian Bouterse wrote: > +1 to accepting this proposal. > > I left my final round of very small language nitpicks. > > On Wed, Apr 12, 2017 at 2:31 PM, Austin Macdonald > wrote: > >> Thanks to everyone for thoughtful comments and suggestions. S

Re: [Pulp-dev] PyPI names for Pulp3

+1 pulpapp +0 pulpproj On Thu, Apr 20, 2017 at 7:05 AM, Ina Panova wrote: > we have not considered yet 'pulpapp' > > pip install pulpapp > pip install pulpapp_cli > pip install pulpapp_streamer > > > > > Regards, > > Ina Panova > Software Engineer| Pulp| Red Hat Inc. > > "Do not go wher

Re: [Pulp-dev] PyPI names for Pulp3

+1 pulpapp +0 pulpproj On Thu, May 4, 2017 at 4:54 PM, Brian Bouterse wrote: > +1 pulpproj > -0 pulpproject > -0 pulp_platform > -1 plp > -1 pulp3 > > Also I'm +1 to having the top level namespace (the name above) contain the > subnamespaces i.e. 'platform', 'common', 'streamer', and 'cli'. So t

Re: [Pulp-dev] python namespace proposal

+1 On Fri, May 12, 2017 at 12:13 PM, Jeff Ortel wrote: > +1, This sounds good to me. > > On 05/11/2017 10:59 AM, Michael Hrivnak wrote: > > We had a brainstorm session today to re-evaluate the > previously-identified options, and try to come up with > > some new ones. None of the previously-iden

Re: [Pulp-dev] Terms: unassociate vs. disassociate

+1 Add/remove is definitely more clear. Associate/disassociate feels like more of an engineering terminology. On Wed, May 24, 2017 at 6:06 AM, Ina Panova wrote: > +1 for add/remove. An aside note, i want to make sure we stick to 'remove' > specifically' and not 'delete'. > I wanted to bring th

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

+1 On Wed, May 24, 2017 at 4:00 PM, David Davis wrote: > I’d like to kick off the voting on PUP-3 which is the proposal to change > our git workflow by using cherry-picks instead of merging changes forward. > The proposal can be viewed here: > > https://github.com/daviddavis/pups/blob/pup3/pup-0

Re: [Pulp-dev] PUP Process: "obvious consensus"

We could use the metric that a PUP passes if there are no -1s and more than 1/3 of the team considers it an improvement (+0 or +1). If more than 2/3rds the team is voting -0, it probably needs more discussion. On Mon, Jun 12, 2017 at 11:49 AM, Bryan Kearney wrote: > I liked what Brian said, p

Re: [Pulp-dev] PUP Process: "obvious consensus"

I _strongly_ disagree with the idea of a black or white +1 / -1 system, I think it would be much more likely to encourage groupthink. Not everyone will be able to reach a clear, strong opinion about every topic, particularly people less familiar or experienced with the subject area under debate.

Re: [Pulp-dev] Type hinting in Pulp 3

For what it's worth, Pycharm does support PEP 484 type hinting. https://www.jetbrains.com/help/pycharm/type-hinting-in-pycharm.html https://blog.jetbrains.com/pycharm/2015/11/python-3-5-type-hinting-in-pycharm-5/ There are also projects like MyPy which behave like static analyzers. It is theoret

Re: [Pulp-dev] Flake8 in Pulp 3

+1 On Thu, Jul 6, 2017 at 2:16 PM, Dennis Kliban wrote: > +1 https://pulp.plan.io/issues/2870 > > On Mon, Jul 3, 2017 at 2:08 PM, David Davis wrote: > >> +1 from me. >> >> At the very least, we could try it out for a while and see how it goes. >> >> >> David >> >> On Mon, Jul 3, 2017 at 1:05 P

Re: [Pulp-dev] PUP Process: "obvious consensus"

+1 On Thu, Aug 10, 2017 at 3:04 PM, Dennis Kliban wrote: > +1 > > On Thu, Aug 10, 2017 at 9:21 AM, David Davis > wrote: > >> +1. I think this is worth trying out. >> >> >> David >> >> On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald >> wrote: >> >>> +1 >>> >>> Thank you Brian! >>> >>> On Thu,

Re: [Pulp-dev] Reconsidering PUP-3

+1 On Mon, Oct 2, 2017 at 7:37 AM, Michael Hrivnak wrote: > +1 > > On Fri, Sep 29, 2017 at 10:08 AM, Brian Bouterse > wrote: > >> +1 >> >> I believe the cherry picking approach will avoid merge-forward problems >> we've experienced, allow for less friction during community contribution, >> and

Re: [Pulp-dev] Triage lead role is open

I am willing to take on the triage lead position beginning this Friday, and asmacdo has said that he will help with the transition. - Daniel On Tue, Oct 3, 2017 at 5:42 PM, Tatiana Tereshchenko wrote: > Hi everyone, > > I'm rotating off of the triage lead, and I'm looking for someone else to >

Re: [Pulp-dev] 'Pulp 3 installer' tag added to pulp.plan.io

+1, the ansible roles are large enough that having their own tracker makes a lot of sense. On Tue, Oct 17, 2017 at 3:17 PM, Dennis Kliban wrote: > We should tag all these as 'Pulp 3 installer'. If you have some issues in > mind, please add that tag. > > On Tue, Oct 17, 2017 at 3:02 PM, Austin Ma

[Pulp-dev] [pulp_python] Roadmap and wishlist for future versions of the Pulp Python plugin

Pulp 3 development is in full swing, and we've begun thinking about what we may want out of future versions of the Python plugin. We would love your input, too! We've created a wiki page on pulp.plan.io detailing our initial thoughts on what the Pulp Python plugin should look like, and how the wo

Re: [Pulp-dev] [pulp_python] Roadmap and wishlist for future versions of the Pulp Python plugin

ses > presented. Since this document is meant to be shared with Pulp users and > most of our users are probably not subscribed to pulp-dev list, we should > probably send out this email to the pulp-list also. What do you think? > > -Dennis > > On Mon, Oct 23, 2017 at 5:11 PM, Daniel A

Re: [Pulp-dev] Let's use immutable resource URIs for all resources in pulp 3

+1 On Thu, Nov 9, 2017 at 3:27 PM, Jeff Ortel wrote: > +1 > > On 11/09/2017 02:01 PM, Dennis Kliban wrote: > > Pulp 3 currently uses a resource's 'name' attribute to form a URI for > that resource. However, the name is > > usually mutable and as a result can cause some clients to have > referenc

Re: [Pulp-dev] Proposing dropping old fedora releases for 2.15

+1 On Mon, Nov 20, 2017 at 9:24 AM, Ina Panova wrote: > +1 > > > > > 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, Nov 14, 2017 at 4:18 PM, Michael Hrivnak > w

Re: [Pulp-dev] Infrastructure tracker on pulp.plan.io

Would this new tracker be the proper home for issues regarding Jenkins, Travis, nodepool, etc? And, if so, should we move those issues out of whichever trackers they exist in currently (many in "Pulp Packaging" [0], a few in "Pulp" [1] [2] [3], etc.) [0] https://pulp.plan.io/projects/packaging/is

Re: [Pulp-dev] Pulp Code of Conduct PUP discussion

+1 to option F On Wed, Nov 29, 2017 at 4:47 PM, Brian Bouterse wrote: > +1 to option F. It starts a CONTRIBUTING.md and also shows off the CoC on > the website. We can easily make a CoC page on the website and link to that. > > For the email, we probably need to make a private mailing list like

Re: [Pulp-dev] Proposal and feedback request: un-nest urls

+0 to un-nesting On Thu, Nov 30, 2017 at 11:19 AM, Bihan Zhang wrote: > After chatting with @asmacdo I am now +0 on this. > I've been convinced that treating importers, publishers, and content as > separate resources is a reasonable approach. > > On Thu, Nov 30, 2017 at 10:40 AM, Jeff Ortel wro

Re: [Pulp-dev] [Pulp 3 REST API] Breaking URL structure changes

+1, good work Austin! We should make sure the documentation for pulp_file, pulp_example, and pulp_python (3.0-dev) is changed to match. https://github.com/pulp/pulp_file/blob/master/README.rst#add-an-importer-to-repository-foo https://github.com/pulp/pulp_example/blob/master/README.rst#add-an-imp

Re: [Pulp-dev] Voting for PUP 4: Code of Conduct

+1 On Tue, Dec 12, 2017 at 12:25 PM, Dennis Kliban wrote: > We had some discussion about this PUP in a separate thread[0]. We have now > reached consensus on the wording of the PUP to open it up to voting. > > To refresh everyone’s memory, voting is outlined in PUP-1: > > https://github.com/pulp

Re: [Pulp-dev] Deferring 3 things for Pulp3 to 3.1+

+1 here too On Wed, Dec 13, 2017 at 8:28 AM, David Davis wrote: > I think this makes sense. +1 from me. > > > David > > On Tue, Dec 12, 2017 at 11:47 AM, Brian Bouterse > wrote: > >> As we get to the end of the MVP planning for Pulp3, I want to check-in >> about deferring 3 areas of Pulp functi

Re: [Pulp-dev] Pulp 3: using JWT to request a JWT

> > - close issues 3163 and 3164 > - move JWT auth use cases from the MVP document[2] to the 3.1+ > document[3]. > - add a story for removing "djangorestframework-jwt" from pulp 3.0 s/story/task, and - remove the JWT auth documentation from the 3.0 docs +1 On Tue, Dec 12, 2017 at 5:01 PM, D

Re: [Pulp-dev] Feedback Requested: Language Guide PR

+1 to this, thank you Austin! On Thu, Dec 14, 2017 at 11:20 AM, Austin Macdonald wrote: > I've written up a high level overview of Pulp 3 concepts and definitions. > It is my hope that sharpening our language will help us to be internally > consistent in our docs, on the mailing list, and how we

Re: [Pulp-dev] Github keywords

Even if we don't change this, It's something we should keep in mind since our PR #s are currently in a spot where they may frequently overlap with issue #s. At some point they'll diverge again and it won't be so much of an issue, but currently it is. I don't know precisely how the redmine integra

Re: [Pulp-dev] pulp 3 distributor use cases

+1 rename On Fri, Feb 2, 2018 at 10:51 AM, Austin Macdonald wrote: > +1 rename to Exporter. > > On Fri, Feb 2, 2018 at 10:13 AM, Brian Bouterse > wrote: > >> +1 to renaming a Pulp3 'Distributor' to be 'Exporter'. The name of a >> 'Distribution' (when Pulp serves bits using its webserver) would

Re: [Pulp-dev] Github Required Checks

I don't think we should make it a hard *physical* block on PR merging. Setting aside the occasional infrastructure issues, we also have some unit tests (in pulp core, at least) that rely on e.g. non-expired certificates, and fixing those once they break would require circumventing the process or di

Re: [Pulp-dev] Github Required Checks

Jeremy, I don't think David was continuing our line of discussion on policy, but rather rebutting the original idea that Github's "required checks" be enforced for all plugins. That goes back to the whole difference between having a policy that requires green tests and making it physically impossi

Re: [Pulp-dev] Github Required Checks

failures will still happen in all >>> the three options regardless, but at least false negatives won't be ignored. >>> This might also help catching environment issues sooner in the process >>> (such as a third-party library update causing a legitimate failure because >>

Re: [Pulp-dev] pulp 3 PR testing with pulp-smash

Would it be possible to have the required tests be Pulp core only, but to have an expanded set of non-mandatory smash tests which includes pulp_file? Which would mean, the pulp_file smash test results would be there as a visual indicator, but wouldn't cause problems over the next few months before

Re: [Pulp-dev] Migrating Sprint to Custom Field

+1 On Mon, Mar 5, 2018 at 11:51 AM, David Davis wrote: > +1 > > > David > > On Mon, Mar 5, 2018 at 11:44 AM, Dennis Kliban wrote: > >> +1 to this plan >> >> On Mon, Mar 5, 2018 at 11:28 AM, Bihan Zhang wrote: >> >>> +1 I'm a fan of the redmine roadmap features, I tried to use this for >>> pulp

Re: [Pulp-dev] Plugin triage

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 plugi

Re: [Pulp-dev] Github Required Checks

://pulp.plan.io/issues/3379 >>>>> >>>>> I think we should enable these because we have a human-enforced policy >>>>> that expects failed checks to not be merged, but in practice code that is >>>>> merged breaks things that quality checks al

Re: [Pulp-dev] Importer Name

+1 +1 On Fri, Mar 9, 2018 at 3:28 PM, Brian Bouterse wrote: > I left some responses inline. > > On Thu, Mar 8, 2018 at 11:13 AM, Austin Macdonald > wrote: > >> Motivation: >> The name "importer" carries some inaccurate implications. >> 1) Importers should "import". Tasks like "sync" will do the

Re: [Pulp-dev] Plugin triage

18 at 12:30 PM, Ina Panova wrote: >> >>> 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. >>> >>> >>>

Re: [Pulp-dev] let's rename RepositoryVersion to Snapshot

I think of a "snapshot" like a VM snapshot or a Windows restore point - an archival copy of a very fluid and non-discrete system at one point in time. By that understanding, the term RepositoryVersion probably fits better. I acknowledge the other benefits though. -/+0? On Tue, Mar 20, 2018 at 1

Re: [Pulp-dev] Port Pulp3 to use RQ

As Brian said, Celery has a lot of limitations and drawbacks, a lot of code complexity, and an upstream that is not terribly responsive. I, too, would love to see us move away from Celery at some point. But having done a little bit of research over the last few hours since it was mentioned, I hav

Re: [Pulp-dev] Port Pulp3 to use RQ

on of whether that amount of change would be acceptable in the interim period between betas. On Tue, Mar 20, 2018 at 4:39 PM, Daniel Alley wrote: > As Brian said, Celery has a lot of limitations and drawbacks, a lot of > code complexity, and an upstream that is not terribly responsive. I, t

Re: [Pulp-dev] Port Pulp3 to use RQ

that's for sure. >> I am +1 to get rid of celery, but with something that would not have >> other limitations which would bring just different kind of pain. [0] >> Let's keep searching and evaluating alternatives. >> >> [0] https://www.youtube.com/watch?v=Qmh

Re: [Pulp-dev] Port Pulp3 to use RQ

I meant in the sense that, what is the aftermath when it comes back online, and is it screwed up in ways that cause side effects. On Wed, Mar 21, 2018 at 5:02 PM, Jeremy Audet wrote: > > RQ does not support revoking tasks. If you send the worker a SIGINT, it > will finish the task and then stop

Re: [Pulp-dev] Pulp 3 Unit Test Plan Proposal

We would still block on failing tests, yes. I'm also -1 blocking on coverage, and -1 against attempting 100%. I'm also generally -1 against trying to pick a number (100%, 80%, 60%) up-front. We should unit test what makes sense to unit test, push that number as high as reasonable, and otherwise

Re: [Pulp-dev] Plugin relationship to tasks

Nice choice of music :) On Mon, Mar 26, 2018 at 4:14 PM, Milan Kovacik wrote: > On Mon, Mar 26, 2018 at 9:38 PM, Austin Macdonald > wrote: > > > > > > On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban > wrote: > >> > >> This proposal does not make the plugin writer's job any easier. This > >> sim

Re: [Pulp-dev] let's rename RepositoryVersion to Snapshot

of pulp3 atm, you are giving a >> plugin maintainer a hard time, anyway. I think, it's now or never. >> >> Matthias >> >> On Tue, 20 Mar 2018 11:55:14 -0400 >> David Davis wrote: >> >> > I’m not too worried about the change being too large. Howev

Re: [Pulp-dev] remove AUTHORS

+0 On Wed, Apr 4, 2018 at 9:14 AM, Dana Walker wrote: > I like Austin's point about getting to specify contact info for a specific > project as I have different emails for different types of contributions > myself, but I don't want to have to update things in multiple places down > the road when

Re: [Pulp-dev] Improving technical decision making

> > > My opinion is that we have stalled and punted several very important > issues when lazy consensus was too lazy. This has slowed our progress > enough that I am interested in fleshing out alternatives. > +1 On Wed, Apr 4, 2018 at 11:14 AM, Austin Macdonald wrote: > > > On Wed, Apr 4, 2018

Re: [Pulp-dev] Changesets Challenges

+1 On Sat, Apr 7, 2018 at 8:13 AM, David Davis wrote: > +1 > > > David > > On Fri, Apr 6, 2018 at 10:39 AM, Dennis Kliban wrote: > >> On Fri, Apr 6, 2018 at 10:15 AM, Brian Bouterse >> wrote: >> >>> Several plugins have started using the Changesets including >>> pulp_ansible, pulp_python, pulp

Re: [Pulp-dev] Various MVP micro-discussions

> > Throughout the MVP there are many references to lazy sync. They have been > changed to red, but IMO we should just remove them. > Are the items we're removing from the MVP being moved to the 3.1+ planning document on the wiki? We don't want to lose track of any of these items. This applies al

Re: [Pulp-dev] Pulp 3 release quality

bmbouter is fixing the docs link in a PR: https://github.com/pulp/pulp/ pull/3446 My understanding is that the smoke tests are for PRs, but actual releases would still be tested against the full test suite. On Tue, Apr 17, 2018 at 3:25 PM, Preethi Thomas wrote: > > > On Tue, Apr 17, 2018 at 8:3

Re: [Pulp-dev] Tracking GA issues

+1 On Wed, Apr 18, 2018 at 12:11 PM, Dana Walker wrote: > +1 > > I like this idea for tracking purposes so that things do not fall by the > wayside and for organization of future aims. > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat > > >

Re: [Pulp-dev] Pulp 3 Release Process Questions

> > Are those Travis jobs testing combinations of web servers, AMQP brokers, > databases, etc? If not, is testing across those combinations a goal? The travis jobs currently text a matrix of Django version (2.0 and 1.1 LTS), database (sqlite and postgresql), and python version (3.5 and 3.6). Pres

Re: [Pulp-dev] Port Pulp3 to use RQ

le, but we won't really know until we prototype it a bit. Based >>> on the >>> > technical outline in the previous email, I believe it can be >>> prototyped in a >>> > day or two. I plan to do this soon, once I contribute to a few other >>> &

Re: [Pulp-dev] Port Pulp3 to use RQ

gt; > >>>>> > Looking forward for this. >>>>> > >>>>> > Regards, >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > On Wed, M

[Pulp-dev] Content types which are not compatible with the normal pulp workflow

Some content types are not going to be compatible with the normal sync/publish/distribute Pulp workflows, and will need to be live API-only. To what degree should Pulp accomodate these use cases? Example: Pulp makes the assumptions that A) the metadata for a repository can be generated in its en

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

Maybe _created > _id > _last_updated > ? I'm not sure whether we use pk or id more often, but we use both quite a lot. On Wed, May 23, 2018 at 9:22 AM, David Davis wrote: > Correct me if I’m wrong but don’t we call pk in most places instead of id? > If so, it would seem like replacing id with

Re: [Pulp-dev] Content types which are not compatible with the normal pulp workflow

y bringing all the content into one place, and that > place having a tasking system that plugin writers can control how their > content can be analyzed continuously. > > Also +1 to jortel's idea. I think that's a great idea and exactly what we > need. > > > On Thu, May

Re: [Pulp-dev] Content types which are not compatible with the normal pulp workflow

ical git history between Pulp and the git repository being synced / uploaded into Pulp One of them has to give. On Mon, May 28, 2018 at 8:01 AM, Milan Kovacik wrote: > On Sat, May 26, 2018 at 2:23 AM, Daniel Alley wrote: > > @Brian > > > > I agree with a lot of t

Re: [Pulp-dev] PUP5 -- Adopting the "Common Cure Rights Commitment" for Pulp Core

+0 On Thu, May 31, 2018 at 3:49 PM, Robin Chan wrote: > Voting closes June 2nd. > > I have read this through and appreciate @richardfontana's > response/explanation to questions: https://github.com/pulp/pups/ > pull/9#issuecomment-393317027 > > +1 > > On Wed, May 23, 2018 at 11:29 AM, Dennis Kli

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > The article[1] you mentioned states that 'ID' *should* be used for the PK It does say this, but it says that the reasons for doing that are because id is "short, simple, and unambiguous", and that the reason you shouldn't prefix is because "the extra prefix is redundant". I think it's really

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

e similar problems. If a plugin writer >>> defines a 'pk' field then core code using using 'object.pk' will cause >>> core code to receive their attribute and not the primary key. I think >>> overall the strategy I think to minimize collisions we should use

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

ass, it would have "pk" as > reserved and "_id" since we define the primary key in the ancestor class > they inherit from. It also would have "_created" and "_last_updated" > reserved. This should cause minimal collisions with the plugin writer&#x

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > just curious, where does the rpm 'id' come from and how is it used > differently than the NEVREA composite natural key. It's a part of Erratum, not the actual RPM content, so it's unrelated to NVREA. An example of an errata "id" would be "RHEA-2013:1777". I agree with your point about '_id'

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > 1) If we do this, what happens when someone uses multiple plugins and both > of them want to use id as well? Wouldn't it be better to have the core > application reserving it and *all* plugins doing some derivative name? > One plugin wouldn't affect another since it's namespaced by table - it

Re: [Pulp-dev] Ideas for the plugin template

+1 On Mon, Jun 18, 2018 at 12:16 PM, Brian Bouterse wrote: > +1 > > On Mon, Jun 18, 2018 at 8:47 AM, Ina Panova wrote: > >> +1 >> >> >> >> >> Regards, >> >> Ina Panova >> Software Engineer| Pulp| Red Hat Inc. >> >> "Do not go where the path may lead, >> go instead where there is no pa

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

gt;> 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 Thu, Jun 14, 2018 at 9:38 PM, Jeff Ortel wrote: >> >>> >>> >>> On 06/14/2018 12:19 PM, J

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

Another way of thinking of it would be: "don't store store this unless you absolutely know that the base of the URL will never, ever change". Storing IDs is fine, storing hrefs may potentially not be, because it can change out from underneath you. I think it's actually a similar concept. On Thu,

Re: [Pulp-dev] Pagination in Pulp

Until Pulp actually goes GA I don't think we need to be concerned too strongly about semantic versioning. I agree that we should avoid painful changes unless they're truly necessary, though. On Tue, Jun 26, 2018 at 10:34 AM, Dana Walker wrote: > Thanks, Jeremy, for pointing that out! > > Those w

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > Base URLs should never change. That's an expectation that all web > application clients everywhere should be able to rely on. Isn't changing the hostname something that downstream explicitly supports? (I could be wrong here, I'm only recollecting random chats from months ago). On Thu, Jun 21

Re: [Pulp-dev] Revising PUPs

+1 On Mon, Jul 9, 2018 at 9:02 AM, Milan Kovacik wrote: > Hey David, > > thanks, +1 > > -- > milan > > On Mon, Jul 9, 2018 at 1:49 PM, David Davis wrote: > >> I’ve opened a PR with the process on how to revise a PUP. >> Reviews/feedback are welcome: >> >> https://github.com/pulp/pups/pull/11 >>

Re: [Pulp-dev] Branch protection

+1 On Tue, Jul 10, 2018 at 3:30 PM, David Davis wrote: > We noticed in Pulp that the 2-master branch has branch protection but only > to prevent force pushes and deletion. I was wondering if we should also add > these checks: > > - Require an approving review > - Require status checks (e.g. unit

Re: [Pulp-dev] Integer IDs in Pulp 3

So, since I've already been working on some Pulp 3 benchmarking I decided to go ahead and benchmark this to get some actual data. Disclaimer: The following data is using bulk_create() with a modified, flat, non-inheriting content model, not the current multi-table inherited content model we're cu

Re: [Pulp-dev] Integer IDs in Pulp 3

the fields) takes about 0.44 seconds if the model has a UUID pk and about 0.33 seconds if the model has a default Django auto-incrementing PK. On Wed, Jul 11, 2018 at 11:03 AM, Daniel Alley wrote: > So, since I've already been working on some Pulp 3 benchmarking I decided > to g

Re: [Pulp-dev] proposed changes to Pulp 3 auto generated docs

Keep in mind that as of yesterday, unless we revert the change, we are using Integers IDs instead of UUIDs https://github.com/pulp/pulp/pull/3549 On Wed, Jul 18, 2018 at 9:57 PM, Bihan Zhang wrote: > > > On Wed, Jul 18, 2018 at 1:05 PM, Dennis Kliban wrote: > >> I was asked on IRC to state wha

Re: [Pulp-dev] Proposal to change default logging to console in Pulp 3

> > Not to say syslog is dead, it's especially useful for clustered installs > which need fancier logging like centralization or off-site replication, etc. And a lot of people who do use syslog are just telling journald to forward logs there, in which case, console logging is still a good default

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

arameters passed in. > - I expect django will generate foreign key fields with double > understores. Eg: content__id > > I'm still -1 for using a *pulp_* prefix. > > Thoughts? > > > On 06/18/2018 01:15 PM, Daniel Alley wrote: > > I'm -1 on going th

Re: [Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

I think it's because the problem only ever existed on master and never made it into to a release. On Tue, Aug 7, 2018 at 12:55 PM, Jeremy Audet wrote: > https://pulp.plan.io/issues/3875 is a regression and does not appear to > be included in the list of fixed bugs, above. > > ___

Re: [Pulp-dev] Installing RQ

Yup. (pulp) [vagrant@pulp3 pulp_python]$ which rq > ~/.virtualenvs/pulp/bin/rq > Inside a virtualenv everything is kind of weird, for example "pip" and "python" both map to the python 3 variants instead of the python 2 variants, which you would typically expect those names to map to. On Tue, Aug

Re: [Pulp-dev] Plan to handle ids and hrefs

As per the other discussion thread, I assume the names will actually be _id, _type, _href? Errata have both "id" and "type" fields, so if we're going to attempt to keep the Pulp metadata field names out of the way of Content field names, we need to do it for all of them. On Wed, Aug 8, 2018 at 1

Re: [Pulp-dev] Revisit: sync modes

> > It's possible we could want additional sync_modes in the future. To me, > sync mode deals with the contents of the repo during the sync. There are > other ways you would want to have a sync associate content with a > repository. Consider a retention behavior that retains 5 versions of each > un

Re: [Pulp-dev] Pulp smash test docs and issues

> > I think this is fine where it is. pulp2 is going into maintenance mode at > some point here soon. That makes sense for the Pulp 2 smash test docs, but it's still a problem if we want to have smash test docs for Pulp 3 (which, we do) On Thu, Aug 9, 2018 at 5:12 PM, Brian Bouterse wrote: > T

Re: [Pulp-dev] PUP-1 template missing field

+1 On Mon, Aug 13, 2018 at 3:35 PM, David Davis wrote: > I am making a small tweak to PUP-1 to include version in the template. I > forgot to do so when I added the revision process to PUP-1. > > https://github.com/pulp/pups/pull/13 > > Please vote by August 25, 2018. Again the options are: > >

Re: [Pulp-dev] Pulp Code Owners

+1. My understanding is that this will not directly limit who can review or merge code, but should streamline the review process by notifying relevant parties? On Mon, Aug 13, 2018 at 5:29 PM, David Davis wrote: > We have come up with initial proposal of how to use code owners feature in > Pulp.

Re: [Pulp-dev] Pulp Code Owners

t; >> +0 who's the relevant party if not the commit bit owner? >> +1 for commit bit owners receiving automatic notification to review >> >> -- >> milan >> >> On Tue, Aug 14, 2018 at 12:56 AM, Daniel Alley wrote: >> >>> +1. My understandi

Re: [Pulp-dev] Switching Pulp3 settings.yaml to settings.py file

So, right now, our settings actually *are* in settings.py. When settings.py gets evaluated it looks up settings.yaml, parses it into a dictionary, and then uses that dictionary to modify it's own attributes. https://github.com/pulp/pulp/blob/a175c118f9466ac822f22f138cb6cea339b39f54/pulpcore/pulpc

[Pulp-dev] commit-bit nomination

Now that PUP 6 has been merged, it's time to follow the process :) I would like to nominate Milan Kovacik (mkova...@redhat.com) for a commit bit on these repositories: - pulp - pulp_rpm - devel Milan has demonstrated a consistent dedication to quality in his contributions and his revi

Re: [Pulp-dev] Proposal to drop support of Python 3.5 for Pulp 3

Personally, +1. I ran into this issue myself and it was infuriating to deal with. dict objects preserve insertion-order (officially declared part of > the language with Python 3.7). Eliminates a source of subtle > "works on 3.6, sometimes works on 3.5" bugs. > Just to expand on this though:

Re: [Pulp-dev] commit-bit nomination

mmates, and bugfixes are for. >>>>> We need trust, not control beyond the basic level to mitigate risks. >>>>> >>>>> >>>>> >>>>> >>>>> Either way, this type of conversation is probably best suited for &g

Re: [Pulp-dev] Replace pulp_template repo with cookiecutter template

Cookiecutter looks really nice and I'm not opposed to switching, but I don't expect we would save much maintenance work in doing so. We aren't doing / haven't needed to do too much maintenance on boostrap.py that I'm aware of, it seems like it's relatively complete and tested. Most of the maintena

Re: [Pulp-dev] Spam on plan.io

Maybe the first comment / issue posted by an account would need to be approved, but once approved they could post subsequent comments / issues without delay? On Wed, Oct 31, 2018 at 1:28 PM, Brian Bouterse wrote: > Below is what plan.io got back to me with. I list some options below that. > > ==

Re: [Pulp-dev] Dev freeze

+1 On Mon, Nov 5, 2018 at 3:48 PM, Dana Walker wrote: > That sounds good to me, and consistent with the wikipedia definition of a > feature freeze. [0] > > > [0] https://en.wikipedia.org/wiki/Freeze_(software_engineering) > > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat >

Re: [Pulp-dev] Pulp 3 RC Blocker tag

I am assuming that this can be used on a per-plugin basis, e.g. that applying this tag to an RPM plugin will be assumed to mean the RPM plugin RC as opposed to core? On Wed, Nov 28, 2018 at 9:45 AM David Davis wrote: > Just wanted to make a quick announcement that there’s a new RC Blocker tag >

Re: [Pulp-dev] Pulp 3 RC Blocker tag

upcoming Pulp RC? One > solution would be to have plugins use milestones and reserve the Pulp 3 RC > Blocker tag for the upcoming Pulp 3 RC. > > David > > > On Thu, Nov 29, 2018 at 7:36 AM Brian Bouterse > wrote: > >> >> >> On Wed, Nov 28, 2018 at 10:16

Re: [Pulp-dev] Distributing Pulp3 Plans

No objection On Mon, Dec 3, 2018 at 11:52 AM Jeff Ortel wrote: > +1 > > On 12/1/18 6:01 AM, David Davis wrote: > > +1 from me. > > David > > > On Fri, Nov 30, 2018 at 10:26 AM Dennis Kliban wrote: > >> No objections from me. >> >> On Thu, Nov 29, 2018 at 7:50 AM Brian Bouterse >> wrote: >> >>>

[Pulp-dev] Proposal to remove 'notes' fields from the Pulp 3 RC

*Background:* "Notes" are a generic key value store where data can be attached to repositories and content and publications and so forth. The eventual plan is to use this to enable adding tags to those sorts of objects, which is important for Katello. Most of the code for this is located in pulp

  1   2   3   >