Re: [Pulp-dev] Backlog cleanup, Nodes
Fine with me. 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." - Original Message - From: "Austin Macdonald" To: pulp-dev@redhat.com Sent: Wednesday, September 7, 2016 10:04:25 PM Subject: [Pulp-dev] Backlog cleanup, Nodes Since we are dropping nodes support in Pulp 3.0, we can close some stories. If there are no objections, I will close all of these. https://pulp.plan.io/issues/1067 https://pulp.plan.io/issues/938 https://pulp.plan.io/issues/893 https://pulp.plan.io/issues/882 https://pulp.plan.io/issues/629 https://pulp.plan.io/issues/486 https://pulp.plan.io/issues/417 https://pulp.plan.io/issues/302 https://pulp.plan.io/issues/180 https://pulp.plan.io/issues/62 https://pulp.plan.io/issues/44 https://pulp.plan.io/issues/1741 https://pulp.plan.io/issues/1411 https://pulp.plan.io/issues/1392 ___ 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] Upcoming epel6 Dependency Issues
+1 to option 3 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." - Original Message - From: "Michael Hrivnak" To: "Brian Bouterse" Cc: pulp-dev@redhat.com Sent: Monday, November 7, 2016 9:32:08 PM Subject: Re: [Pulp-dev] Upcoming epel6 Dependency Issues Thanks for the clarification. If they do end up removing Django14 from epel6, I think we have these options: 1) Provide a django package ourselves. No supported django release runs on python 2.6, so we would be providing an unsupported version. 2) Show users how to install django some other way. Either by retrieving the Django14 package direct from the build system, or via pip, or something else. It's clear in this case that the user is taking responsibility for installing an old and unsupported version of django, and they must be vigilant. It's the price for running pulp on el6. 3) Stop supporting el6. This might be the nail in the coffin. It's getting harder all the time to provide supported dependencies on el6, and el7 has been out for a while now. If the platform removes one of our biggest dependencies, there's only so much effort we should reasonably go to as an upstream to keep it working. Thoughts? Preferences? I lean toward option 3 but could be persuaded. Michael On Wed, Nov 2, 2016 at 4:18 PM, Brian Bouterse < bbout...@redhat.com > wrote: That date was all wrong. The real date is Wednesday 11/9 at 18:00 UTC in #fedora-meeting on freenode. Yes they would add python34 to epel6, then add Django 1.8 package that only runs on Python 3.4. Since there are a lot of cve's against Django14 they seemed inclined to remove it soon. Packages being incompatible with the 3.4 runtime would have to handle that themselves. As you point out, once Django14 is removed, anything Pulp 2.6+ would break. We should try to get them to leave Django14 in the repo for as long as possible. It's called Django14 and the new one would be python-django I believe, so there shouldn't be an issue with them both being offered in epel6. On Wed, Nov 2, 2016 at 3:35 PM, Michael Hrivnak < mhriv...@redhat.com > wrote: On Wed, Nov 2, 2016 at 3:10 PM, Brian Bouterse < bbout...@redhat.com > wrote: It seems that the mongodb and Django14 packages in EPEL6 are going to be changing in some big ways. It's still early in the conversation, but here is what I've learned at the EPSCO (EPel Steering COmmitee) meeting today[0]. mongodb 2.4 is not supported upstream from epel and EPSCO approved an upgrade of mongodb in epel6. It will likely be to a 3.x based version. It will first be pushed to epel-testing first. What is the newest mongodb that we are compatible with? do we know? One idea I have is to create pulp-smash test jobs which are testing pulp using bits from epel-testing in addition to epel-release. That will help us identify issues before one day it just breaks on us. Also, Django14 is on the short list to be pulled from epel6 due to upstream not supporting it and is unmaintained from a cve perspective. Everyone recognizes now that it must be replaced with something versus what happened last time of having it just removed. The current thinking is to add python34 (not scl) to epel6 and add python-django 1.8 to epel6 also. The will be discussed again at the EPSCO meeting next week on Thursday 11/2 at 18:00 UTC in #fedora-meeting on freenode. I'm planning to attend, but come if you're interested. One or more parts of the date/time can't be right. Can you double-check? This still isn't great for Pulp 2.y on EL6. Pulp will break when Django14 is removed, even if Django 1.8 is available because Pulp 2.y and all of its deps would have to be updated to run in the Python 3.4 runtime. I believe this will likely happen before Pulp 3 is even released. I don't think we're going to switch the EL6 runtime to Python 3.4 for Pulp 2.y, so we need to think carefully about our options here. Are you saying they would add python34 to epel6, then add a django 1.8 package that only runs on python 3.4? I suppose that would make some sense since django 1.8 dropped support for python 2.6. But it wouldn't be much help for pulp 2.y. ___ 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] RFC: new redmine project for pulp 3 ?
I tend to agree with Brian. I agree that with creation of another project will confuse more the users. I also like the idea of creation new tags, or renaming existing ones more than creation of new project. 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." - Original Message - From: "Brian Bouterse" To: "Elyezer Rezende" Cc: pulp-dev@redhat.com Sent: Wednesday, November 9, 2016 10:24:31 PM Subject: Re: [Pulp-dev] RFC: new redmine project for pulp 3 ? I would like to continue using our existing Redmine projects as we transition from 2.y to 3.y. I think users will be even more confused in our already confusing Redmine. Also I want to keep the Redmine Care-And-Feeding™ to a minimum. I can understand the challenge in currently tracking a "pulp 3 MVP" vs "pulp 3 after-MVP" issue. I have a few ideas in this area: * Let's not spend any time/energy on Pulp 3 post MVP things. This is an opportunity cost argument, and any time spent planning for after the MVP delays the MVP. * If we absolutely have to have a way to enter and track those things we can make a 'Pulp 3 Future Feature' or 'Pulp 3 After MVP'. There are only a few (like ~2) issues like this that I know of. * Maybe renaming the 'Pulp 3' tag to 'Pulp 3 MVP' would be good? * We can probably delete the prefactor tag. I think that ship has sailed. In terms of how to deal with the fact that almost all of our bugs won't be relevant to Pulp3, as we are closer to the Pulp3 release date we can put together a simple plan then. I don't think a new Redmine project will help us with this work and more than a mass tag would for example. Thoughts? On Wed, Nov 9, 2016 at 9:26 AM, Elyezer Rezende < ereze...@redhat.com > wrote: I can't provide a full feedback but will leave some thoughts: State of the "Pulp" project in redmine now: - There is a huge backlog of pulp 2 issues, most of which will become irrelevant or implicitly resolved by pulp 3. We'll need to do a big purge eventually. Doing a purge means that relevant issues will be marked as resolved for Pulp 3? I mean we will eventually go through all pending issues and do so sort of review of them? Or it will be just check them all and close? - Nearly all new issues added will be for pulp 3. Only bug reports and a very small number of RFEs will be added for pulp 2. If we still have the majority of customers using Pulp 2 then maybe the majority of the issues can be Pulp 2 related. Do we already have any position about some of our customers willing to upgrade to Pulp 3? Also having a seamless upgrade path from 2 to 3 would be great and ease that process. Since pulp 3 is such a major refactor/rewrite, it might make sense to have hard separation between pulp 2 and 3 issues. Within a separate pulp 3 issue tracker, we could identify what qualifies for the MVP using a tag, and only move over issues from the pulp 2 tracker that are identified as relevant. Yes, having a separated project makes sense here. That will make easy to separate what is 2 and what is 3 related stuff. But we may be in a spot where we need to deal with two projects in order to define milestones, sprints, etc, at least until Pulp 2 is fully deprecated. Potential Downsides: - If we do it for platform, would we also do it for all of the plugins and other remine projects? It might still be worth it, but that increases the complexity of this change. Having it for platform makes sense but plugins I am not sure since they have a separate versioning process. Also would a particular version of a plugin be compatible with both Pulp 2 and 3, does it make sense at all? - Does it impact any team processes, automation, etc? For QE processes I think that will not be an issue since we can target the proper issues for skipping/selecting tests, that is the major usage of Redmine issues on QE automation. - Will it be confusing to users? I think we could keep that straight, and it's easy to move an issue from one project to another if someone files a bug in the wrong place. I is not confusing for most of the cases I can think of, except if for some reason an issue can be relevant for both Pulp 2 and 3 (when this happens should we have separated issues?). I can't think on an example of an issue being required for both versions but wanted to bring it up. I hope you find my comments useful or at least can open up for some further conversation. Cheers -- Elyézer Rezende Senior Quality Engineer irc: elyezer ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev ___ Pulp-dev mailin
Re: [Pulp-dev] Upcoming epel6 Dependency Issues
I like this approach. w/r to the blog post, would be good to explicitly point the users to give feedback on pulp-list (who knows, maybe not every user is aware of this list), since the comments are disabled. 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." - Original Message - From: "Brian Bouterse" To: "Elyezer Rezende" Cc: pulp-dev@redhat.com Sent: Monday, November 14, 2016 7:06:12 PM Subject: Re: [Pulp-dev] Upcoming epel6 Dependency Issues After some discussion today we determined the following will be done: @mhrivnak is going to solicit feedback via pulp-list on how long (time or release) users want us to continue producing el6 builds for. I will produce a blog post identifying what this epel6 change means for EL6 Pulp users We decided to not enable comments on blog posts to keep the discussion in one place (pulp-list). Thank you @elyezer for the feedback. On Mon, Nov 14, 2016 at 8:01 AM, Elyezer Rezende < ereze...@redhat.com > wrote: Do these kinds of next steps make any sense? What are some other approaches or next steps that would be good/better? Trying to get user feedback makes completely sense to me. Having that feedback as early as possible will help us find how we can support Pulp users and identify the impact of dropping RHEL6 support. About enabling comments on blog posts I remember we talking about that for other reason and maybe this is a good opportunity to have it. -- Elyézer Rezende Senior Quality Engineer irc: elyezer ___ 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] Pulp logo with new fonts
Team, take a look at the changes that have been done [0]: - leaves are a bit shrunk, so they will not draw that much attention and now logo is more proportional - the middle hole is also shrunk a bit, for the same reason as leaves - font changed - the distance between elements is increased so logo would be seen better when it changes in sizes(big/small) - note the favicon - taker a look how logo looks like on light and dark background [1] [2] If you want to play more, here is the logo version [3] you can upload here [4] Number 2 was my crazy idea to try with centralized leaves and segments but seems like it does not look good. [0] http://imgur.com/a/Vx0CO [1] http://placeit.net/916de6bd7841d12 [2] http://placeit.net/09793f7b984339c [3] http://i.imgur.com/uKmypXY.png [4] https://placeit.net/c/apparel/stages/pullover-hoodie-mockup-of-a-girl-inside-an-abandoned-wagon-a12486?f_devices=woman Let me know your thoughts and ideas. 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Mission statement finalization
Team, During PulpCon we were defining our mission. >From my understanding this would be final version 'Acquire, Organize, and >Distribute Software'. Does anyone wants to change/add here something? Otherwise this ^^ would be considered as final and official version. Here the pad where we were discussing possible statements [0]. [0] http://pulp.etherpad.corp.redhat.com/290 -------- 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] release process updates
Do i understand correctly that blocker bugs will not be verified by default, unless we would set "require QE signoff" to True? 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 Mon, Jan 16, 2017 at 8:35 PM, Brian Bouterse wrote: > Yes I think it captures the discussion. +1 to all ideas you've written. > > [related ideas] > * The release criteria and workflow document is not community visible. > Does it make any sense to move that to the wiki? > * For the two new fields proposed, they should apply to Redmine tracker > types (Story, Issue, and Task but not Refactor). Refactors cannot be > "verified" or "require QE signoff" because by definition they should > perform. > * For mailing list proposals with feedback, what about a time limit. > Perhaps 1 week? If there are no -1s given by Jan 24th, we could consider > this proposal accepted. > * After feedback is given, we should turn these into Redmine tasks > (probably 3 tasks, 1 for each section). > > Thanks for sending this out. > > -Brian > > On Mon, Jan 16, 2017 at 12:53 PM, Jeremy Audet wrote: > >> This email is a follow-up to today's "Release process and communication." >> The goal of today's conversation was to improve how the dev and QE teams >> interface. The following proposals were made. >> >> Documentation Improvements >> -- >> >> The Pulp Release Criteria and Workflow >> <https://mojo.redhat.com/docs/DOC-1101802> document appears to contain >> errors: >> >> * The "Y Releases" section states that "Pulp issues addressed by the >> release must be verified." Otherwise, the release is blocked. >> * It is not clear whether blocker bugs require verification. >> >> These errors can be fixed like so: >> >> * State that Y releases may be released even with bugs that haven't been >> verified. This is the same as for Z releases. >> * State that blocker bugs do not require verification. >> >> Verification Tracking Improvements >> -- >> >> There should be some way for QE to state that an issue has been verified. >> QE currently does this through the VERIFIED state, but this is problematic: >> issues are changed to a CLOSED state when bugs are released, effectively >> erasing QE's stamp of approval. The proposed solution is to update how >> redmine tracks issues: >> >> * Remove the VERIFIED state from issues. >> * Add a 'verified' field to issues. Let this field be a boolean, and let >> it default to false. >> * Remove references to the VERIFIED state from upstream and downstream >> automation. >> * Remove references to the VERIFIED state from the docs, if present. >> >> Verification Request Improvements >> - >> >> The developers should have some mechanism to require that an issue be >> verified before a release goes out the door. This mechanism should be >> present because most releases are not blocked based on whether or not QE >> has verified an issue. The proposed solution is to let pulp.plan.io >> track this information: >> >> * Add a 'require QE signoff' field to issues. Let this field be a >> boolean, and let it default to false. >> * Expand release announcement emails. Let the emails include a link to a >> pulp.plan.io query that returns all issues requiring QE verification, >> and possibly copy-and-paste this list into the release announcement emails. >> >> - >> >> Does this capture the actionable topics from today's discussion? Do you >> agree with these proposals, or not? (Even a simple "Yes, and yes." is >> useful.) >> >> —Jeremy >> >> ___ >> 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
Re: [Pulp-dev] release process updates
I personally would be -1 then( to this point ), because if we state that we cannot make release with blokers opened, that would be not really wise to make the actual release without their verification. How can we state that the blocker was fixed and in addition what's then the point then to make the issue as blocker and fix it in tight deadlines. I think all blocker bugs should be verified by default, and other bugs just when there's flag set by devs. 18 янв. 2017 г. 19:23 пользователь "Brian Bouterse" написал: Yes, that is my understanding. On Wed, Jan 18, 2017 at 12:39 PM, Ina Panova wrote: > Do i understand correctly that blocker bugs will not be verified by > default, unless we would set "require QE signoff" to True? > > > > > > 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 Mon, Jan 16, 2017 at 8:35 PM, Brian Bouterse > wrote: > >> Yes I think it captures the discussion. +1 to all ideas you've written. >> >> [related ideas] >> * The release criteria and workflow document is not community visible. >> Does it make any sense to move that to the wiki? >> * For the two new fields proposed, they should apply to Redmine tracker >> types (Story, Issue, and Task but not Refactor). Refactors cannot be >> "verified" or "require QE signoff" because by definition they should >> perform. >> * For mailing list proposals with feedback, what about a time limit. >> Perhaps 1 week? If there are no -1s given by Jan 24th, we could consider >> this proposal accepted. >> * After feedback is given, we should turn these into Redmine tasks >> (probably 3 tasks, 1 for each section). >> >> Thanks for sending this out. >> >> -Brian >> >> On Mon, Jan 16, 2017 at 12:53 PM, Jeremy Audet wrote: >> >>> This email is a follow-up to today's "Release process and >>> communication." The goal of today's conversation was to improve how the dev >>> and QE teams interface. The following proposals were made. >>> >>> Documentation Improvements >>> -- >>> >>> The Pulp Release Criteria and Workflow >>> <https://mojo.redhat.com/docs/DOC-1101802> document appears to contain >>> errors: >>> >>> * The "Y Releases" section states that "Pulp issues addressed by the >>> release must be verified." Otherwise, the release is blocked. >>> * It is not clear whether blocker bugs require verification. >>> >>> These errors can be fixed like so: >>> >>> * State that Y releases may be released even with bugs that haven't been >>> verified. This is the same as for Z releases. >>> * State that blocker bugs do not require verification. >>> >>> Verification Tracking Improvements >>> -- >>> >>> There should be some way for QE to state that an issue has been >>> verified. QE currently does this through the VERIFIED state, but this is >>> problematic: issues are changed to a CLOSED state when bugs are released, >>> effectively erasing QE's stamp of approval. The proposed solution is to >>> update how redmine tracks issues: >>> >>> * Remove the VERIFIED state from issues. >>> * Add a 'verified' field to issues. Let this field be a boolean, and let >>> it default to false. >>> * Remove references to the VERIFIED state from upstream and downstream >>> automation. >>> * Remove references to the VERIFIED state from the docs, if present. >>> >>> Verification Request Improvements >>> - >>> >>> The developers should have some mechanism to require that an issue be >>> verified before a release goes out the door. This mechanism should be >>> present because most releases are not blocked based on whether or not QE >>> has verified an issue. The proposed solution is to let pulp.plan.io >>> track this information: >>> >>> * Add a 'require QE signoff' field to issues. Let this field be a >>> boolean, and let it default to false. >>> * Expand release announcement emails. Let the emails include a link to a >>> pulp.plan.io query that returns all issues requiring QE verification, >>> and possibly copy-and-paste this list into the release announcement emails. >>> >>> - >>> >>> Does this capture the actionable topics from today's discussion? Do you >>> agree with these proposals, or not? (Even a simple "Yes, and yes." is >>> useful.) >>> >>> —Jeremy >>> >>> ___ >>> 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
Re: [Pulp-dev] release process updates
Jeremy, that totally answers my question, I just personally do not fully agree with our current approach. If we decide to improve it - then the blockers should be verified by default, because until they are un-verified we cannot state 100% that it was fixed. And imagine the situation we find same blocker regression in just released version - that would be a double-facepalm. I've being silent on purpose for couple of days to see feedback/other point of view(?) from other colleagues as well. P.S. I agree with you on refactor/issue/task being verified just on request. 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 Mon, Jan 23, 2017 at 8:51 PM, Jeremy Audet wrote: > David, does my response answer your question? > > Ina, same to you: does my response answer your question? Let me recap a > few points: > >- Pulp releases currently go out the door with un-verified (but fixed) >blocker issues. None of these proposals change that policy. >- If a developer wants a release to be held up until an issue is >verified, they currently must email pulp-qe-list and contact (via IRC? or >email?) the release engineer. Furthermore, finding out which issue(s) are >holding up a release requires reading an email thread and/or pinging the >release engineer, then looking at each affected issue. That's doable, but >it would be easier if the information was tracked in redmine: holding up a >release until a issue is verified would require nothing more than changing >a field on an issue in redmine, and finding out what's holding up a release >requires a redmine query. > > Also, I appreciate the intent behind requiring that refactors or blockers > be verified before a release can go out, but let's bear in mind the > consequences of such a decision. Consider the current 2.12 release: QE is > preoccupied with fixing automated tests that broke as a result of the > repository layout changing, so that we can provide assurance that no > regressions occurred. That alone may push back the release by a day or two. > Requiring verification for all refactors/blockers/etc regardless of their > importance will almost certainly make such delays commonplace. It will also > stress QE's ability to be flexible and occasionally take on other projects. > (For example: I recently took a course on Ansible through RHU. I definitely > spent less time verifying issues while doing that.) > > -Jeremy > > ___ > 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] Merging forward commits
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 is so super simple, i must admit i had issues to understand this strategy from the beginning but now i could do that even with closed eyes. +1 of writing down the benefits of cherry-picking and clear our expectations. 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 Thu, Feb 2, 2017 at 6:50 PM, David Davis wrote: > I think the merging forward seems pretty straightforward as well (with > some exceptions) but one of the my concerns is expecting community > contributors to know our process, the last release branch, etc when they > open a PR. Maybe this isn’t something to worry about though if we don’t > have enough contributions from outside the core Pulp team. > > Another one of my concerns is the git history being cluttered by merging > forward every time we commit a bug fix or hot fix (see my original email). > Thinking through this a bit though, what if we merged forward commits less > often? One option might be to only merge forward when we do a release. > > Also, I like the idea of creating a proposal and trying out cherrypicking > to see what the benefits would be and if we actually meet those benefits by > cherrypicking. > > > David > > On Thu, Feb 2, 2017 at 10:46 AM, Michael Hrivnak > wrote: > >> This comes up periodically, and we've had split opinions for a long time. >> I've been in the camp that likes merging, and finds it intuitive. But I'm >> open to trying cherry-picking since there is a lot of interest. >> >> I must admit, I am always surprised when people describe merging forward >> as complicated. For me, it boils down to this: >> >> - Features happen on master. No merging or cherry-picking required. >> - Bug fixes happen on the last release branch. Merge your bugfix branch >> to master and the release branch. Simple. >> - Hotfixes are a rare exception that require slightly more thought, but >> are still easy to reason about. If in doubt, "git merge-base [list all the >> places you want to merge your fix]" tells you where to branch from. >> >> That's the extent of my thought process when merging forward. I am >> generally interested to know more about how this process causes friction. >> >> But all of that said, I'm very happy to give cherry-picking a try. As >> Brian said, my main concern would just be tracking where a change has been >> applied. This is something I value a lot in the merge model. >> >> If we do switch, I think we should first write down specifically what >> benefits we expect to get. That would help in two ways: 1) Make sure >> everyone is on the same page about what we expect to gain. I suspect there >> are differing assumptions across the group. 2) Enable us to evaluate >> afterward to what extent the change was successful. >> >> Lastly, our current branching model was inspired by this classic approach: >> >> http://nvie.com/posts/a-successful-git-branching-model/ >> >> If you're not familiar, it's worth a read for perspective. Their >> "develop" branch is our "master". And obviously we don't do things in quite >> the same way, but the general principles are the same. >> >> Michael >> >> On Thu, Feb 2, 2017 at 3:34 PM, Brian Bouterse >> wrote: >> >>> The main concern for me is how to track the cherry picks in Redmine. >>> Using the rebase and merge approach, or if Github had a dedicate cherry >>> pick feature, we still need a way in Redmine to know if any given bugfix >>> has been applied to older release streams, i.e. the current bugfix release >>> stream. >>> >>> On Wed, Feb 1, 2017 at 12:18 PM, Jeremy Audet wrote: >>> >>>> > Thinking out loud, it would be nice if github would support a >>>> "cherry pick" PR >>>> >>>> I think you can. The submitter just needs to open a PR against some >>>> branch other than master, and the merger needs to select the rebase >>>> and merge <https://github.com/blog/2243-rebase-and-merge-pull-requests> >>>> GUI option. >>>> >>> >>> >>> ___ >>> 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 > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] RFC process
I think all mentioned options could be used, but we need to have a starting point. Something that would track a discussion for a long time. And i lean towards ---> open a story/task (as a starting point). Having a story/task opened we can always reference it in mail discussion or etherpad. Why i prefer to have all/most of the discussion happen on the story/task? Because i cannot guarantee that i will not miss somehow the email or etherpad. I actually often find myself trying to dig through dozens of mails to find the right one. Same with the etherpads :) Because i receive notifications when someone adds a comment on the task/story, even after one month or two. This does not happen with etherpad, and i actually will not see the new comments/ideas until i will check the pad by myself. Periodically. From time to time. Remembering the right pad number, and of course i do not remember it, so i will need to dig into my mails to find it out. 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 Mon, Feb 6, 2017 at 4:59 PM, David Davis wrote: > One of the things that came up in our retrospective is that we don’t have > a formal way to propose changes to our codebase and processes (aka RFCs). > This was motivated in part by the recent discussion on merging forward > commits on our pulp-dev mailing list. > > I'd like to maybe discuss a way we can propose RFCs and then document this > process in our docs. It sounds like there has already been some discussion > about how to handle RFCs so I apologize coming into this without having any > background. > > Thinking through RFCs, I see two things to address. First is the actual > format of the RFC. I see some RFCs in plan.io but it doesn’t seem like > there’s a standard way of formatting an RFC. Should there be? For > reference, here's the template for foreman RFCs. I think it might serve as > a good starting point: > > https://github.com/theforeman/rfcs/blob/master/-template.md > > Secondly, there’s the question of where to discuss and archive RFCs. Some > possible options: > > 1. Open a story or task on plan.io > 2. Use a GitHub repo to store and discuss RFCs (e.g. > https://github.com/theforeman/rfcs) > 3. Write the RFC on an Etherpad and once accepted, open a plan.io issue. > 4. Just send out RFCs to the mailing list > 5. Something else? > > I was thinking we could also use the mailing list in addition to options > 1-3 by sending out an email pointing people to the actual RFC. > > Thoughts? > > David > > ___ > 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] PyPI names for Pulp3
I went through all the thread and I personally do not like any of options. -1 pulp3 +0 pulpproj -0 pulp_platform -1 plp I somehow agree what Jeff pointed out but looks like pulpproj given the current situation is the 'winner'. I do not know what to do about this, but maybe email our community and ask what do they think? maybe they will come up with new ideas. Not sure if it is a good idea, though. 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 Wed, Apr 19, 2017 at 9:01 PM, Dennis Kliban wrote: > +1 to pulpproj > > On Wed, Apr 19, 2017 at 12:59 PM, Sean Myers > wrote: > >> On 04/19/2017 12:02 PM, Brian Bouterse wrote: >> > Two fyi's relating to the names. (1) pulpproj is our twitter handle. >> Both >> > pulp and pulpproject were already taken. (2) I agree that pulp3 could >> be a >> > headache down the road regardless of if the 3 is for Pulp3 or Python3. >> >> Yeah, I was only kidding about the python3 thing, it's too ambiguous. >> >> I'm still +1 pulpproj >> >> >> >> ___ >> 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
Re: [Pulp-dev] PyPI names for Pulp3
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 where the path may lead, go instead where there is no path and leave a trail." On Thu, Apr 20, 2017 at 12:51 PM, Ina Panova wrote: > I went through all the thread and I personally do not like any of options. > > -1 pulp3 > +0 pulpproj > -0 pulp_platform > -1 plp > > > I somehow agree what Jeff pointed out but looks like pulpproj given the > current situation is the 'winner'. > > I do not know what to do about this, but maybe email our community and ask > what do they think? maybe they will come up with new ideas. Not sure if it > is a good idea, though. > > > > > 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 Wed, Apr 19, 2017 at 9:01 PM, Dennis Kliban wrote: > >> +1 to pulpproj >> >> On Wed, Apr 19, 2017 at 12:59 PM, Sean Myers >> wrote: >> >>> On 04/19/2017 12:02 PM, Brian Bouterse wrote: >>> > Two fyi's relating to the names. (1) pulpproj is our twitter handle. >>> Both >>> > pulp and pulpproject were already taken. (2) I agree that pulp3 could >>> be a >>> > headache down the road regardless of if the 3 is for Pulp3 or Python3. >>> >>> Yeah, I was only kidding about the python3 thing, it's too ambiguous. >>> >>> I'm still +1 pulpproj >>> >>> >>> >>> ___ >>> 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
Re: [Pulp-dev] PyPI names for Pulp3
Team, we need to make some progress on this and try to find a common agreement. Based on the email thread, i will summarize the options which where proposed. I will highlight mainly the concerns brought up by people( where there have been expressed any). I would like to hear more feedback *here in the thread* so later i can shrink the options and then i will create the Doodle for voting. 1) pulpproj, pulp_project, pulpproject. - Some people are opposed to having any form of the word "project" as part of the name. It's like having Firefox be named "firefoxproj". Plus pulpproject is already taken. 2) pulp3 - is ambiguous regardless of if the 3 is for Pulp3 or Python3. 3) plp - looks like pip 4) pulpapp vs pulp_app 5) pulp_platform 6) spot for new ideas I encourage you all to *speak your piece *before I would create the Doodle. 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 Thu, Apr 20, 2017 at 5:08 PM, Daniel Alley wrote: > +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 where the path may lead, >> go instead where there is no path and leave a trail." >> >> On Thu, Apr 20, 2017 at 12:51 PM, Ina Panova wrote: >> >>> I went through all the thread and I personally do not like any of >>> options. >>> >>> -1 pulp3 >>> +0 pulpproj >>> -0 pulp_platform >>> -1 plp >>> >>> >>> I somehow agree what Jeff pointed out but looks like pulpproj given the >>> current situation is the 'winner'. >>> >>> I do not know what to do about this, but maybe email our community and >>> ask what do they think? maybe they will come up with new ideas. Not sure if >>> it is a good idea, though. >>> >>> >>> >>> >>> 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 Wed, Apr 19, 2017 at 9:01 PM, Dennis Kliban >>> wrote: >>> >>>> +1 to pulpproj >>>> >>>> On Wed, Apr 19, 2017 at 12:59 PM, Sean Myers >>>> wrote: >>>> >>>>> On 04/19/2017 12:02 PM, Brian Bouterse wrote: >>>>> > Two fyi's relating to the names. (1) pulpproj is our twitter handle. >>>>> Both >>>>> > pulp and pulpproject were already taken. (2) I agree that pulp3 >>>>> could be a >>>>> > headache down the road regardless of if the 3 is for Pulp3 or >>>>> Python3. >>>>> >>>>> Yeah, I was only kidding about the python3 thing, it's too ambiguous. >>>>> >>>>> I'm still +1 pulpproj >>>>> >>>>> >>>>> >>>>> ___ >>>>> 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 >> >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Docker Schema version data model question
Partha,
schema_version field specified on Manifest model and on Tag model refers
*just* to the V2 api content.
There is no concept of schema_version and manifest in general for V1
content. For V1 content you have concept of image and parent ids.
So when you are querying collections like units_docker_tag or
units_docker_manifest these are related *just* to V2 content. Which
consists of schema version 1 and schema version 2.
Back to your question about what changes have been made for Pulp data model.
Manifest model has a new field called 'confg_layer' . This layer appears in
specs for V2 content schema version 2.
Tag model has a new field 'schema_version'. Because there could be tags
referencing V2 content schema version 2 and V2 content schema version 1 and
we need to distinguish them.
This will also facilitate,for example, copy operation to avoid confusion.
Same for tag removal operation.
If you take a look at specs for V1 and V2 content I think it will help you
to understand more the concepts and clear the confusion.
V1 specs https://github.com/moby/moby/blob/master/image/spec/v1.md
V2 specs https://docs.docker.com/registry/spec/manifest-v2-1/
https://docs.docker.com/registry/spec/manifest-v2-2/
Since you say Katello uses just V2, the collections and models you should
care are - blobs, tags, manifests.
> Yet when I synced busy box I see manifests with schema-verision = 1.
Shouldnt it be only showing stuff with schema-version=2 ??
With the support of schema version 2, when you sync busybox, Pulp will
query Registry for manifests with tags which reference both schema version
1 and 2 and save those to DB
Again, these above stated concepts are related just to V2 content.
Let me know if you have further questions, I will be happy to answer those.
----
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 Thu, May 4, 2017 at 11:58 PM, Partha Aji wrote:
>
> I was trying to figure out pulp's data model changes with respect to
> DockerV2 Schema2. Looking at https://github.com/pulp/pulp_docker/commit/
> 35dc19c8522f840d464bec2e93f45b4bb57b4f80#diff-
> 6c740284d714e1a0349c86bed5617b76 I only see schema-version column added
> to tags and no changes in the manifest collection. But in the database I
> see the following
> For manifests there is a schema_version column
>
> > db.units_docker_manifest.find()[0]
> {
> "_id" : "582cb097-5c81-499a-adec-5d18470014f5",
> "pulp_user_metadata" : {
>
> },
> "_last_updated" : 1487212925,
> "_storage_path" : "/var/lib/pulp/content/units/docker_manifest/9e/
> 2aadfbd6d73d35bddbf2db2925503047fc84fdcba439f4069c80ceaca37f02/sha256:
> b5dd2db609f090a39b65a39489eb3eb670f559af40fc5d206b2a05451355ba72",
> "downloaded" : true,
> "digest" : "sha256:b5dd2db609f090a39b65a39489eb3e
> b670f559af40fc5d206b2a05451355ba72",
> "name" : "library/busybox",
> "tag" : "1-glibc",
> "schema_version" : 1,
> "fs_layers" : [
> {
> "blob_sum" : "sha256:a3ed95caeb02ffe68cdd9fd8440668
> 0ae93d633cb16422d00e8a7c22955b46d4"
> },
> {
> "blob_sum" : "sha256:df74c0cea8ad6b25004db74b9829d5
> 13990ac7e219128594eb2b7df2d785f961"
> }
> ],
> "_ns" : "units_docker_manifest",
> "_content_type_id" : "docker_manifest"
> }
>
>
> And for tags there is one also.
>
> > db.units_docker_tag.find()[0]
>> {
>> "_id" : "cc3d103d-f6ab-4efd-a936-e99dfc43691d",
>> "repo_id" : "dd8fa453-9923-4fc1-99b6-8137a2bb5bf3",
>> "manifest_digest" : "sha256:3e00695ae65afe08d3cc4e1c0bc4ef
>> b335e9c158c9b5a5f7c045c9ec380c731b",
>> "_ns" : "units_docker_tag",
>> "_last_updated" : 1487212925,
>> "schema_version" : 1,
>> "pulp_user_metadata" : {
>>
>> },
>> "_content_type_id" : "docker_tag",
>> "name" : "1.24.2-glibc"
>> }
>>
>
>
> I am I assuming correctly when I say "schema-version" in
> "units_docker_manifest" refers to api version V1 vs V2 while
> "schema-version" in "units_docker_tag" refers to schema-version1 vs
> schema-version 2 ?
>
> If my assumption is correct then I have a diff issue. Katello typically
> says "use v2 only" when creating a repo. Yet when I synced busy box I see
> manifests with schema-verision = 1. Shouldnt it be only showing stuff with
> schema-version=2 ??
>
>
>>
> ___
> 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] PyPI names for Pulp3
So looks like based on previous input, the results are: 1) PyPI name is ---> pulpproj 2) The answer to the question: Will all packages install under a top level directory or not? YES and it will look like: https://pulp.plan.io/issues/2444#Will-all-packages-install-under-a-top-level-directory-or-not If you deathly disagree please speak out now, otherwise these would be the final decision taken in order to complete https://pulp.plan.io/issues/2444 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 Mon, May 8, 2017 at 5:52 PM, Michael Hrivnak wrote: > Since "app" is a specific concept within Pulp (both a celery app and one > or more django apps), it could be awkward for the entire python namespace > to include the word "app". "import pulpapp.app" feels odd. I would stick > with something that does not overlap with the name of any existing > component or concept in Pulp. > > 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 where the path may lead, >> go instead where there is no path and leave a trail." >> >> On Thu, Apr 20, 2017 at 12:51 PM, Ina Panova wrote: >> >>> I went through all the thread and I personally do not like any of >>> options. >>> >>> -1 pulp3 >>> +0 pulpproj >>> -0 pulp_platform >>> -1 plp >>> >>> >>> I somehow agree what Jeff pointed out but looks like pulpproj given the >>> current situation is the 'winner'. >>> >>> I do not know what to do about this, but maybe email our community and >>> ask what do they think? maybe they will come up with new ideas. Not sure if >>> it is a good idea, though. >>> >>> >>> >>> >>> 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 Wed, Apr 19, 2017 at 9:01 PM, Dennis Kliban >>> wrote: >>> >>>> +1 to pulpproj >>>> >>>> On Wed, Apr 19, 2017 at 12:59 PM, Sean Myers >>>> wrote: >>>> >>>>> On 04/19/2017 12:02 PM, Brian Bouterse wrote: >>>>> > Two fyi's relating to the names. (1) pulpproj is our twitter handle. >>>>> Both >>>>> > pulp and pulpproject were already taken. (2) I agree that pulp3 >>>>> could be a >>>>> > headache down the road regardless of if the 3 is for Pulp3 or >>>>> Python3. >>>>> >>>>> Yeah, I was only kidding about the python3 thing, it's too ambiguous. >>>>> >>>>> I'm still +1 pulpproj >>>>> >>>>> >>>>> >>>>> ___ >>>>> 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 >> >> > > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] PyPI names for Pulp3
I am going to schedule a meeting so we can have a live vital beneficial discussion. Thank you all for participation and feedback, we will try to find a consensus during ^^, or at least next steps. 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, May 9, 2017 at 4:45 PM, Roberts, Ben wrote: > As an alternate suggestion: libpulp? > > No existing naming conflicts with other projects that I can see on Github > (no results) or Google (all top search results are for pulp project related > pages containing “/var/lib/pulp”). > > > > Regards, > > Ben Roberts > > -- > This email and any files transmitted with it contain confidential and > proprietary information and is solely for the use of the intended > recipient. If you are not the intended recipient please return the email to > the sender and delete it from your computer and you must not use, disclose, > distribute, copy, print or rely on this email or its contents. This > communication is for informational purposes only. It is not intended as an > offer or solicitation for the purchase or sale of any financial instrument > or as an official confirmation of any transaction. Any comments or > statements made herein do not necessarily reflect those of GSA Capital. GSA > Capital Partners LLP is authorised and regulated by the Financial Conduct > Authority and is registered in England and Wales at Stratton House, 5 > Stratton Street, London W1J 8LA, number OC309261. GSA Capital Services > Limited is registered in England and Wales at the same address, number > 5320529. > > > ___ > 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] PyPI names for Pulp3
The meeting is scheduled for Tomorrow. Find the details below, everyone is welcome to join. When: Thursday May 11 at 2.30pm UTC Where: https://bluejeans.com/436590399 Interact: https://etherpad.net/p/pypi_naming 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 Wed, May 10, 2017 at 6:55 PM, Ina Panova wrote: > I am going to schedule a meeting so we can have a live vital beneficial > discussion. > > Thank you all for participation and feedback, we will try to find a > consensus during ^^, or at least next steps. > > > > > 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, May 9, 2017 at 4:45 PM, Roberts, Ben > wrote: > >> As an alternate suggestion: libpulp? >> >> No existing naming conflicts with other projects that I can see on Github >> (no results) or Google (all top search results are for pulp project related >> pages containing “/var/lib/pulp”). >> >> >> >> Regards, >> >> Ben Roberts >> >> -- >> This email and any files transmitted with it contain confidential and >> proprietary information and is solely for the use of the intended >> recipient. If you are not the intended recipient please return the email to >> the sender and delete it from your computer and you must not use, disclose, >> distribute, copy, print or rely on this email or its contents. This >> communication is for informational purposes only. It is not intended as an >> offer or solicitation for the purchase or sale of any financial instrument >> or as an official confirmation of any transaction. Any comments or >> statements made herein do not necessarily reflect those of GSA Capital. GSA >> Capital Partners LLP is authorised and regulated by the Financial Conduct >> Authority and is registered in England and Wales at Stratton House, 5 >> Stratton Street, London W1J 8LA, number OC309261. GSA Capital Services >> Limited is registered in England and Wales at the same address, number >> 5320529. >> >> >> ___ >> 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] Terms: unassociate vs. disassociate
+1 for add/remove. An aside note, i want to make sure we stick to 'remove' specifically' and not 'delete'. I wanted to bring this up, since these 2 terms are quite similar but still feels different. 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, May 23, 2017 at 11:34 PM, Brian Bouterse wrote: > +1 to the "adding ..." and "removing ..." terminology. I think it will be > more clear for users. > > On Mon, May 22, 2017 at 4:29 PM, Jeremy Audet wrote: > >> > As an end-user I agree with the add/remove lexicon being more clear to >> users, if not more technically accurate. >> >> Same. Either phrasing gets the message across, but IMO, "add content to a >> repository" is more unambiguous. >> >> ___ >> 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
Re: [Pulp-dev] versioned repositories
I am leaning towards what Mike expresses - make the decisions now w/r to data model and REST API. With regards to: "Implementing a feature internally in an MVP and not fully exposing it to the user does not make sense." And what is the problem with fully exposing it? Yes it is new feature, yes it is unstable and most likely has issues and bugs. But people usually expect more or less this ^ when it comes to a completely new and drastically big change. 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 Wed, May 24, 2017 at 11:05 PM, Michael Hrivnak wrote: > > On Wed, May 24, 2017 at 3:38 PM, Brian Bouterse > wrote: > >> Internals we can change/rework all day, but the thing we need to get >> right is the API because of semver. > > > I agree with this sentiment. But, I think it will be difficult to make the > API be compatible with a repo versioning world if the data model does not > match. > > We could keep versioned repos out of the API and bolt something on later, > but I think we'd end up with an awkward solution, and it would be difficult > to guarantee that we'll be able to maintain compatibility without knowing > exactly what versioned repos will look like. > > Or we could make a facade that looks partially like versioned repos but > doesn't actually implement it under the hood. But that would also be > awkward, more total work, and difficult to get 100% right without having > the model nailed down and agreed upon. > > I'd much rather make the decisions now and go out the door with the data > model and associated REST API we want. > > I'll also emphasize that "not fully exposing it to the user" is not > something I mean to be advocating for. I want to make repo versions a first > class concept in 3.0 and get people in that mindset. Like many things in > 3.0, we can save time by not implementing every related feature and use > case. But just having the basics would already provide a lot of value. It > also helps us with other problems we're facing, such as race conditions > around orphans, and incomplete repo changes (for example if a sync task > fails hard in the middle). > > I also want to point out that the REST API minutia we are discussing needs > to be thought through across our whole API. Removing repo versions from the > design would slightly reduce the total number of resources being RESTified, > but we'd be making most of the same decisions just on a different > collection. > > The plugin work I think can proceed without this. Presumably the plugin > API will include a way to add and remove content, the implementation > details of which are not important to the plugin writer. > > So I do share the same sentiment that I want to get 3.0 out ASAP and make > sure plugin work gets unblocked ASAP. But I think it is worth our time to > get the data model and associated REST API completed up-front, especially > when it comes to an important conceptual change such as this. > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat > > ___ > 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] PUP-3: Proposal to change our git workflow
-0 I don't know, i am personally not super excited about cherry-picking, too many involved resources imho in order to compensate crazy git history. 1. submit pr against master 2. decide into which branches it should be cherry-picked 3. submit PRs against those branches 4. Find someone to approve it( person can approve it right away or can forget), you then need again to bother the person to approve the PR, plus you also can forget about them. 5. If the bugfix/rfe/hotfix consists of several PRs, like platform and plugin, you need to take care of more PRs and be sure you opened all of them and merged all of them. 6. since the commit id changes, you need to keep track of the info externally. That means open Redmine and update it. With merge forward you just merge forward and need to take care of: 1. be sure you merged all PRs through all branches. 2. solve conflicts occasionally. The concern Brian brought up - that contributors do not know against which branch to submit PR. Instead of asking them to re-submit PR against different branch we can cherry pick this, We don't have that 'big traffic' of PRs from contributors and once in a while we can cherry pick if the PR was submitted against wrong branch. Another thing which was stated in the motivation was 'We've also seen some mistakes where branches are accidentally merged into other branches. " I guess we will have much higher chance to make a mistake or forget something between steps 1-6 mentioned for cherry-picking then steps 1-2 mentioned for merging forward. 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 Thu, May 25, 2017 at 6:49 PM, Sean Myers wrote: > On 05/25/2017 10:30 AM, Patrick Creech wrote: > > -1 > > > > While trying to come up with a decision on this topic, I googled "git > merge vs cherry-pick". The > > overwhelming ammount of search results were basically 'don't > cherry-pick!'. The page that I favored > > is [0]. It brings up some good points about loosing git's internal > tracking of commits. It seems > > cherry-picks do get new commit id's instead of using the same ones. > While this site is basically a > > 'Don't cherry pick' opinion piece, it did make me think about our > motivations for moving away. > > Merging forward *does not* guarantee that the changes you're looking > for actually exist on a branch. git-cherry does. The article you > linked is citing a specific problem and blaming it on cherry-picking, > which is that when cherry-picking commits *with conflicts*, you can > confuse git-cherry. This is accounted for in the in the PUP, and for > good reasons. > > > ... > > > > I'm more in favor of us re-evaluating when and how we manage the merge > forwards (as it does appear > > our current automation has been a big source of pain at least once), and > believe that just adding > > better process and diligence around our current way of doing things will > probably be better than > > inventing a new process and figuring out the pain points as we go there. > > In my experience, only one merge-forward problem was caused by > automation (the mergepocalype, when 2.10 was considered "less than" > 2.2, and got merged forward into a lower branch). The rest were > intelligent humans making mistakes, first with a bad merge, and second > by trusting that the appearance of a given commit hash on a branch > means that the *change* associated with that commit hash therefore > also appears on that branch (it does not). Perhaps ironically, any > improvement to the merge-forward process would likely involve using > git-cherry to track actual changes, ignoring what hash is where. > > The suggestions that we invent a better process for merging forward > immeditaely followed by a suggestion to not invent a new process is a > little bit confusing. Either deal with the merge-forward papercuts or > the cherry-pick papercuts, it's inventing new process either way. When > it comes to the merging forward process, the intelligent humans were > (in my opinion) being diligent in their application of the process in > every failure case I can recall, and I don't think just throwing more > "diligence" at the problem will solve it. > > On the other hand, cherry-picking back from master is not a new > process that we're inventing. This is a common workflow, not something > being invented by this PUP, so the opportunity to find help with this > process outside of this team is tremendously valuable. No such > opportunity exists with the merge-forward strategy without moving to a > more generally-accepted merging strategy like git flow(/driessen). > > > ___ > 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] PUP-3: Proposal to change our git workflow
Usually, you tend not have your PR opened for months,especially if it is a bugfix tracked in our sprint :) Really, what is difficult about step 5 and 6 i don't understand? you pull changes so branch is up to date, then you merge into this branch, then you push to upstream. If there are conflicts you are resolving them locally, then pushing upstream. What i want to say in other words - right now the merge or PRs takes me like 2 mins going through whole chain of branch-dev to master. Rarely i need to solve conflicts, but honestly saying i do not remember when was last time i've been solving those. With new approach it will be, merge here, cherry pick there, open pr for cherry picks, merge pr, open redmine, change it,etc Those are my personal 2 cents. I am opened to try this out, i just find that this new approach does not cover the cost of steps and time involved for making the git history cleaner and other things mentioned previously in my email 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 Fri, May 26, 2017 at 5:46 PM, David Davis wrote: > The current workflow is more than a two-step process. To expand all the > steps: > > 1. Decide what x.y-dev branch to open a PR against > 2. Open a PR against that branch > 3. After the PR is accepted, decide if you can actually still merge it > against the branch. This is necessary if for example, if I opened a PR > several months ago against 2.12-dev and it was since released. Then I have > to update the PR to point to 2.13-dev. > 4. Merge the PR > 5. Merge the x.y-dev branch to master locally > 6. Push the local changes directly to the upstream repository > > These steps 5 and 6 seem more error prone in that no one is reviewing > them. In the git cherry-pick workflow, having someone reviewing the > cherry-picks should reduce errors. Also, since you’re moving individual > commits instead of merging whole branches together, mistakes should be far > less disastrous if they do somehow occur. > > > David > > On Fri, May 26, 2017 at 10:29 AM, Ina Panova wrote: > >> -0 >> >> I don't know, i am personally not super excited about cherry-picking, too >> many involved resources imho in order to compensate crazy git history. >> >> 1. submit pr against master >> 2. decide into which branches it should be cherry-picked >> 3. submit PRs against those branches >> 4. Find someone to approve it( person can approve it right away or can >> forget), you then need again to bother the person to approve the PR, plus >> you also can forget about them. >> 5. If the bugfix/rfe/hotfix consists of several PRs, like platform and >> plugin, you need to take care of more PRs and be sure you opened all of >> them and merged all of them. >> 6. since the commit id changes, you need to keep track of the info >> externally. That means open Redmine and update it. >> >> >> With merge forward you just merge forward and need to take care of: >> >> 1. be sure you merged all PRs through all branches. >> 2. solve conflicts occasionally. >> >> >> The concern Brian brought up - that contributors do not know against >> which branch to submit PR. Instead of asking them to re-submit PR against >> different branch we can cherry pick this, >> We don't have that 'big traffic' of PRs from contributors and once in a >> while we can cherry pick if the PR was submitted against wrong branch. >> >> Another thing which was stated in the motivation was 'We've also seen >> some mistakes where branches are accidentally merged into other branches. " >> I guess we will have much higher chance to make a mistake or forget >> something between steps 1-6 mentioned for cherry-picking then steps 1-2 >> mentioned for merging forward. >> >> >> >> >> 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 Thu, May 25, 2017 at 6:49 PM, Sean Myers >> wrote: >> >>> On 05/25/2017 10:30 AM, Patrick Creech wrote: >>> > -1 >>> > >>> > While trying to come up with a decision on this topic, I googled "git >>> merge vs cherry-pick". The >>> > overwhelming ammount of search results were basically 'don't >>> cherry-pick!'. The page that I favored >>> > is [0]. It brings up some good points about loosing git's internal >>> tracking of commits
Re: [Pulp-dev] PUP-3: Proposal to change our git workflow
That's correct, we need not to forget to set the new branch as protected. 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 Fri, Jun 2, 2017 at 3:52 PM, David Davis wrote: > I like the first proposal of disabling pushes to all branches except > master. It’s simple and effective. My only question is when we create a new > branch, I’m guessing we’ll have to remember to set it to protected? > > Also, I am going to extend voting for another week until June 12 9pm UTC > to give us time to discuss alternatives. > > > David > > On Thu, Jun 1, 2017 at 4:36 PM, Michael Hrivnak > wrote: > >> There are definitely additional options to improve the current process. >> >> One way to prevent accidental merges is to just disable push to all >> branches except master. Merging to all other branches would happen via the >> "merge" button on a pull request. The normal workflow of merging to a >> x.y-dev branch and then to master would stay the same. For the less-common >> occasion when you need to merge stuff to more places, a quick PR is a small >> price to pay for seeing exactly what changes you're about to merge. I think >> we would not require review of such PRs. >> >> We could also run a check before doing a push. For example, client-side >> push hooks could easily ensure that the changes being pushed are >> acceptable. When I experimented with this in the past, I focused on the >> idea of a "forbidden commit". When creating 2.14-dev, we would identify the >> next commit on master that is not part of 2.14, and that becomes the >> "forbidden commit" for the 2.14-dev branch. Any simple automation, hook or >> not, can check if an incoming push contains the forbidden commit, and >> reject it if so. >> >> Another option is to use some other automation to do the merging and/or >> pushing for us, which is a common approach. That may be valuable with >> cherry-picking also. For example, maybe you can push a branch to your fork, >> but some other tool or service has to merge that into the main Pulp repo >> after validating it. >> >> In any case, there are options. It's definitely in the spirit of the PUP >> process to explore all the options, so I'm glad we're having this >> discussion. >> >> On Thu, Jun 1, 2017 at 3:36 PM, David Davis >> wrote: >> >>> Regarding improving our current git workflow, I do have a proposal on >>> the PUP-3 as an alternative: >>> >>> https://github.com/daviddavis/pups/blob/54907337a9211671cd90 >>> 8327fe3ba9b7dd93e750/pup-0003.md#merge-forward-less-often >>> >>> In it, we’d merge forward less often (e.g. once a week?) and do so via >>> PR. I think this solves one of the biggest problems we’ve seen with merging >>> forward: mistakes. However, it has some issues: >>> >>> 1. Who will perform the merge forward and how often will they perform it? >>> 2. The person performing the merge forward won’t have the specialized >>> knowledge to merge forward all the commits and fix any merge conflicts. >>> That said, they can work with the commit authors to do so and conflict >>> resolutions can be checked in the merge forward PR. >>> 3. Contributions (as raised by @ehelms and @bmbouter) still must go >>> against x.y-dev branches >>> >>> Maybe there are other alternatives as well? >>> >>> >>> David >>> >>> On Thu, Jun 1, 2017 at 2:34 PM, Patrick Creech >>> wrote: >>> >>>> On Thu, 2017-05-25 at 10:30 -0400, Patrick Creech wrote: >>>> > -1 >>>> >>>> I'm changing my vote to -0 to better reflect my initial intention of >>>> expressing my dissent, but not >>>> blocking the passage of this outright; as I do not believe I have >>>> enough knowledge and experience in >>>> this argument to do such. (I apologize for any frustration, I wasn't >>>> aware at the time my -1 would >>>> solely block this. I should have RTFM'ed). >>>> >>>> To follow up, I want to re-summarize my dissent here. >>>> >>>> I don't know all the ins and outs of this argument, and decided to keep >>>> it this way to better >>>> analyze the argument with minimal prior knowledge. This was to be able >>>> to come to this at voting >>>> time with fresh eyes, and have a layman'
Re: [Pulp-dev] Including the pulp-deb plugin in pulp 2.14
Mihai, both of the Tasks are added to the sprint, so they will be worked on asap. 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 Thu, Jun 8, 2017 at 3:53 PM, Mihai Ibanescu wrote: > Hi, > > We have had discussions on the IRC channel about adding pulp-deb (debian > support for pulp) in 2.14. > > I have filed this: > > https://pulp.plan.io/issues/2802 > > The unit tests pass against the master branch. I am in the process of > installing a server from master to validate that things do indeed work as > expected. > > I believe we need consensus that we should do it, and figure out what > needs to be done and who will do that. At the very least, python-debpkgr > would need to be packaged as an rpm and included in the yum repo (subtask > https://pulp.plan.io/issues/2803) > > Thank you! > Mihai > > ___ > 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] Docker Manifest list support in Pulp
There have been ongoing planning effort on how to add the support for Manifest lists into Pulp.[0][1] Please take a look at these 2 stories, they need grooming, provide feedback and suggestions in case I forgot or overlooked things. Once it is groomed I am going to start the work on this. [0] https://pulp.plan.io/issues/2384 [1] https://pulp.plan.io/issues/2385 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] PUP Process: "obvious consensus"
--> - We could score each vote (e.g. -2 for -1, -1 for -0, +1 for +0, +2 for +1) and then add up the votes. An obvious consensus could be something like a total of 0 or greater. >From my perspective it complicates the 'consensus' Why not following: if there is -1 from core dev, then not implement it and if majority of the votes are +/-0 then maybe revisit the PUP and talk again since the team is like 'meh, not really motivated'. For obvious consensus i think most of the votes should be +1, because it shows that team members are motivated and inspired by the forthcoming changes, otherwise i don't see sense in pushing forward is there is no boost from the very beginning. 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 Mon, Jun 12, 2017 at 4:13 PM, David Davis wrote: > I wanted to follow up after our meeting about what “obvious consensus" > means in PUP-1. As a refresher, here’s the relevant section in PUP-1: > > https://github.com/pulp/pups/blob/master/pup-0001.md#deciding > > <https://github.com/pulp/pups/blob/master/pup-0001.md#deciding>The term > about “obvious consensus” is vague—perhaps intentionally so. I’m wondering > if we want to clarify what it means. Given that we have numerical votes, we > could implement an algorithm for deciding what an obvious consensus means. > A couple examples: > > - At least X% of votes are +0 or +1 > - We could score each vote (e.g. -2 for -1, -1 for -0, +1 for +0, +2 for > +1) and then add up the votes. An obvious consensus could be something like > a total of 0 or greater. > > The other conditions (e.g. no -1 votes from pulp core devs) should still > apply I think. So even if there is an obvious consensus, the PUP wouldn’t > necessarily be approved. > > Thoughts? > > David > > ___ > 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] PUP Process: "obvious consensus"
Having at least one +1 is not impartial approach just because the developer who , as you said, found the time for the research and writing down the proposal obviously will vote as +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 Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald wrote: > This reminds me of the concept of a "Do-ocracy". > > If developers take the time to research and write up a proposal, they have > "done". It seems completely reasonable to default to the opinion of the > people that cared enough to do the work. If it isn't the right decision, > then someone must actively block it, simple as that. > > I think the rule should be "PUP passes if we have at least one +1 and no > -1s". > > ___ > 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] PUP Process: "obvious consensus"
And if we would remove all 'shades of grey' and go back just to +1 and -1 where people would need to make their mind up *clearly* which would lead stronger arguments of doing or not doing this. 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, Jun 13, 2017 at 5:30 PM, David Davis wrote: > In this model of where only -1 votes stop the PUP from passing, wouldn’t > it mean that there needn't be any consensus at all? In other words we could > effectively strike the language about consensus from PUP-1. This model > makes me worried that people other than those casting -1 won’t bother to > vote or participate since only -1 votes matter. > > I personally like the idea of having at least 30% that are +1 or +0. This > means that enough -0 votes can still block the vote, and also +0 votes goes > towards helping the PUP pass. Thus +0 and -0 would both matter. I think > this is a good compromise between the extremes of "broad buy-in" and > "default to change." > > > David > > On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse > wrote: > >> We should (I thought we did) adopt a process that favors change and does >> not have a "broad buy-in requirement". Any change that doesn't harm the >> project should be allowed without broad buy-in. This empowers even a single >> individual to enact change. This makes Pulp better because: >> >> * Everyone is empowered. A single individual can have a meaningful impact. >> * Anyone can stop an idea that will negatively affect the project or >> community via veto. >> * We avoid the tyranny of the majority [0] or supermajority. >> * It avoids politics. If we start averaging, or counting votes >> for/against in an offsetting way, there will be politics. Counting votes >> for/against will create inequality because influential project members will >> likely see their ideas adopted but others won't. Having a "default to >> change and any core dev can veto" approach creates equality. >> >> Regarding how "obvious consensus" works with the "veto-or-it-passes" >> model, if there are zero -1 votes cast, that means no one wanted to stop >> the process. If no wants to stop it, and at least one is for it, then the >> most sensible thing to do is to pass it. Since someone took time to write >> the PUP there is obviously someone giving it a +1. If one person really >> wants to go to place X for dinner (aka a +1), and there are no >> counterproposals (aka a -1 with a suggestion) or strong preferences against >> (aka -0 or +0) then the group will probably go to place X for dinner by way >> of "obvious consensus". >> >> In summary, adopting a "default to accept or reject with even a single >> veto" system creates an equal system. A system where, a single individual >> can make a difference, and anyone can stop a bad idea from occurring. To >> @mhrivnak's point about a change not meeting a broad range of needs, I >> expect -1's to be cast in those cases, so this system is still very safe in >> terms of protecting the projects needs and interests. >> >> [0]: https://en.wikipedia.org/wiki/Tyranny_of_the_majority >> >> -Brian >> >> On Mon, Jun 12, 2017 at 7:53 PM, David Davis >> wrote: >> >>> Not sure this is true. I actually abstained from voting on PUP-3 because >>> I was somewhere between a +0 and a -0. >>> >>> >>> David >>> >>> On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova wrote: >>> >>>> Having at least one +1 is not impartial approach just because the >>>> developer who , as you said, found the time for the research and writing >>>> down the proposal obviously will vote as +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 Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald >>>> wrote: >>>> >>>>> This reminds me of the concept of a "Do-ocracy". >>>>> >>>>> If developers take the time to research and write up a proposal, they >>>>> have "done". It seems completely r
Re: [Pulp-dev] PUP Process: "obvious consensus"
Daniel, a person has *always* its own opinion, +/-1 just makes him more to think, or think twice or encourage the person to go and read and google if there is not much or knowledge or tech background. Another example, i personally voted as -0, just because i don't want to stay in the way, so i am 'going with the flow'. If there would be just +/- 1, i would vote as -1, this will make me think more and provide stronger arguments, instead of putting a relaxed +/- 0 just because it is a safer option and you don't need to mess the water and be in the middle of the fire :) Zero is always and easy path :) ---- 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 Thu, Jun 15, 2017 at 10:42 PM, Daniel Alley wrote: > 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. Those people are put in the position of either abstaining, > or "going with the flow", and the very act of deciding "yes, I am going to > vote for this" can suppress your reservations about something. > > The consensus decision making document Brian linked seems like a good > model, although it seems to make a distinction between a reservation, a > comment, and a "vote against" which is poorly explained. I'll also note > that under that model, +0/-0 are effectively "abstain with comment". And > maybe that's fine, but to go back to my point earlier (which Michael did an > excellent job of expanding on), we should consider that a widespread > opinion of "(-0) I'm not voting no but I'm still concerned about XYZ" is > problematic. > > On Thu, Jun 15, 2017 at 3:20 PM, Brian Bouterse > wrote: > >> I asked about some of these governance questions to a group of community >> managers from several open source projects that I meet with weekly. They >> said that if you don't have a BDFL (Pulp does not) the other very popular >> model is the lazy consensus model. I think lazy consensus is the spirit of >> pup1. I asked for some examples and they pointed me at the CentOS >> governance model [0][1]. >> >> Also @daviddavis and I were talking and codifying the problem as what >> value should X be if X are the number of +1s required to pass a decision >> with zero -1 votes (vetos)? The CentOS governance model sets X = 0 by >> stating "There is no minimum +1 vote requirement". I'm also advocating for >> X=0 for the reasons I wrote in my earlier email. Practically speaking, I >> don't think an X=1, or X=2 will prevent many proposals that would have also >> passed with X=0. >> >> Regardless of the X value, we should continue the discussion so we can >> arrive at a decision on both pup1 and pup3. Thanks for continuing the convo. >> >> [0]: https://www.centos.org/about/governance/appendix-glossary/#c >> onsensus-decision-making >> [1]: https://www.centos.org/about/governance/voting/ >> >> -Brian >> >> >> On Tue, Jun 13, 2017 at 11:46 AM, Ina Panova wrote: >> >>> And if we would remove all 'shades of grey' and go back just to +1 and >>> -1 where people would need to make their mind up *clearly* which would lead >>> stronger arguments of doing or not doing this. >>> >>> >>> >>> >>> 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, Jun 13, 2017 at 5:30 PM, David Davis >>> wrote: >>> >>>> In this model of where only -1 votes stop the PUP from passing, >>>> wouldn’t it mean that there needn't be any consensus at all? In other words >>>> we could effectively strike the language about consensus from PUP-1. This >>>> model makes me worried that people other than those casting -1 won’t bother >>>> to vote or participate since only -1 votes matter. >>>> >>>> I personally like the idea of having at least 30% that are +1 or +0. >>>> This means that enough -0 votes can still block the vote, and also +0 votes >>>> goes towards helping the PUP pass. Thus +0 and -0 would both matter. I >>>> think this is a good compromise between th
Re: [Pulp-dev] PUP Process: "obvious consensus"
Another model to consider is to look how downstream kernel guys accept patches - it should have at least 3 acks and none nack. 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 Fri, Jun 16, 2017 at 11:48 AM, Ina Panova wrote: > > Daniel, a person has *always* its own opinion, +/-1 just makes him more to > think, or think twice or encourage the person to go and read and google if > there is not much or knowledge or tech background. > Another example, i personally voted as -0, just because i don't want to > stay in the way, so i am 'going with the flow'. If there would be just +/- > 1, i would vote as -1, this will make me think more and provide stronger > arguments, instead of putting a relaxed +/- 0 just because it is a safer > option and you don't need to mess the water and be in the middle of the > fire :) Zero is always and easy path :) > > > > > 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 Thu, Jun 15, 2017 at 10:42 PM, Daniel Alley wrote: > >> 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. Those people are put in the position of either abstaining, >> or "going with the flow", and the very act of deciding "yes, I am going to >> vote for this" can suppress your reservations about something. >> >> The consensus decision making document Brian linked seems like a good >> model, although it seems to make a distinction between a reservation, a >> comment, and a "vote against" which is poorly explained. I'll also note >> that under that model, +0/-0 are effectively "abstain with comment". And >> maybe that's fine, but to go back to my point earlier (which Michael did an >> excellent job of expanding on), we should consider that a widespread >> opinion of "(-0) I'm not voting no but I'm still concerned about XYZ" is >> problematic. >> >> On Thu, Jun 15, 2017 at 3:20 PM, Brian Bouterse >> wrote: >> >>> I asked about some of these governance questions to a group of community >>> managers from several open source projects that I meet with weekly. They >>> said that if you don't have a BDFL (Pulp does not) the other very popular >>> model is the lazy consensus model. I think lazy consensus is the spirit of >>> pup1. I asked for some examples and they pointed me at the CentOS >>> governance model [0][1]. >>> >>> Also @daviddavis and I were talking and codifying the problem as what >>> value should X be if X are the number of +1s required to pass a decision >>> with zero -1 votes (vetos)? The CentOS governance model sets X = 0 by >>> stating "There is no minimum +1 vote requirement". I'm also advocating for >>> X=0 for the reasons I wrote in my earlier email. Practically speaking, I >>> don't think an X=1, or X=2 will prevent many proposals that would have also >>> passed with X=0. >>> >>> Regardless of the X value, we should continue the discussion so we can >>> arrive at a decision on both pup1 and pup3. Thanks for continuing the convo. >>> >>> [0]: https://www.centos.org/about/governance/appendix-glossary/#c >>> onsensus-decision-making >>> [1]: https://www.centos.org/about/governance/voting/ >>> >>> -Brian >>> >>> >>> On Tue, Jun 13, 2017 at 11:46 AM, Ina Panova wrote: >>> >>>> And if we would remove all 'shades of grey' and go back just to +1 and >>>> -1 where people would need to make their mind up *clearly* which would lead >>>> stronger arguments of doing or not doing this. >>>> >>>> >>>> >>>> >>>> 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, Jun 13, 2017 at 5:30 PM, David Davis >>>> wrote: >>>> >>>>> In this model of where only
Re: [Pulp-dev] PUP Process: "obvious consensus"
+1. Thanks Brian for all your effort and commitment. 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 Thu, Aug 10, 2017 at 9:58 PM, Daniel Alley wrote: > +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, Aug 10, 2017 at 5:33 AM, Brian Bouterse >>>> wrote: >>>> >>>>> A small language clarification was pushed based on feedback via >>>>> comment: https://github.com/bmbouter/pups/commit/f5b7282b2d2e369b90f1 >>>>> 49e4cc25226bb093171b >>>>> >>>>> Voting is open for the PUP1 revisions. Normally the voting window is >>>>> longer, but this topic has been discussed for a long time. The core team >>>>> earlier this week decided a shorter voting window was appropriate in this >>>>> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise >>>>> any concerns around this process. Otherwise, please send in votes via this >>>>> thread. I'll cast mine now. >>>>> >>>>> +1 to passing the pup1 revisions. >>>>> >>>>> Thanks to everyone who has contributed comments and energy into this >>>>> topic. >>>>> >>>>> -Brian >>>>> >>>>> >>>>> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse >>>>> wrote: >>>>> >>>>>> After some in-person convo, the core team wants to open PUP1 revision >>>>>> voting on Wednesday and close it at midnight UTC on Friday Aug 11th. We >>>>>> will pass/not-pass according this the voting outlined in PUP1 itself (a >>>>>> variation on self-hosting [0]). We also want to ask that any comments on >>>>>> the PUP1 revisions by posted before midnight UTC tomorrow Aug 8th. >>>>>> >>>>>> [0]: https://en.wikipedia.org/wiki/Self-hosting >>>>>> >>>>>> -Brian >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse >>>>>> wrote: >>>>>> >>>>>>> I've pushed a new commit [3] to the PR. It includes the following >>>>>>> changes. Please review and comment. If there are any major/blocking >>>>>>> concerns about adopting this please raise them. Once the PUP1 revisions >>>>>>> are >>>>>>> resolved, PUP2 can also be accepted based on the votes it had >>>>>>> previously. >>>>>>> >>>>>>> * Adjusts the +1 approvals to come from anywhere, not just core devs >>>>>>> * Explicitly allows for votes to be recast >>>>>>> * Explains two examples where votes are recast. One is based on many >>>>>>> other -1 votes being cast. The other is when concerns are addressed and >>>>>>> a >>>>>>> -1 vote is recast. >>>>>>> >>>>>>> [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26 >>>>>>> e1d97ea6fe4aa570066db768 >>>>>>> >>>>>>> -Brian >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse >>>>>> > wrote: >>>>>>> >>>>>>>> From the discussion on the call last week, I've made some revisions >>>>>>>> [2] to explore the idea of having a lazy consensus model. Comments, >>>>>>>> ideas, >>>>>>>> concerns are welcome either on the PR or via this thread. >>>>>>>> >>>>>>>> As @mhrivnak pointed out, the adoption of a lazy consensus model is >>>>>>>> meaningfully different than the language we have in pup1 today which >>>>>>>> uses >>>>>>>> "obvious consensus". I want to be up front about tha
[Pulp-dev] do we have master branch screwed up?
Today i accidentally stumbled across some inconsistencies on pulp/pulp master branch while looking into some Nectar related stuff 1) master branch has the commit ab277d4f9c11cb539ed82236881621962b8ef721 in the git history 2) git blame or git history of the file itself does not show anything, the code change is not on master. 3) 2.-14dev branch which was branched from master does contains the commit and the code changes. Same for f36a5b96ad60d594cc875faf0ce395d80d63ac75 which is the fix for #2783, i cannot see the code changes on master branch. Is there any black magic happening again? 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Reconsidering PUP-3
+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 Mon, Oct 2, 2017 at 2:45 PM, Daniel Alley wrote: > +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 create a more stable project overall. >>> >>> On Fri, Sep 29, 2017 at 9:53 AM, Dennis Kliban >>> wrote: >>> >>>> +1 >>>> >>>> On Fri, Sep 29, 2017 at 9:17 AM, David Davis >>>> wrote: >>>> >>>>> I went back and looked at PUP-3 and it does lay out some of the items >>>>> @pcreech mentions although at a higher, more general level. I’ll leave the >>>>> document as is unless someone disagrees. >>>>> >>>>> With that in mind, let's go ahead and vote on PUP-3. We’ll end the >>>>> voting on October 8th which is about 10 days away. >>>>> >>>>> To refresh everyone’s memory, voting is outlined in PUP-1: >>>>> >>>>> https://github.com/pulp/pups/blob/master/pup-0001.md#voting >>>>> >>>>> And here’s the PUP in question: >>>>> >>>>> https://github.com/daviddavis/pups/blob/pup3/pup-0003.md >>>>> >>>>> Please respond to this thread with your vote or any comments/questions. >>>>> >>>>> >>>>> David >>>>> >>>>> On Thu, Sep 28, 2017 at 12:15 PM, Brian Bouterse >>>>> wrote: >>>>> >>>>>> Thanks @pcreech for all the comments. I also believe that switching >>>>>> to a cherry-picking model will provide many benefits. >>>>>> >>>>>> As a general FYI, the way PUP-3 is written, it allows us to adopt it >>>>>> (assuming it passes at vote) and then figure out how to roll it out later >>>>>> in coordination w/ release engineering. >>>>>> >>>>>> @daviddavis, should we start casting votes or should we wait for you >>>>>> to declare it open after maybe pushing an update? >>>>>> >>>>>> Thanks! >>>>>> Brian >>>>>> >>>>>> On Mon, Sep 25, 2017 at 1:38 PM, David Davis >>>>>> wrote: >>>>>> >>>>>>> Patrick, >>>>>>> >>>>>>> Thanks for the feedback. I’d like to update PUP-3 in the next couple >>>>>>> days with the pain points you mention. >>>>>>> >>>>>>> Also, I’d love the idea of having some tooling that tells us exactly >>>>>>> which commits to cherry pick into which release branch. I think we >>>>>>> should >>>>>>> have this in place before we switch to cherry-picking if we decide to go >>>>>>> that route. >>>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On Fri, Sep 22, 2017 at 1:56 PM, Patrick Creech >>>>>>> wrote: >>>>>>> >>>>>>>> Since I was one of the early voices against cherrypicking during >>>>>>>> the initial vote, I figured I'd send this e-mail along with some points >>>>>>>> that have helped me be in favor of cherry picking before voting >>>>>>>> starts. >>>>>>>> >>>>>>>> In taking over the release engineering process, I have gained some >>>>>>>> perspective on our current situation and have found Cherrypicking to >>>>>>>> be an >>>>>>>> enticing concept for pulp. Most notably, these are the >>>>>>>> things I ran into during the release process for 2.13.4 that caused >>>>>>>> some headaches and frustrations. >>>>>>>> >>>>>>>> Firstly, we had an issue come up with the Pulp Docker 2 line that >>>>>>>> does not exist with the new Pulp Docker 3 line. Dockerhub V2 Schema2 >>>>>>&g
Re: [Pulp-dev] De-duplicating Demo Content
I think it is important to keep 2 sections: 1) Community updates - which would tackle community contributions and everything related to the spread of our project awareness. 2) Release updates- which would take care of RFEs, bugfixes, issues, releases, future plans we are heading to, etc Maybe as a starting point we should define as a team what we expect to have in those 2 sections, since it might turn out everyone would have its different expectations. 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 Fri, Sep 29, 2017 at 9:48 PM, Brian Bouterse wrote: > I've thought about this some more and given my role as the community > manager, I would like to host the demos and deliver the content I have > planned. This is what I see from other projects like Foreman. This content > regularly conflicts with the "State of Pulp" content. The YouTube live > demos are something I started for Pulp, and something I would like to stay > involved with. > > I want to go back to @asmacdo's idea of renaming the State of Pulp to > "Release Updates". You're welcome to deliver that or someone who does the > releases themselves would be good. Some feedback on this change would be > great. > > Thanks, > Brian > > > > On Fri, Sep 29, 2017 at 2:19 PM, Michael Hrivnak > wrote: > >> Sure, I'd be happy to do that. I do think there's plenty of room for a >> "What's happening with the technology" segment and a "What else is going on >> in the community" segment if you'd like to keep doing highlights there, but >> otherwise I am happy to take care of it. >> >> On Fri, Sep 29, 2017 at 9:43 AM, Brian Bouterse >> wrote: >> >>> The content you are describing is the same content I usually plan to >>> cover also. Then on the day-of we realize that we have the same content. I >>> think this is the root of the issue that is causing me to raise this >>> problem to begin with. Switching the name won't resolve it. >>> >>> In looking at a community like Forman for example, Greg, the community >>> manager, runs the demos and coordinates the content updates that you are >>> describing. I'm wondering why Pulp is doing something different. >>> >>> It sounds like you want to deliver all of that content. That is ok with >>> me if you are also willing to run/coordinate/post the demos. Would that be >>> a way to solve this? We have docs here [0] about how to do that. Feedback >>> about this idea would be great. >>> >>> [0]: https://pulp.plan.io/projects/pulp/wiki/Sprint_Demo_Notes >>> >>> >>> >>> >>> On Thu, Sep 28, 2017 at 3:04 PM, Michael Hrivnak >>> wrote: >>> >>>> I'm happy to change the name of my section to something other than >>>> "State of Pulp", which isn't very descriptive. I want it to continue >>>> focusing on what's happening with the technology, such as releases, new >>>> initiatives getting started (new plugin for example), specific current >>>> problems (coredump on F26 for example), highlighting areas of investigation >>>> or planning (like when we were wrestling with how to support multi-arch >>>> container images), deprecations (no more EL6 for example), etc. "Tech >>>> Update" would be fine, or something similar. >>>> >>>> On Thu, Sep 28, 2017 at 2:02 PM, Austin Macdonald >>>> wrote: >>>> >>>>> +1 to "Release Updates" because it doesn't make an artificial >>>>> distinction between work done by Red Hat employees and work done by the >>>>> community. >>>>> >>>>> On Thu, Sep 28, 2017 at 10:38 AM, Brian Bouterse >>>>> wrote: >>>>> >>>>>> During the sprint demos there are two sections which regularly (if >>>>>> not always) present redundant content: the State of Pulp update, and the >>>>>> Community Update. We need to combine or redefine these parts of our demos >>>>>> to not be redundant or compete for content to present in each section. >>>>>> Today the content was 100% redundant to the point where I entirely >>>>>> skipped >>>>>> the community update. >>>>>> >>>>>> Please send ideas or comments. Here are two options I can think of: >>>>>&
Re: [Pulp-dev] REST API Milestone/alpha?
@Austin, do we want to update the etherpad since jwt work was merged? 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 Mon, Oct 9, 2017 at 2:34 PM, Austin Macdonald wrote: > Luckily, I wrote this as a text file. > > http://pad-theforeman.rhcloud.com/p/Pulp3_REST_API > > On Mon, Oct 9, 2017 at 8:19 AM, Brian Bouterse > wrote: > >> That server was migrated. Most urls should still exist but now its over >> here: http://pad-theforeman.rhcloud.com/ >> >> This etherpad I think is lost. Any edits from Oct 2 - Oct 6th were lost >> in the transition. I lost a bunch of stuff in other etherpads during that >> time too. >> >> -Brian >> >> >> On Sun, Oct 8, 2017 at 11:59 PM, Michael Hrivnak >> wrote: >> >>> This etherpad deployment has been returning 503s for a few days. Any >>> chance you could easily re-generate that list of endpoints with methods and >>> put it somewhere else? >>> >>> On Thu, Oct 5, 2017 at 12:49 PM, Austin Macdonald >>> wrote: >>> >>>> I think we are ready to start considering an alpha for our REST API. >>>> (REST API and plugin API are versioned separately.) I've started a list of >>>> all our endpoints along with accepted methods and the expected responses. I >>>> hope this list will be useful for QE as well. >>>> >>>> http://pad-katello.rhcloud.com/p/pulp3_REST_API >>>> >>>> The questions that I have: >>>> >>>>1. Which other endpoints do we need to add before an alpha of the >>>>REST API? (Publications?) >>>>2. Are we happy with the general structure? >>>>3. What else should we do before we call it an alpha? >>>> >>>> >>> >>> >>> -- >>> >>> Michael Hrivnak >>> >>> Principal Software Engineer, RHCE >>> >>> Red Hat >>> >> >> > > ___ > 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] Task tagging in Pulp 3
I feel a bit nervous to replace the TaskTag model with the direct relationship with the repository. I understand that all the tasks we plan to trigger are against/or related to a repo, but i just want to be prepared to unforeseen future changes where the TaskRepository would not get us in a dead-end situation. > Do we really need to allow users to search tasks by a resource/repo at all? I think this is useful and we should keep this. 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 Mon, Nov 6, 2017 at 8:17 PM, David Davis wrote: > Originally I scheduled a meeting for tomorrow but on second thought, I > figured a pulp-dev thread would be more inclusive than a meeting. I hope to > get this resolved by the end of this week and if not then maybe we can have > a meeting. > > This is to design out the replacement of task tags in Pulp 3. I’ve got > feedback from a few other developers in terms of how to do that so I wrote > up a sort of outline of the problem and two possible proposals. Looking for > feedback/questions/etc on what people prefer. > > > Background > --- > > In Pulp 2, tasks have tags that either provide a task name/description or > info on what resources a task acts on. Tasks also have reserved resources, > which provide a way for tasks to lock a particular resource. > > In Pulp 3, we have models TaskTag and ReservedResource[0]. Tasks are > associated with the resources they work on via TaskTag. If a resource is > locked, a ReservedResource record is created in the db and then removed > from the db once the resource is unlocked. > > > Problem > --- > > The task tag model doesn't really fit Pulp 3. It's perhaps too generic and > totally unnecessary (see Proposal 1), or it could be redesigned to > accomodate other things (see Proposal 2). > > Also, we need to support created resources (e.g. publications) with tasks. > Refactoring task tags might provide an opportunity to do so. > > > User stories > --- > > As an authenticated user, I can see what resource(s) a task acted on. > As an authenticated user, I can search for a tasks based on what resource > they acted on. > > > Proposal 1 > --- > > Since tags and reserved resources in Pulp 3 will only store information > about a particular repository (not 100% sure here), it should be possible > to simplify the data model. We could ditch both TaskTag and > ReservedResource models and just have a direct relationship between Tasks > and Repositories (e.g. TaskRepository). This model could also have some > sort of field to indicate whether a particular field is locked (e.g. > is_locked). Unlike ReservedResource, this relationship would be > persisted—only the is_locked field would be updated when a task is done. > > > Proposal 2 > --- > > We could keep the TaskTag relationship (perhaps even rename it to > TaskResource) and we could add a field to indicate the nature of the > relationship between task and resource (e.g. created, updated, etc). This > field could not only capture what TaskTag is currently used for but also > stuff like created resources (e.g. publications). We could also have a > field to indicate which task resources are locked (e.g. is_locked). > > This would be useful for https://pulp.plan.io/issues/3033. > > > Questions > --- > > - What proposal do we want to adopt? > - When do we need to address these changes? > - Do we really need to allow users to search tasks by a resource/repo at > all? > > > [0] https://git.io/vF8iH > > David > > ___ > 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] writing new search plugin for crane
Hi Tom, Given the current state i am not sure i would be able to provide you a straightforward answer which would be yes or no, since we did not start yet to plan in details that particular part of Pulp3. What i can suggest is - open a Story on our tracker where deliverables will be written down and further discussed with the team in the written manner. This approach will minimize the probability of implementing something which may not work later. Thank you. 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 Wed, Nov 15, 2017 at 12:27 AM, Tom McKay wrote: > I was thinking of writing a crane search plugin (like solr) that uses > foreman as the search source. If I write it against pulp-2, will it still > work with pulp-3? > > ___ > 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] Proposing dropping old fedora releases for 2.15
+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 wrote: > Sounds good. Our policy has been to stop building for and supporting a > Fedora release when Fedora stops supporting that release. > > On Tue, Nov 14, 2017 at 10:16 AM, Patrick Creech > wrote: > >> With Fedora 27 being released today, I would like to propose dropping >> Fedora 24 at this time, with >> dropping Fedora 25 shortly after 2.15.0 is released. >> >> Fedora only supports Current and Current-1 releases, with Current-2 >> support dropping one month after >> the release of Current. >> >> I will be working on adding Fedora 27 support to our releases, but given >> current release engineering >> priorities, I am not confident this will land by 2.15.0 >> >> Thanks >> Patrick >> >> >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat > > ___ > 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] New Docs for Demo Presenters
That all looks good, i would just suggest not to limit the presentation by 4 minutes. Maybe omitting this would be better, you never know what kind of feature will be demoed. 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 Fri, Nov 10, 2017 at 8:02 PM, Brian Bouterse wrote: > Some of the presenters had conflicts today so they sent videos. I've also > heard that presenters like recording to get their content right with a few > takes. > > Aside from that, I'm going to streamline the presentation some so there is > less figiting between videos. > > On Thu, Nov 9, 2017 at 2:53 PM, Bryan Kearney wrote: > >> On 11/09/2017 11:08 AM, Brian Bouterse wrote: >> > I wrote a page on the wiki outlining some docs for demo presenters to >> > use. It includes sections on video recording recommendations and on >> > presenting live. PSA about this as a resource: >> > >> > https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes >> > <https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes> >> > >> > Thanks to all the demo presenters! >> > >> >> Why were so many of the demos videos today? Was it holiday/pto issues? I >> personally dont mind seeing things break live, that lets me know it is >> real code :) >> >> -- bk >> >> >> >> >> > > ___ > 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] Voting for PUP 4: Code of Conduct
+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, Dec 12, 2017 at 8:32 PM, Austin Macdonald wrote: > +1 > > On Tue, Dec 12, 2017 at 2:01 PM, Bihan Zhang wrote: > >> +1 >> >> On Tue, Dec 12, 2017 at 1:45 PM, David Davis >> wrote: >> >>> +1 >>> >>> >>> David >>> >>> On Tue, Dec 12, 2017 at 1:39 PM, Daniel Alley wrote: >>> >>>> +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/pups/blob/master/pup-0001.md#voting >>>>> >>>>> And here’s the PUP in question: >>>>> >>>>> https://github.com/dkliban/pups/blob/pup4/pup-0004.md >>>>> >>>>> Please respond to this thread with your vote or any >>>>> comments/questions. >>>>> >>>>> >>>>> >>>>> >>>>> [0] https://www.redhat.com/archives/pulp-dev/2017-November/msg00 >>>>> 110.html >>>>> >>>>> ___ >>>>> 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 >>> >>> >> >> ___ >> 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
Re: [Pulp-dev] docker repo RFEs
Right now we sync all tags by first querying the available tag list from the repo. Lazy sync you can expect in pulp3 we did not plan to lazily fetch docker content in pulp2( from pure design perspective). There is no mirror on sync in docker plugin. Would be good to report these RFEs for pulp3 in case there are not opened yet. Thank you! 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 Wed, Jan 31, 2018 at 9:11 PM, Tom McKay wrote: > A couple foreman RFEs continue to pop up around managing docker tags in > repos when syncing. The case for them centers around cleaning up storage > and preventing stale manifests and tags from being accessible. > > The first is a request to be able to create tag filters for sync. This > would let the user specify one or more filters to include or exclude tags > by regex. > > This naturally leads into having a "lazy sync" mode for docker repos > since, presumably, to only pull manifests for a subset of tags the list of > tags would need to be fetched first. (Like the output of 'skopeo inspect'.) > > And finally, this would lead to having a "mirror on sync" where after > syncing only the tags and associated manifests would be in the repo, > nothing from previous syncs that no longer matched. > > Do any of these features exist already in current pulp-2.15+? > > ___ > 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] 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 t
Re: [Pulp-dev] possible to upload container image blobs?
Hello Tom, No it is not possible to upload individual blobs, the only way how to get image manifest schema1 or schema2 for now is to use skopeo copy and tar the output. For more info please checks the docs and recipes [0]. In addition it is not safe to upload the components of the tar file individually, because if you upload just a single json file without blobs, it ends up to be a corrupted image manifest. In case you'd upload blob by blob, you also risk to end up with corrupted image manifest in case you'd forget some blob to upload. Let me know in case you have more questions. [0] https://github.com/pulp/pulp_docker/blob/master/docs/user-guide/recipes.rst#upload-v2-schema-2-and-schema-1-images-to-pulp 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 Wed, Mar 7, 2018 at 10:06 PM, Tom McKay wrote: > I know I can upload a skopeo copy tar file but is it possible to upload > individual blobs directly? Or upload the components of the tar file > individually? I am on pulp-2.15.2. > > ___ > 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] possible to upload container image blobs?
We had an irc chat and a call, the questions where addressed with a possible solution. 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 Thu, Mar 8, 2018 at 4:35 AM, Tom McKay wrote: > resending since mobile email triggered approval... > > i have created an api endpoint in foreman for docker push and from there > will be calling pulp. don’t worry about “safe” since there is no manual > aspect. if pulp doesn’t support it, i will work around. if it us possible, > please tell me how. thanks!! > > In my proof-of-concept foreman work, I have docker login working with RBAC > for limiting scope of images for docker pull. I also added the /v2/_catalog > and /v2/$repo/tags/list since those are very useful for integrating with > tools like openshift. If I can get docker push / skopeo working, that would > be a huge win. > > I understand that these topics are not a priority but any suggestions on > how to make this work with existing pulp-2 code would be very welcome. > > > On Wed, Mar 7, 2018 at 9:31 PM, Mihai Ibanescu > wrote: > >> See https://pulp.plan.io/issues/3231 as well. >> >> On Wed, Mar 7, 2018 at 5:25 PM, Ina Panova wrote: >> >>> Hello Tom, >>> >>> No it is not possible to upload individual blobs, the only way how to >>> get image manifest schema1 or schema2 for now is to use skopeo copy and tar >>> the output. >>> For more info please checks the docs and recipes [0]. >>> >>> In addition it is not safe to upload the components of the tar file >>> individually, because if you upload just a single json file without blobs, >>> it ends up to be a corrupted image manifest. In case you'd upload blob by >>> blob, you also risk to end up with corrupted image manifest in case you'd >>> forget some blob to upload. >>> >>> Let me know in case you have more questions. >>> >>> [0] https://github.com/pulp/pulp_docker/blob/master/docs/user-gu >>> ide/recipes.rst#upload-v2-schema-2-and-schema-1-images-to-pulp >>> >>> >>> >>> >>> 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 Wed, Mar 7, 2018 at 10:06 PM, Tom McKay >>> wrote: >>> >>>> I know I can upload a skopeo copy tar file but is it possible to upload >>>> individual blobs directly? Or upload the components of the tar file >>>> individually? I am on pulp-2.15.2. >>>> >>>> ___ >>>> 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 > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Removing a few sprint items?
#2988 was automatically moved to srpint 34 because it was in assigned state and the assignee was not present on the planning so we moved it forward and let the decision up to the assignee whether to continue to work on this or drop form the sprint. Since you're just unassigned it i think we can drop this issue from the sprint. 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 Wed, Mar 14, 2018 at 5:03 PM, Brian Bouterse wrote: > I didn't get a chance until now to look at the sprint 34 items in a > detailed way. I want us to consider removing three of them from the sprint. > The reasoning is that these areas of work are not part of the pulp3 core > beta deliverables. > > Exception when raising a user-Defined Exception that has a custom __init__ > signature [0] > > Create and publish an ansible role to install apache and configure it for > pulp [1] <--- note the code already support Apache and nginx > > Distribute Pulp with Pulp [2] > > Can others give input on this decision? > > [0]: https://pulp.plan.io/issues/2988 > [1]: https://pulp.plan.io/issues/2921 > [2]: https://pulp.plan.io/issues/2325 > > Thank you! > Brian > > ___ > 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] Port Pulp3 to use RQ
+1 what said dalley. Whatever we'd decide to replace celery with, should not go before beta 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=Qmhc7tZ6ElQ ---- 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 20, 2018 at 9:52 PM, Daniel Alley wrote: > Another option is TaskTiger (https://github.com/closeio/tasktiger) which > really hooked me with their tagline. > > But I really just don't see how we could pull this off responsibly in the > next month (or even 3 months). Assuming the functionality gaps can be > worked out, it then becomes a question 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, 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 have some concerns about the gaps between Celery and RQ, >> and I don't think that changing Pulp to use RQ would be as trivial as we >> hope. >> >> I'll start with the benefits of RQ, from what I've read so far. >> >> >>- It has task prioritization that *actually works*, which would help >>resolve the issue where reserved resource work tasks get choked out by >>less important tasks like applicability. The officially recommended >>solution that Celery provides for this is... have dedicated workers for >>each priority level. Not ideal. >>- The documentation is pretty good, from what I can tell. The Celery >>documentation is usually OK but sometimes... lacking. >>- RQ is a lot more straightforwards and less complex to use, from >>what I can tell >> >> But, problems: >> >>- RQ does not support revoking tasks. If you send the worker a >>SIGINT, it will finish the task and then stop processing new ones. If you >>send the worker SIGKILL, it will stop immediately, but I don't think it >>gracefully handles this circumstance. >> - People have rolled their own revoke functionality, but we should >> really look at this. >>- When a RQ task fails, it does not provide a mechanism to >>automatically run a piece of code. It puts the task on a "failed" queue >>and the python handle for it will have is_failed set to True. this means >>we would have to redesign how failed tasks are cleaned up >>- I have no idea what happens when RQ loses connection to Redis, I >>couldn't find that info anywhere. Celery (in theory, at least, reality is >>mushy) will try to reconnect to the broker. >>- I have no idea how well RQ deals with persistence >> >> Also... we have shaped large parts of our API around what Celery does. >> Undoing this would be very... nontrivial and I don't think it is possible >> before the beta date, and definitely not if we want to guarantee some level >> of stability. >> >> I'll keep looking but as much as I despise working with Celery I don't >> think we can make this move without a lot more research to make sure these >> problems are solvable. >> >> On Tue, Mar 20, 2018 at 4:03 PM, Austin Macdonald >> wrote: >> >>> Not being familiar with RQ, I have questions (but no opinion). >>> >>> Will we also be replacing RabbitMQ with Redis? >>> Does anyone on the team have experience with RQ? In production? >>> How well does RQ scale? >>> Is RQ's use of `pickle` a problem? https://pulp.plan.io/issues/23 >>> RQ doesn't work on Windows. Is that a problem? (jk) >>> >>> >>> On Tue, Mar 20, 2018 at 3:35 PM, Brian Bouterse >>> wrote: >>> >>>> Motivation: >>>> 1. Celery causes many bugs and issues for Pulp2 and 3 users and there >>>> is no end in sight. >>>> >>>> 2. The Pulp core team spends a lot of effort fixing Celery bugs. It's >>>> often times just us doing it with little or no assistance from the upstream >>>> communities. It's across 4 projects: celery, kombu, billiard, and pyamqp. >
Re: [Pulp-dev] let's rename RepositoryVersion to Snapshot
+1 to keep RepositoryVersion. I also do not like the fact that it is quite long, that's why i do like the Snapshot, but thinking more of what snapshot is - is something that *you* need to trigger and it is not triggered automatically. I'd say, we are working with repository versioning and not snapshots. Back to aptly, they use the term shapshot, which you need to manually create https://www.aptly.info/doc/aptly/snapshot/create/ 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 20, 2018 at 5:14 PM, Matthias Dellweg wrote: > I guess, you meant 'RepositoryVersions' there. Maybe it is just a typo, > or maybe your subconciousness already adepted to this change. ;) > > I'm +1, because from the REST API or model view, you do not ask what > changed, but rather what is in that snapshot|version. > And since you are renaming all models 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. However, I > > agree with @dalley though about snapshot not fitting my mental model > > of how I view snapshots so any work seems like a loss to me. > > > > I’m at -1 but am happy to talk more about it. > > > > > > David > > > > On Tue, Mar 20, 2018 at 11:08 AM, Daniel Alley > > wrote: > > > > > 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 10:51 AM, Dennis Kliban > > > wrote: > > > > > >> The article you link to just says that "a snapshot is the state of > > >> a system at a particular point in time". The point in time can be > > >> now or in the past. > > >> > > >> The current state of a repository's content would be described as > > >> the latest or most recent snapshot of a repository. > > >> > > >> I am not too worried about the pain of doing the refactoring across > > >> multiple repos. > > >> > > >> On Tue, Mar 20, 2018 at 10:20 AM, David Davis > > >> wrote: > > >> > > >>> I have some reservations about using the name Snapshot. > > >>> Specifically, I don’t think the snapshot term is a good fit. As > > >>> wikipedia says [0], in CS a snapshot represents a state of > > >>> something "in the past.” How would we describe the current state > > >>> of the repository’s content then? I think "current version" would > > >>> make sense but not "current snapshot.” > > >>> > > >>> Also, changing the code in pulpcore and plugins is going to be a > > >>> pain. Especially with the other things we have planned like > > >>> renaming Importers to Remotes. I think this should factor into > > >>> our decision as well. > > >>> > > >>> [0] https://en.wikipedia.org/wiki/Snapshot > > >>> > > >>> > > >>> David > > >>> > > >>> On Tue, Mar 20, 2018 at 10:05 AM, Austin Macdonald > > >>> wrote: > > >>> > > >>>> "Snapshot" is a nice way to explain what a RepositoryVersion is, > > >>>> especially in the context of Publications. "Publish a > > >>>> snapshot." I like the idea, and I informally floated it around > > >>>> PulpCon but decided not to propose it because: > > >>>> > > >>>>- Snapshot is a little misleading about the actual data we > > >>>> store. Specifically, since RepositoryVersions are stored as > > >>>> diffs, when a user views the "content in a version", this is > > >>>> calculated. This is a subtle point, and hopefully not user > > >>>> facing at all, but I think snapshot implies a little bit more > > >>>> certainty than we can offer. > > >>>>- A snapshot also implies a slightly different workflow to > > >>>> me. The workflow I expect with snapshots
Re: [Pulp-dev] Two docker repos with the same registry image name?
The answer to your question you can find here: https://github.com/Katello/katello/pull/7262#issuecomment-376094549 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 Sat, Mar 24, 2018 at 4:38 PM, Tom McKay wrote: > I forget the field in pulp db, the one that crane exposes as the image > name. Can I have two repos with the same image name? For example, could I > have repo 1 with name "rhel7/rhel" with tags 1 and 2, as well as repo 2 > with name "rhel7/rhel" with tags 3 and 4? > > > ___ > 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] Pulp 3 Unit Test Plan Proposal
-1 for hard check, -1 for 100% coverage. Unittests are good but integration tests are better. I totally agree with what Austin said. We should add tests where it makes sense. +1 soft check. I would not like finding myself banging my head [0] (just because of 100% coverage policy) against one line of code to cover which is not really realistic to happen, +1 complex to mock. +1 to own policy of plugins. [0] https://media.giphy.com/media/g8GfH3i5F0hby/giphy.gif 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 Fri, Mar 23, 2018 at 6:42 PM, Austin Macdonald wrote: > -1 For a blocking check, -1 for attempting 100% coverage. > > There is a *lot* of code in Pulp 3 that simply involves inheriting from > parents classes and defining attributes. If we add a ViewSet for instance, > there is nothing to test other than "asserting that we did what we did". I > have written lots of tests like that. IMO, they add no value and are time > consuming to write. Also, they are time consuming to maintain because every > change must also change the unit tests. This type of test almost never > catches a real problem. > > A soft check would be a useful reminder to the contributor and the > reviewer to add tests where they make sense. + 1 soft check > > Plugins: Each plugin team should determine their own unit test policy. > > > On Fri, Mar 23, 2018 at 1:26 PM, David Davis > wrote: > >> We haven't had a unit test policy in Pulp 3, and the community and core >> committers would all like one. The general desire we've heard so far is to >> change course and encourage developers to add unit tests to their changes >> to Pulp 3. >> >> The policy we're suggesting is to add a coveralls[0] check for Pull >> Requests against the pulpcore 3.0-dev branch that shows the overall >> coverage percentage, e.g. 12.89%. This check would pass if and only if >> coverage increases or remains the same with the PR. We think this will >> eventually get us on the path to 100% unit test coverage. >> >> We propose the coveralls check be a soft check that allow for merging if >> it fails. We would document the policy and try to adhere to it even though >> it wouldn't formally block merging. At a future point when pulp3 (maybe the >> GA?) we could make this a hard check. >> >> Benefits: >> - It's easy, simple, and automatic >> - It's pretty objective and there's little room to argue with a number. >> - Helps us raise our unit test coverage gradually over time >> >> Downsides: >> - Could discourage community contributions >> - It can be a bit strict and unforgiving at times (especially if there's >> a hard check) >> - It only provides a guarantee around quantity of unit testing and not >> quality >> >> >> *Q: What about the existing functionality? Do we need to write unit tests >> for it?* >> >> We're not sure about this. We'd like community feedback. Is anyone >> interested in writing backfill unit tests? If so, then maybe we should. >> >> *Q: Will this also affect Pulp 2?* >> >> We're not planning on it but if we like this enough, we can look at >> adding it to Pulp 2. >> >> *Q: Will this affect plugins?* >> >> We want to start out with just pulpcore now and see how we like it. Then >> we'll look at adding it to pulp_file. In the future, we can also look at >> ways to make it easy for plugins to set this up. >> >> *Q: Do I no longer need to write pulp-smash test plan issues in Github >> for Pulp 3 features?* >> >> No, you should still do that. >> >> [0] https://coveralls.io/ >> >> ___ >> 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
Re: [Pulp-dev] Plugin relationship to tasks
I do not think that it's a valid argument to ban the proposal just because the proposal will bring changes to the existing plugins. Because: 1) i think it would be fair to think of other plugins and find a solution all plugins will be happy with --> so we are back to the generic correctness problem 2) we are not GA, not even Beta, we are free and eligible to make changes, no promises made yet. 3) if we bring changes *this* exactly is the time to do because we have just 2 plugins working with basic functionality :) W/r to the "Pulp turning into a task running system" ..and yet that's a system based on distributed task system I suggest to organize a meeting with an agenda in advance that would list 1) concerns 2) questions I also think it would be valuable to hear Jeff's feedback. If the team finds that meeting idea is beneficial with the believe that after the meeting we will: 1) i am not naive to believe that we would reach consensus but at least we would move forward 2) we will decrease the frustration level, because face2face conversation is more profitable, since we do see faces, have social interaction and not type onto keyboard and stare at the text on the monitor. then...I will take the action item and schedule the meeting. Meanwhile we'll have time to chew on Easter eggs and give to the proposal a deeper, unbiased, full of protein (that helps brain thinking) thought. 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 Wed, Mar 28, 2018 at 12:11 AM, Brian Bouterse wrote: > In terms of removing POST /api/v3/repositories//versions/ from > core, I want to bring it back to the MVP language and REST which drove the > original design. The MVP has: "As an authenticated user, I can create a new > version by adding or removing content to the latest version." To > facilitate that in a generic way, we need a core endpoint to do that, i.e. > /api/v3/repositories//versions/. My concern is that removing it > would cause us to not fulfill our use cases without requiring more code > from some plugin writers. Also in terms of REST philosophy, POSTing to the > RespotoryVersion resource to create a new RepositoryVersion is the > traditional url design. > > For pulp_ansible, for example, the generic add/remove functionality at > core endpoint ^ would be meet all of the pulp_ansible user's needs because > of the way the pulp_ansible content is modelled. So removing this endpoint > means more work for pulp_ansible developers w.r.t creating repo versions > and providing tasks and endpoints. I don't see this extra responsibility on > plugin writers coming with a clear benefit. > > One idea I liked in this discussion is to have a documented convention > that encourages plugin writers to put their viewsets in a namespaced area. > They still need the ability to put them anywhere due to live API > goals/requirements so this would only be a convention for those tasks they > are offering directly to their users. > > > > > > On Tue, Mar 27, 2018 at 5:40 PM, David Davis > wrote: > >> I like Austin’s task proposal in that the plugin writers can focus on >> serializers and tasks that can be easily integrated with core. That said, I >> agree on the counterpoints raise about the new resource endpoints and >> turning much of pulp into a task running system. So I am a bit mixed on >> which approach is better. >> >> I do think that we should remove POST /api/v3/repositories//versions/ >> from core. >> >> >> David >> >> On Tue, Mar 27, 2018 at 3:49 PM, Austin Macdonald >> wrote: >> >>> >>>>- /api/v3/repositories//versions/ endpoint does not perform >>>>plugin specific validation which can lead to "broken" repository >>>> versions. >>>>- Plugin authors don't have any convention to follow when creating >>>>custom REST API endpoints for creating repository versions. >>>>- As a result of ^, a user will have a hard time identifying >>>>repository version creation APIs in different plugins. >>>> >>>> >>> I agree with these points. >>> >>>> >>>>- >>>> >>>> My first inclination is to disable the ability to POST to >>>> /api/v3/repositories//versions/ and require users to use the >>>> plugin specific APIs for creating repository versions. However, I think >>>> that integrators of build systems that produce a variety of content types >>>> would have a lot more flexibility if they could use a single generic API
Re: [Pulp-dev] Demos switching to pre-recorded videos
I would keep this as a suggestion but not a hard requirement. Some people would still like to train their live demoing skills :) 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 Wed, Apr 4, 2018 at 8:36 PM, Brian Bouterse wrote: > After some off-list feedback from several presenters, our Community Demos > are going to start using pre-recorded videos only. We have had a variety of > issues recently with live demos preventing several demos from happening > day-of. This change will start with our next demo on April 25th. > > I've updated the presenter documentation here to match: > https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes > > Any feedback is welcome. > > -Brian > > ___ > 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] remove AUTHORS
+1 to remove AUTHORS file entirely. Not sure if it worth putting `git shortlog -sne` in our docs, everyone is capable to google git commands in case they need to find some specific functionality. My $2. It does make sense to remove the file just because it is difficutle to maintain it (as David mentioned in previous emails) but not because of it exposes personal info, makes it easy for headhunters to reap email addresses. Whenever we *consciously* expose/give our email somewhere we are all accept the possibility of being spammed and headhunted. I am also pretty sure that everyone has couple of email addresses for different purposes ;) 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 Wed, Apr 4, 2018 at 6:57 PM, Brian Bouterse wrote: > OK I'm convinced. Let's remove it altogether. Anyone who needs a serious > answer will be able to find one. > > Thank you! > Brian > > > > On Wed, Apr 4, 2018 at 12:55 PM, David Davis > wrote: > >> This is @dalley’s response on the PR which I agree with: >> >> I would rather get rid of the AUTHORS entirely and put the documentation >> for `git shortlog -sne` elsewhere (or nowhere). >> >> People who want that info should just look at the contributors page for >> the repository on github and, if they need the list in text form, `git >> shortlog -sn` is very very high in the search rankings for that query. >> >> >> >> David >> >> On Wed, Apr 4, 2018 at 12:30 PM, Brian Bouterse >> wrote: >> >>> You did update the dev guide already. Thank you for pointing that out. I >>> was mistaken. >>> >>> My main thinking is about the copyright which indicates the code is >>> owned by the pulp contributors. Having a simple way to provide a definitive >>> answer to that question is useful enough to document. An alternative to >>> keeping it in the AUTHORS file contents would be to add it somewhere in the >>> docs. >>> >>> What do others want to do? >>> >>> Thanks all, >>> Brian >>> >>> >>> On Wed, Apr 4, 2018 at 12:09 PM, Irina Gulina >>> wrote: >>> >>>> Hi all, >>>> >>>> Brian, >>>> >>>> * the dev-guide doc was already updated in that PR, or do I miss smth? >>>> * Does anybody else want the AUTHORS file be updated with smth like "To >>>> see the list of contributors run `git shortlog -sne` command? >>>> Personally, I think it's not needed. >>>> * ok, I will do it for pulp 2 and 3, as soon as we agree on the >>>> previous point. >>>> >>>> Thanks all, >>>> Irina >>>> >>>> >>>> - Original Message - >>>> From: "Brian Bouterse" >>>> To: "Daniel Alley" >>>> Cc: "Pulp-dev" >>>> Sent: Wednesday, 4 April, 2018 5:26:30 PM >>>> Subject: Re: [Pulp-dev] remove AUTHORS >>>> >>>> +1 to removing AUTHORS. I left some requests on the issue: >>>> >>>> * update some of the necessary docs >>>> * replace the AUTHORS content docs for the git shortlog -sne command >>>> * to do it for both pulp2 and pulp3. >>>> >>>> https://github.com/pulp/pulp/pull/3393#issuecomment-378631901 >>>> >>>> On Wed, Apr 4, 2018 at 10:09 AM, Daniel Alley < dal...@redhat.com > >>>> wrote: >>>> >>>> >>>> >>>> +0 >>>> >>>> On Wed, Apr 4, 2018 at 9:14 AM, Dana Walker < dawal...@redhat.com > >>>> 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 I can just keep track of my listed contact >>>> details in my github settings. The same goes for someone who wants privacy >>>> and doesn't want their email listed or someone who has changed their name. >>>> I created the AUTHORS file for pulp_file recently and had misgivings about >>>> whether each of these contributors would have chosen to have the info I put >>>> together as their representative contact info, especially since we squashed >>>> down to one name
Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup
I would try for now to minimize the number of projects because they are difficult to maintain and stick to Tags field until we clearly define what goes where. Some thoughts: if we put CLI as a separate project, where we'd put some plugin specific, for example PRM, cli section/command/option request? Under project CLI with tag RPM? Or under rpm_plugin project with tag CLI? 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 Thu, Apr 5, 2018 at 1:21 AM, Austin Macdonald wrote: > > > On Wed, Apr 4, 2018 at 6:09 PM, Dennis Kliban wrote: > >> Anything that is going to have it's own release cadence should be tracked >> in it's own project. That way we can assign issues related to specific >> release of that project to the particular release. >> > Are we going to release the CLI, Ansible Installer, and the Migration tool >> as part of one version of Pulp or will these all be versioned separately? >> > > Seems reasonable. IMO, CLI should be released on its own. Ansible > Installer role will have its own cadence on Galaxy. Vagrant/playbooks will > not be released. > > The Migration tool is tricky. A pulpcore migration tool would be one > thing, but each plugin will probably need its own migration tool. So... /me > shugs. > > >> >> On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald >> wrote: >> >>> >>>>> I'm hoping to continue the "Infrastructure" Redmine project for things >>>> like website hosting. I see what you mean though because it will be >>>> developed and released separately. I think we're in a similar situation for >>>> 3 things: the ansible installer, the migration tool, and CLI, and for each >>>> of them we should either make their own Redmine projects or a tag under >>>> Pulp. We already have many Redmine projects and they are kind of a pain so >>>> I want to float a tags based approach for feedback. Perhaps keeping them >>>> out of "Pulp" means that we remove all the existing tags from them and tag >>>> them with new tags like 'Ansible Installer', '2to3 Migration' and 'CLI'? >>>> >>> >>> I had hoped that someday there would be a separate group of committers >>> for pulp/devel or wherever we keep it. Also, I wouldnt want potential >>> users/PMs to see a "bug count" that includes non-user facing issues. These >>> concerns are trivial though, and if projects are a pain, I'm fine with >>> keeping Tags. >>> >>> Since projects are a pain, can we get rid of the "external" project? >>> https://pulp.plan.io/projects/external/issues >>> >>> >>> ___ >>> 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
Re: [Pulp-dev] Demos switching to pre-recorded videos
I just personally find the demo recording more time consuming, that's why demoing live besides other benefits(like live interactions, stop and check in with the watchers if the are on the same page or having questions in the middle) are more beneficial for my personal practice. Not sure if other people share same sentiment? I want to believe that in opensourse world we are capable to provide more that one option not to discourage people by strict rules and poor choice. Also, If we do not present live and play just the recordings then i think the value of so-called-live-demo drops drastically or maybe no need to host live demo at all? Why don't we just post the list of recorded videos on the pulp lists then, suggest to watch them later? :) 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 Thu, Apr 5, 2018 at 4:59 PM, Austin Macdonald wrote: > +0 to videos. > > If we do that, lets not post a single "pulp demo" but lets post each demo > separately. > > On Thu, Apr 5, 2018 at 10:51 AM, Brian Bouterse > wrote: > >> I want to try videos only for a while. We've had 3 demos in a row where >> seconds before we start, a "live demo" has to be withdrawn. Usually the >> problem isn't content related; usually it's Wayland, it's YouTube errors, >> it's being late, etc. It's causing us to regularly have an agenda that >> deviates from what was advertised. >> >> I want to call out an opportunity for someone to present live in other >> ways. Anyone can host a Pulp live event on the Pulp YouTube channel and >> present live there. That is especially good for presentations. If you have >> something you want to live present via the YouTube channel, reach out to me >> and we can get it scheduled. >> >> >> >> >> On Thu, Apr 5, 2018 at 8:45 AM, Ina Panova wrote: >> >>> I would keep this as a suggestion but not a hard requirement. >>> Some people would still like to train their live demoing skills :) >>> >>> >>> >>> >>> 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 Wed, Apr 4, 2018 at 8:36 PM, Brian Bouterse >>> wrote: >>> >>>> After some off-list feedback from several presenters, our Community >>>> Demos are going to start using pre-recorded videos only. We have had a >>>> variety of issues recently with live demos preventing several demos from >>>> happening day-of. This change will start with our next demo on April 25th. >>>> >>>> I've updated the presenter documentation here to match: >>>> https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes >>>> >>>> Any feedback is welcome. >>>> >>>> -Brian >>>> >>>> ___ >>>> 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
Re: [Pulp-dev] Roadmap Challenges
W/r to stakeholders needs. We have dedicated people on our team who closely work with the stakeholders, therefore both of the parties are in agreement on: 1) what needs to get done 2) by when #1 needs to get done In my understanding if there are some uncertainties about some work then 1) it was not prioritized 2) it was not brought to the both parties attention. I agree with Jeff that with Redmine Story we were successfully being able to describe, design and plan. In addition to the sub-tasks for commits tracking we have the associated revisions. What i agree with is what brought up Robin - it is not efficient to put on the sprint work and then let it be there for months. Maybe would be a good idea for every work that is groomed to set a deadline - we can speak in terms of time, sprints, releases, whatever we are comfortable with. This way, when we promise to commit to something as a team, we make sure that it gets picked up and worked on, and we do not leave/pospone it be there for X amount of time because maybe it does not really not look appealing. 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, Apr 10, 2018 at 9:40 PM, Jeff Ortel wrote: > From a tooling perspective: > > we have had good success in the past with fully defining and designing a > feature in a Redmine Story. The story (description) provides a good way to > capture (and edit) the overall design and (comments) support a discussion > history. Then, the implementation can be broken down and tracked by > related sub-tasks which are aligned to sprints and cross core/plugin > boundaries. The feature is complete when all the implementation tasks are > complete. > > > On 04/06/2018 02:00 PM, Robin Chan wrote: > > Brian, > > To bring this back to your original question, here are some comments in > line. > > Agree w/#1 - I have observed a few different ways that this problems has > been solved by developers. The requirement here is "I need a way to > understand all the work and deliverables associated with a feature." This > question comes down to how do we track of deliverables. This is I think > secondary and not as much of a problem as the next question. > > #2 - This is essentially a question of planning deliverables. Your > descriptions is "how will someone know if a feature is committed to"? I > think full planning is not necessary for commitment. I believe that "full > planning" part could go in #1 in terms of tracking status. I think the > question is actually "how will someone know if a feature is committed to > and when it is committed by" - addition of a time or time frame. > > In my experience, feature work generally went like this: > 1. Define feature/problem to be solved. > 2. Investigate: > - refine requirements/problem definition > - do enough design or planning of tasks to come up with estimate of > work > 3. Commit to work or not > 4. execute along list of tasks, refine list as you learn. > > Steps 1-3 is part of roadmap planning (higher level planning) and #3-4 is > sprint planning. > > > I think the problem with using the sprint field as we have used it, is > that if you add something to a sprint, the Scrum definition would lead > people to assume that the team is committing to it at the end of a defined > sprint period. We do not. This major departure from industry standard does > not serve us well in my opinion. We have kept items on sprints for many > months and then removed it. Even if we were able to convince folks that our > definition of sprint was "our next few sprints" of work, we don't have any > accountability that we are actually keeping our commitment here and the > folks wanting something on the sprint don't have any idea if something > added to a sprint will be there in 3 weeks or 12 weeks. I think others in > software are reasonable in understanding that software deliveries aren't > going to be there until they are, but I think our immediate focus on what > is in process (impending delivery/next build) and on some of the larger > deliveries. > > Robin > > On Thu, Mar 29, 2018 at 3:13 PM, Brian Bouterse > wrote: > >> I want to start a discussion around how Pulp does roadmap planning and >> some of our current challenges. This is the pre-discussion part of a future >> PUP. I want to collaborate on characterizing the problems first before we >> discuss solutions. >> >> # The surface problem statement >> >> It very difficult for external stakeholders to answer some simple >> questions about any given feature: >> >> * How would a user use this
Re: [Pulp-dev] Improving technical decision making
I could see some advantages here. The benefit of such proposal could create a healthy ecosystem in our team. We just need to answer the question whether now or later is a more appropriate time. I do understand that not everyone on our team has same level of expertise and soft skills, but with these rotation we can: 1) do knowledge transfer, this way less experienced person will learn from a more experienced. 2) the ecosystem of our team will be healthy, and we will not panic when that single person that knows X is not PTO and he have sev1 issue or similar. 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 Wed, Apr 4, 2018 at 3:01 PM, Brian Bouterse wrote: > I'm not ready to pursue a single decision maker model for Pulp's technical > decisions or community leadership. I also have concerns about those > positions being rotating roles since typically they require much > experience. This would also be a departure from the lazy consensus decision > making model we use for community decisions (the pup process itself). > > There would need to be a lot of discussion with input from many people > around what the issues currently are so we can be sure that changes would > resolve those issues. > > > On Wed, Apr 4, 2018 at 4:54 AM, Milan Kovacik wrote: > >> Oh I'd forget that we actually don't really have a formal process to >> recognize and retire active contributors yet; >> how about the technical lead proposes both the recognition and >> retirement anytime they find reason to do so, for the former >> situation, with a pre-approval of other active contributors, propose >> folks publicly, for the latter situation, try reaching out to the >> retiring contributor before going public to avoid frustration. >> Folks of course would ideally announce their intention to retire, the >> formal process would be conducted by the technical lead. >> The insignia of an active contributor would be the commit bit on any >> of the Pulp projects. >> The first ever technical and community leads would be elected by folks >> with the commit bit, the election would be organized by our current >> community representatives. >> >> Unless there are objections, I'd file a PUP to summarize these points. >> >> >> Cheers, >> milan >> >> On Tue, Apr 3, 2018 at 6:02 PM, Milan Kovacik >> wrote: >> > On Tue, Apr 3, 2018 at 3:47 PM, Austin Macdonald >> wrote: >> >> Interesting proposals Milan! >> >> >> >> I am forking Brian's email so that thread can focus on communication, >> >> redmine, etc. >> > >> > Thanks, I guess it would best go hand-in-hand with the process update >> > proposal for the Technical specifications/blue-prints PUP: >> > >> >>> I'd add that many a time, an e-mail based technical discussion gets >> >>> messy and unfolds in multiple branches over multiple months. >> >>> I'd like to propose we adopt a Technical Specification concept, living >> >>> in a separate GitHub repo, similar to the PUP process. >> >>> This would take advantage of our review process, preferably requiring >> >>> multiple (core) reviewers acks before merging, allowing Redmine to be >> >>> used for planning/tracking the (design) work. >> >>> I think it's easier to manage the life-cycle of a larger Technical >> >>> Specification in a revision system document than an e-mail thread and >> >>> a single Redmine issue. >> >>> It also helps (feature) documentation and provides context. >> > >> >> >> >> On Tue, Apr 3, 2018 at 8:13 AM, Milan Kovacik >> wrote: >> >>> >> >>> I'd also like to propose formal Project Technical Lead and a formal >> >>> Project Community Lead roles to be able to decide in case of competing >> >>> (technical) ideas or planning priorities. >> >>> These would have to be time-boxed (half a year) and folks would elect >> >>> the leader for a period based on leader's program, such as focus on >> >>> particular goals for instance testing or refactoring. >> >>> Any single person would be able to perform either the Community or the >> >>> Technical Lead role in any given period but not both at the same time. >> >>> The Community Lead role would take care for organizing the Technical >> >>> Lead elections and vice versa, the Technical
Re: [Pulp-dev] Pulp2 Release Engineer Needs Volunteer
Brian, i'd like to take care of the upcoming pulp2 Y release. I'll ping you on irc to sync up on details. 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 Wed, May 2, 2018 at 5:25 PM, Brian Bouterse wrote: > For the last several Pulp2 releases we've documented [0] the new process > that separates building pulp2 bits from all the other > docs/redmine/announcing stuff. > > Note that to start a Pulp2 release anyone can call for a release via email > to pulp-dev. At that point the "release engineer" will handle the release > train from start to finish, coordinating with the build team. > > I've been that "release engineer" for the past several releases to start > this process, and I'm looking to pass this responsibility on to someone > else. Eventually they can pass it along to another person too. With 2.16.1 > going GA, there are no active pulp2 releases, so now is a great time to > transition the role. > > Is anyone interested in being that "release engineer" for Pulp2? Please > reply on-list if so. I can help onboard and support you as you transition > into the role. > > [0]: https://pulp.plan.io/projects/pulp/wiki/Pulp_2_Release_Planning > > -Brian > > ___ > 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] 2.17.0 Release request
A 2.17.0 is being planned with some features and recent fixes. Here [0] is a release schedule page which outlines some tentative dates, starting with a dev freeze on May 9, 2018. If this schedule needs to be adjusted, please reply with alternate dates. [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Status <https://pulp.plan.io/projects/pulp/wiki/2160_Release_Status> --- 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] 2.17.0 Release request
[0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Status 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 Thu, May 3, 2018 at 4:05 PM, Ina Panova wrote: > A 2.17.0 is being planned with some features and recent fixes. > > Here [0] is a release schedule page which outlines some tentative dates, > starting with a dev freeze on May 9, 2018. > > If this schedule needs to be adjusted, please reply with alternate dates. > > [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Status > <https://pulp.plan.io/projects/pulp/wiki/2160_Release_Status> > > > --- > 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." > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] 2.17.0 Release request
Based on some more discussion it has been decided that we're not ready yet for another Y release. The request for Y release has been withdrawn. 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 Thu, May 3, 2018 at 4:07 PM, Ina Panova wrote: > [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Status > > > > > 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 Thu, May 3, 2018 at 4:05 PM, Ina Panova wrote: > >> A 2.17.0 is being planned with some features and recent fixes. >> >> Here [0] is a release schedule page which outlines some tentative dates, >> starting with a dev freeze on May 9, 2018. >> >> If this schedule needs to be adjusted, please reply with alternate dates. >> >> [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Status >> <https://pulp.plan.io/projects/pulp/wiki/2160_Release_Status> >> >> >> --- >> 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." >> > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] 3.2.0 Crane release schedule
A Crane 3.2.0 is being planned with some features and recent fixes. Here [0] is a release schedule page which outlines some tentative dates, starting with a dev freeze on May 9, 2018. If this schedule needs to be adjusted, please reply with alternate dates. [0] https://pulp.plan.io/projects/pulp/wiki/320_Crane_Release_Status 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Crane 3.2.0 dev freeze
The code for Crane 3.2.0 is now frozen. There are a total of 3 issues prepared for the release. The current beta date is May 16. https://pulp.plan.io/issues?query_id=108 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] PUP5 -- Adopting the "Common Cure Rights Commitment" for Pulp Core
To make a concrete example to prove my understating: Since pulp_rpm is maintained by core team we could adopt this change, meanwhile pulp_deb is beyond our control and we( core team) cannot enforce or influence this change. Yes? 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, May 8, 2018 at 5:55 PM, Brian Bouterse wrote: > A Pulp Update Proposal (PUP) pull request has been opened by the > go-to-lawyer for the Pulp community, Richard Fontana. The PUP is PUP5 [0]. > I don't want to paraphrase it here, so please read it [0] if you are > interested to understand what it does. > > I am proposing a period of questions/discussion via the list/PR and then a > call for a vote according to the process. All questions are welcome, please > ask. > > > # Timeline > > Today - May 18th mailing list and PR discussion > May 18th - formally call for a vote which would end 12 calendar days from > then May 30th > May 30th - Merge or reject > > > # FAQs > > Is this relicensing Pulp? > No. It's still GPLv2. This adopts a procedural enforment approach within > the existing license. See @rfontana's response here: > https://github.com/pulp/pups/pull/9#issuecomment-384523020 > > Do all prior contributors need to sign off on this change? > No, because it's not a relicensing. > > Does this affect core, plugins, or both? > This PR is only scoped to affect the GPLv2 codebases maintained by the > core team. Plugins make their own decisions without PUPs. Initially this > would be pulp/pulp, and as other GPLv2 repositories are maintained by the > core team, it would apply to this in the future as well. > > > [0]: https://github.com/pulp/pups/pull/9/files > > Thanks, > Brian > > ___ > 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] PUP5 -- Adopting the "Common Cure Rights Commitment" for Pulp Core
*understanding 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 Mon, May 14, 2018 at 12:27 PM, Ina Panova wrote: > To make a concrete example to prove my understating: > > Since pulp_rpm is maintained by core team we could adopt this change, > meanwhile pulp_deb is beyond our control and we( core team) cannot enforce > or influence this change. > Yes? > > > > > 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, May 8, 2018 at 5:55 PM, Brian Bouterse > wrote: > >> A Pulp Update Proposal (PUP) pull request has been opened by the >> go-to-lawyer for the Pulp community, Richard Fontana. The PUP is PUP5 [0]. >> I don't want to paraphrase it here, so please read it [0] if you are >> interested to understand what it does. >> >> I am proposing a period of questions/discussion via the list/PR and then >> a call for a vote according to the process. All questions are welcome, >> please ask. >> >> >> # Timeline >> >> Today - May 18th mailing list and PR discussion >> May 18th - formally call for a vote which would end 12 calendar days from >> then May 30th >> May 30th - Merge or reject >> >> >> # FAQs >> >> Is this relicensing Pulp? >> No. It's still GPLv2. This adopts a procedural enforment approach within >> the existing license. See @rfontana's response here: >> https://github.com/pulp/pups/pull/9#issuecomment-384523020 >> >> Do all prior contributors need to sign off on this change? >> No, because it's not a relicensing. >> >> Does this affect core, plugins, or both? >> This PR is only scoped to affect the GPLv2 codebases maintained by the >> core team. Plugins make their own decisions without PUPs. Initially this >> would be pulp/pulp, and as other GPLv2 repositories are maintained by the >> core team, it would apply to this in the future as well. >> >> >> [0]: https://github.com/pulp/pups/pull/9/files >> >> Thanks, >> Brian >> >> ___ >> 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] MODIFIED redmine issues for 3.0 beta
If i am not mistaken as of now the person who takes care of a release needs to manually change the issue status. There is a possibility to select all the issues and actually move the status in 1 click. Do you think to automate this will pay off? I am fine to close issues as current release in case we set the target release specifically Beta, otherwise it sounds like it brings some confusion. There is a big period between Beta and GA and you never know what can happen to those set issues especially if they are targeted as GA. 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 Mon, May 14, 2018 at 7:03 PM, Dennis Kliban wrote: > Historically we would transition issues in Pulp's issue tracker from > MODIFIED to CLOSED - CURRENTRELEASE when a GA build went out the door. The > same approach is working against us for the duration of the Pulp 3.0 beta. > We have a large number of issues in MODIFIED state, but are considered > released. > > I propose that we transition issues to CLOSED - CURRENTRELEASE when they > have been shipped with a 3.0 beta. > > Could we add automation to do this at release time? > > What do you all think? > > > Thanks, > Dennis > > ___ > 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] Composed Repositories
+1 on not introducing dependencies between plugins. What will be the behavior in case there is a composed repo of rpm and ks trees but just the rpm plugin is installed? Do we fail and say we cannot sync this repo at all or we just sync the rpm part? Depends how we plan this ^ i guess we'll decide which option 1 or 2 fits better. Don't want to go wild, but what if notion of composed repos will be so popular in the future that's its amount will increase? I think we do want to at least partially being able to sync it and not take the approach all or nothing? #2 speaks to me more for now. ---- 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 Mon, May 14, 2018 at 9:44 PM, Jeff Ortel wrote: > Let's brainstorm on something. > > Pulp needs to deal with remote repositories that are composed of multiple > content types which may span the domain of a single plugin. Here are a few > examples. Some Red Hat RPM repositories are composed of: RPMs, DRPMs, , > ISOs and Kickstart Trees. Some OSTree repositories are composed of OSTrees > & Kickstart Trees. This raises a question: > > How can pulp3 best support syncing with remote repositories that are > composed of multiple (unrelated) content types in a way that doesn't result > in plugins duplicating support for content types? > > Few approaches come to mind: > > 1. Multiple plugins (Remotes) participate in the sync flow to produce a > new repository version. > 2. Multiple plugins (Remotes) are sync'd successively each producing a new > version of a repository. Only the last version contains the fully sync'd > composition. > 3. Plugins share code. > 4. Other? > > > Option #1: Sync would be orchestrated by core or the user so that multiple > plugins (Remotes) participate in populating a new repository version. For > example: the RPM plugin (Remote) and the Kickstart Tree plugin (Remote) > would both be sync'd against the same remote repository that is composed of > both types. The new repository version would be composed of the result of > both plugin (Remote) syncs. To support this, we'd need to provide a way > for each plugin to operate seamlessly on the same (new) repository > version. Perhaps something internal to the RepositoryVersion. The > repository version would not be marked "complete" until the last plugin > (Remote) sync has succeeded. More complicated than #2 but results in only > creating truly complete versions or nothing. No idea how this would work > with current REST API whereby plugins provide sync endpoints. > > Option #2: Sync would be orchestrated by core or the user so that multiple > plugins (Remotes) create successive repository versions. For example: the > RPM plugin (Remote) and the Kickstart Tree plugin (Remote) would both be > sync'd against the same remote repository that is a composition including > both types. The intermediate versions would be incomplete. Only the > last version contains the fully sync'd composition. This approach can be > supported by core today :) but will produce incomplete repository versions > that are marked complete=True. This /seems/ undesirable, right? This may > not be a problem for distribution since I would imaging that only the last > (fully composed) version would be published. But what about other usages > of the repository's "latest" version? > > Option #3: requires a plugin to be aware of specific repository > composition(s); other plugins and creates a code dependency between > plugins. For example, the RPM plugin could delegate ISOs to the File > plugin and Kickstart Trees to the KickStart Tree plugin. > > For all options, plugins (Remotes) need to limit sync to affect only those > content types within their domain. For example, the RPM (Remote) sync > cannot add/remove ISO or KS Trees. > > I am an advocate of some from of options #1 or #2. Combining plugins > (Remotes) as needed to deal with arbitrary combinations within remote > repositories seems very powerful; does not impose complexity on plugin > writers; and does not introduce code dependencies between plugins. > > Thoughts? > > ___ > 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] Core Commit Bit Process
Brian, thanks for spending time and writing down this email. +1 for submitting pup for for commit bit acquisition. W/r to commit bit relieve/loss/removal i would make a separate pup just because we'd need to deal with a lot of conditions and usecases. * i suggest the process we'd adopt would be default one and plugins would follow those by default unless they would write their own process. * i suggest we list at least some kind of criteria like X time involved in project development, has demonstrated to provide good form and useful code reviews, has submitted code that was accepted into main parts of the project. Project in this case i am referring the repository( pulp/ ) which is part of organization (Pulp) * the candidate would whether apply himself for commit bit or an existing core member would nominate the candidate through the email list, for example pulp-dev * voting willbe open and public via email, with majority of core-devs voted and no -1. Some time limit on voting would be set as well. * chance of re-applying for commit bit with some cooldown 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, May 22, 2018 at 3:27 PM, Robin Chan wrote: > We should also have a process to remove a commit bit from a contributor. > > I believe it would be helpful to come up with an initial proposal for > granting the commit bit, then a proposal for removing, and then going > to a vote for the grant or both. I don't want to confuse the subject, > so I'll stay on the subject of granting. > > Any proposal on terminology for terms would be helpful so we can > communicate clearly. > > Process > - I think the contributor should request the commit bit via an email > call for vote on the pulp-dev list. Reason here is that this is a lot > of responsibility and they have to be willing to accept that > responsibility. > > Criteria > I am fine with the lack of hard requirements for getting the commit > bit. I wonder if it would be helpful to add some minimal requirements > such as length of time of involvement or # of PRs reviewed/merged to > be considered or ask for a vote? Or perhaps this that guidance it > listed more as expectations for responsibilities held as a commit bit > holder. The gist here would be that you let the requestor know what > would be expected of them and some guidance on what what our > expectations are vs. other projects. > > > On Tue, May 22, 2018 at 4:34 AM, Milan Kovacik > wrote: > > Brian, > > > > thanks for the proposal! > > I agree with the proposed process to gain the commit bit because of it > > being based on the trust folks have to each other and the project and > > because of its positive feedback loop effect on the trust building, > > this process I believe will bring. > > I'd like to suggest we adopt a process to relieve a commit bit too. > > > > Thanks, > > milan > > > > > > On Mon, May 21, 2018 at 11:48 PM, Brian Bouterse > wrote: > >> For core and it's related tools, we don't have a written process to > describe > >> giving the commit bit to a contributor. We've been wanting to agree on > and > >> document that process for a while, so I'm facilitating thread gathering > >> ideas to inform the writing of a PUP. > >> > >> This starter email gives a brief history of what we've done and > outlines a > >> simple proposal to get us started. We can throw that proposal away in > favor > >> of any other idea. > >> > >> # History > >> > >> Historically if you were hired onto the Pulp team at Red Hat you > received > >> the commit bit day 0. In Oct 2017 we decided to stop doing that and > instead > >> document an open process. Engineers hired on the pulp time since Oct '17 > >> have not received commit bit. We have not yet documented an open > process of > >> which to give it to them or any other proven contributor. > >> > >> # Current State > >> > >> The current core devs as shown on github are: asmacdo, bizhang, > bmbouter, > >> daviddavis, dkliban, dalley, ipanova, jortel, pcreech, ttereshc > >> > >> # Scope of this discussion > >> > >> pulp/pulp, pulp/devel, and any repos for the Pulp3 Ansible installer. It > >> applies to both Pulp2 and Pulp3. Plugins will do what they want. > >> > >> # Process Idea > >> > >> One process idea is to add a new core committer upon a vote with +1's > >> received from all current core developers.
Re: [Pulp-dev] PUP5 -- Adopting the "Common Cure Rights Commitment" for Pulp Core
+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 Fri, Jun 1, 2018 at 6:11 PM, Austin Macdonald wrote: > +1 > > On Fri, Jun 1, 2018 at 8:54 AM, Dana Walker wrote: > >> +1 >> >> Dana Walker >> >> Associate Software Engineer >> >> Red Hat >> >> <https://www.redhat.com> >> <https://red.ht/sig> >> >> On Thu, May 31, 2018 at 4:08 PM, Daniel Alley wrote: >> >>> +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/p >>>> ull/9#issuecomment-393317027 >>>> >>>> +1 >>>> >>>> On Wed, May 23, 2018 at 11:29 AM, Dennis Kliban >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> On Wed, May 23, 2018 at 10:41 AM, Brian Bouterse >>>>> wrote: >>>>> >>>>>> Through feedback on the issue and discussion in #pulp-dev, one small >>>>>> language revision [0] was added to PUP5 [1]. I believe we are ready to >>>>>> call >>>>>> a vote. >>>>>> >>>>>> Voting for PUP5 is open and will close on June 2nd. Please respond >>>>>> with your vote to this thread if you feel so inclined (lazy consensus). >>>>>> Barring any -1's cast, PUP5 will be merged on June 4th. >>>>>> >>>>>> [0]: https://github.com/richardfontana/pups/commit/99fcd35e1cc396 >>>>>> a1ba5a34555f093304dd07a333 >>>>>> [1]: https://github.com/pulp/pups/pull/9 >>>>>> >>>>>> -Brian >>>>>> >>>>>> >>>>>> On Tue, May 15, 2018 at 10:47 AM, Brian Bouterse >>>>> > wrote: >>>>>> >>>>>>> @ipanova, I think of the core team as only maintaining pulp/pulp and >>>>>>> pulp/devel so I limit the scope of this to those repos only. I think >>>>>>> pulp_rpm (or any plugin) could adopt the CCRC without a PUP by following >>>>>>> the "Displaying the CRCC section >>>>>>> <https://github.com/pulp/pups/pull/9/files#diff-e883d39d60672a684862d3cef971e94eR106>" >>>>>>> in their own repo. >>>>>>> >>>>>>> @dawalker, relicensing to GPLv3 is an alternative. It's not a bad >>>>>>> option, but it would be more complicated. Since every committer with >>>>>>> even a >>>>>>> single line of current code is a copyright holder of the codebase, and >>>>>>> it >>>>>>> would require a 100% signoff from all copyright holders, in practice >>>>>>> this >>>>>>> can be difficult. Also someone may not even use that email anymore so it >>>>>>> may not even be possible. I haven't assessed how many Pulp3 committers >>>>>>> we >>>>>>> have currently for the Pulp3 codebase. >>>>>>> >>>>>>> I was recently part of a relicensing which failed >>>>>>> <https://github.com/python-bugzilla/python-bugzilla/issues/25>, but >>>>>>> it shows what the process looks like: >>>>>>> https://github.com/python-bugzilla/python-bugzilla/issues/25 If >>>>>>> someone wants to champion switching to GPLv3 and create an issue like >>>>>>> that >>>>>>> and get all the signoffs I'm not opposed to relicensing to GPLv3 >>>>>>> instead of >>>>>>> adopting the CRCC. >>>>>>> >>>>>>> On Mon, May 14, 2018 at 1:34 PM, Dana Walker >>>>>>> wrote: >>>>>>> >>>>>>>> Other than the noted point that it takes time, is there any reason >>>>>>>> why Pulp should stay on the current license instead of moving to GPLv3 >>>>>>>> (one >>>>>>>> of the stated alternatives in this PUP)? I don't know much about the >>>>>>>> differences currently, but it strikes me that our new Pu
Re: [Pulp-dev] Lazy for Pulp3
we could try to go with: policy=immediate -> downloads now while the task runs (no lazy). Also the default if unspecified. policy=on_demand -> All the steps in the diagram. Content that is downloaded is saved so that it's only ever downloaded once. policy=cache_only -> All the steps in the diagram except step 14. If squid pushes the bits out of the cache, it will be re-downloaded again to serve to other clients requesting the same bits. ---- 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 Fri, Jun 1, 2018 at 12:36 AM, Jeff Ortel wrote: > > > On 05/31/2018 04:39 PM, Brian Bouterse wrote: > > I updated the epic (https://pulp.plan.io/issues/3693) to use this new > language. > > policy=immediate -> downloads now while the task runs (no lazy). Also the > default if unspecified. > policy=cache-and-save -> All the steps in the diagram. Content that is > downloaded is saved so that it's only ever downloaded once. > policy=cache -> All the steps in the diagram except step 14. If squid > pushes the bits out of the cache, it will be re-downloaded again to serve > to other clients requesting the same bits. > > > These policy names strike me as an odd, non-intuitive mixture. I think we > need to brainstorm on policy names and/or additional attributes to best > capture this. Suggest the epic be updated to describe the "modes" or use > cases without the names for now. I'll try to follow up with other > suggestions. > > > > Also @milan, see inline for answers to your question. > > On Wed, May 30, 2018 at 3:48 PM, Milan Kovacik > wrote: > >> On Wed, May 30, 2018 at 4:50 PM, Brian Bouterse >> wrote: >> > >> > >> > On Wed, May 30, 2018 at 8:57 AM, Tom McKay >> wrote: >> >> >> >> I think there is a usecase for "proxy only" like is being described >> here. >> >> Several years ago there was a project called thumbslug[1] that was >> used in a >> >> version of katello instead of pulp. It's job was to check entitlements >> and >> >> then proxy content from a cdn. The same functionality could be >> implemented >> >> in pulp. (Perhaps it's even as simple as telling squid not to cache >> anything >> >> so the content would never make it from cache to pulp in current >> pulp-2.) >> > >> > >> > What would you call this policy? >> > policy=proxy? >> > policy=stream-dont-save? >> > policy=stream-no-save? >> > >> > Are the names 'on-demand' and 'immediate' clear enough? Are there better >> > names? >> >> >> >> >> >> Overall I'm +1 to the idea of an only-squid version, if others think it >> >> would be useful. >> > >> > >> > I understand describing this as a "only-squid" version, but for >> clarity, the >> > streamer would still be required because it is what requests the bits >> with >> > the correctly configured downloader (certs, proxy, etc). The streamer >> > streams the bits into squid which provides caching and client >> multiplexing. >> >> I have to admit it's just now I'm reading >> https://docs.pulpproject.org/dev-guide/design/deferred-downl >> oad.html#apache-reverse-proxy >> again because of the SSL termination. So the new plan is to use the >> streamer to terminate the SSL instead of the Apache reverse proxy? >> > > The plan for right now is to not use a reverse proxy and have the client's > connection terminate at squid directly either via http or https depending > on how squid is configured. The Reverse proxy in pulp2's design served to > validate the signed urls and rewrite them for squid. This first > implementation won't use signed urls. I believe that means we don't need a > reverse proxy here yet. > > >> W/r the construction of the URL of an artifact, I thought it would be >> stored in the DB, so the Remote would create it during the sync. >> > > This is correct. The inbound URL from the client after the redirect will > still be a reference that the "Pulp content app" will resolve to a > RemoteArtifact. Then the streamer will use that RemoteArtifact data to > correctly build the downloader. That's the gist of it at least. > > >> > >> > To confirm my understanding this "squid-only" policy would be the same >> as >> > on-demand excep
Re: [Pulp-dev] Foreman / Katello / Pulp at FrOSCon2018
Awesome news! Whoever is around - do not miss the chance to stop by, share ideas, experience and grab swag! 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, Jun 5, 2018 at 5:35 PM, Matthias Dellweg wrote: > Hi all, > we proudly announce, *drum roll*, that we have a confirmed spot for a > Foreman / Katello / Pulp community booth at FrOSCon. > > FrOSCon will be held at Hochschule Bonn-Rhein-Sieg from 25th > to 26th of August. > > If you are around come visit us. If you want to participate in any way, > drop us a note at froscon-2...@atix.de and we will figure out, what is > possible. > > Hope to see you all, > Matthias and the ATIX crew > > ___ > 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] 'id' versus 'pulp_id' on Content
uuid sounds like good compromise. 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 Thu, Jun 14, 2018 at 9:38 PM, Jeff Ortel wrote: > > > On 06/14/2018 12:19 PM, Jeff Ortel wrote: > >> >> >> On 06/14/2018 10:37 AM, Daniel Alley wrote: >> >>> I will make one more suggestion. What about naming "id" -> "uuid"? >>> This carries the clear connotation that it is a unique identifier so it is >>> less likely to be confusing a la "id and _id", and is still less likely to >>> have a namespace conflict. >>> >> >> Appreciate the suggestion but this would only be marginally less >> confusing. >> > > Reconsidering this suggestion for the reasons you outlined. > > > ___ > 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] Ideas for the plugin template
+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 Thu, Jun 14, 2018 at 10:19 PM, Bihan Zhang wrote: > +1 > I think the plugin_template is very valuable for bootstrapping plugin > development, but we have had issues with keeping it up to date. Creating a > smash test that will enforce this on new PRs make perfect sense to me. > > > > On Thu, Jun 14, 2018 at 11:29 AM, Austin Macdonald > wrote: > >> I've recently updated the plugin_template to work with the latest >> master (3.0). [0] The template handles almost all of the bootstrapping >> work necessary to write a new plugin, so it is valuable to keep it up to >> date. Given human nature, it's likely that the plugin_template will tend >> to fall behind as it did recently. I have some ideas to save time while >> keeping the template current and useful. >> >> 1) Move the plugin writer docs [1] into the plugin_template repository >> - Leave a (very) high level overview in the core docs with a link >> to >> the template docs. >> - Plugin writer docs PRs would only go to one place, and it would >> be easier keep the docs in line with the code. >> - Narrative docs in the template would explain what needs to be >> done generally, linking to the modules. >> - Specific instructions would live in the code modules alongside >> basic working code, and additional commented out code >> to demonstrate and explain more complex behaviors. >> >> 2) Add pulp_smash tests for basic functionality of a bootstrapped plugin. >> - Run these tests as a check on pulpcore and template PRs >> - Ensure that discoverability works >> - Fail with breaking Plugin API changes >> - If the test uses pulp_smash, it would include a base set of >>integration tests for every new plugin. >> >> My reasoning is that no matter what changes we make to pulpcore, >> we need to keep the plugin writer docs updated. Doing this in the >> template will provide value for plugin writers, and will inform pulpcore >> developers when it needs to be updated. >> >> [0]: https://github.com/pulp/plugin_template/pull/9 >> [1]: https://github.com/pulp/pulp/tree/master/docs/plugins/plugin-writer >> >> >> >> ___ >> 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
Re: [Pulp-dev] Pulp 2 plugin release plan
Dennis, thank you for sending out the summary of our meeting. Just to highlight and check the overall understanding - there will be one repository per Y pulp release which might contain multiple Z and Y plugin version releases. Correct me if i am wrong. What would be our next steps in terms of collaboration with the build team? 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 Mon, Jun 18, 2018 at 8:20 PM, Dennis Kliban wrote: > Earlier today a few of us met to discuss how we can release new Y releases > of plugins without a Y release of the platform accompanying them. > > The initial proposal was to publish a new Y release of a plugin at the > same time as a Z release of platform and other plugins. More concretely, we > were discussing putting pulp-docker-* 3.2.0 packages into the 2.16 > repository[0]. This repository currently contains 3.1.3 packages. > Publishing 3.2.0 packages to this repository would completely remove the > 3.1.3 pulp-docker packages. Since 3.1.3 pulp-docker-* packages were only > published to the 2.16 repository, the only 3.1.z package available after a > publish of 3.2.0 would be 3.1.2 in the 2.15 repository[1]. After > identifying this problem, we decided to NOT release pulp-docker-* 3.2.0 > with the 2.16.2 z-stream release. > > In order to eliminate this problem in the future, we would like to > investigate if it will be possible to compose repositories with new Y > releases of plugins while retaining the previous versions of packages that > were already published to the repository before. If this is possible, we > would try to start composing our Z stream repositories in such a way > starting with 2.17.0 release. > > Questions? Thoughts? Ideas? > > > [0] https://repos.fedorapeople.org/pulp/pulp/stable/2.16/7Server/x86_64/ > [1] https://repos.fedorapeople.org/pulp/pulp/stable/2.15/7Server/x86_64/ > > > ___ > 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] Pulp 2 plugin release plan
API is not supposed to be changed, but an async plugin release might have not just fixes to the underlying code but also enhancements/features that implies introduction of new code and behaviour change. Do you think that given this ^ information bumping to the primary product version is desirable? 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, Jun 19, 2018 at 11:53 PM, Tom McKay wrote: > Just curious, but I assume that for an async plugin release that would > imply zero changes to the exposed APIs and only fixes to the underlying > code? > > As a consumer of pulp, we install pulp-server not individual plugins. If a > plugin changes it's exposed interface (ie. API) then I'd expect a bump on > the primary product version. > > Foreman has an interface layer that, if the API changes, may itself > require updates. If API is 100% backward compatible, then there shouldn't > be a problem. > > On Tue, Jun 19, 2018 at 11:06 AM, Dennis Kliban > wrote: > >> On Tue, Jun 19, 2018 at 10:54 AM, Ina Panova wrote: >> >>> Dennis, >>> thank you for sending out the summary of our meeting. >>> >>> Just to highlight and check the overall understanding - there will be >>> one repository per Y pulp release which might contain multiple Z and Y >>> plugin version releases. >>> Correct me if i am wrong. >>> >>> >> That is correct. >> >> >> >>> What would be our next steps in terms of collaboration with the build >>> team? >>> >>> >>> >> My understanding was that Patrick is planning to do some investigation >> and report back on this thread. Please correct me if I am wrong. >> >> >>> >>> >>> 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 Mon, Jun 18, 2018 at 8:20 PM, Dennis Kliban >>> wrote: >>> >>>> Earlier today a few of us met to discuss how we can release new Y >>>> releases of plugins without a Y release of the platform accompanying them. >>>> >>>> The initial proposal was to publish a new Y release of a plugin at the >>>> same time as a Z release of platform and other plugins. More concretely, we >>>> were discussing putting pulp-docker-* 3.2.0 packages into the 2.16 >>>> repository[0]. This repository currently contains 3.1.3 packages. >>>> Publishing 3.2.0 packages to this repository would completely remove the >>>> 3.1.3 pulp-docker packages. Since 3.1.3 pulp-docker-* packages were only >>>> published to the 2.16 repository, the only 3.1.z package available after a >>>> publish of 3.2.0 would be 3.1.2 in the 2.15 repository[1]. After >>>> identifying this problem, we decided to NOT release pulp-docker-* 3.2.0 >>>> with the 2.16.2 z-stream release. >>>> >>>> In order to eliminate this problem in the future, we would like to >>>> investigate if it will be possible to compose repositories with new Y >>>> releases of plugins while retaining the previous versions of packages that >>>> were already published to the repository before. If this is possible, we >>>> would try to start composing our Z stream repositories in such a way >>>> starting with 2.17.0 release. >>>> >>>> Questions? Thoughts? Ideas? >>>> >>>> >>>> [0] https://repos.fedorapeople.org/pulp/pulp/stable/2.16/7Server >>>> /x86_64/ >>>> [1] https://repos.fedorapeople.org/pulp/pulp/stable/2.15/7Server >>>> /x86_64/ >>>> >>>> >>>> ___ >>>> 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
[Pulp-dev] 2.17.0 Release request
A 2.17.0 is being planned with some features and recent fixes. Here [0] is a release schedule page which outlines some tentative dates, starting with a dev freeze on July 30 2018. If this schedule needs to be adjusted, please reply with alternate dates. [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Schedule 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Branching Pulp 2 for plugins
Please keep in mind that for docker plugin it's 4.0dev and not 3.0dev. пн, 2 июл. 2018 г., 16:49 David Davis : > In order to conform to the pulp/pulp repository, I propose we update our > branches for our plugins. This would include: > > 1. Moving master to 2-master > 2. Moving 3.0-dev to master (and removing 3.0-dev) > 3. Letting @pcreech know that the branches have changed > > I was thinking we could do aim to do so by July 9th. Here are the plugins > we need to update and some volunteers I have picked randomly from a hat to > handle updating the branches: > > - puppet - @bizhang > - rpm - @daviddavis > - python - @bizhang > - docker - @dkliban > - ostree - @jortel > > I’m not sure what to do about our debian plugin though since it doesn’t > have a 3.0-dev branch. > > Any feedback is welcome. Thanks. > > David > ___ > 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] Revising PUPs
+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 Mon, Jul 9, 2018 at 3:22 PM, Dana Walker wrote: > +1 > > Dana Walker > > Associate Software Engineer > > Red Hat > > <https://www.redhat.com> > <https://red.ht/sig> > > On Mon, Jul 9, 2018 at 9:05 AM, Daniel Alley wrote: > >> +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 >>>> >>>> I’d also like to call a vote on this proposed change. Here’s the voting >>>> model from PUP-1: >>>> >>>> +1: "Will benefit the project and should definitely be adopted." >>>> +0: "Might benefit the project and is acceptable." >>>> -0: "Might not be the right choice but is acceptable." >>>> -1: "I have serious reservations that need to be thought through and >>>> addressed." >>>> >>>> Deadline will be July 22, 2018. >>>> >>>> David >>>> >>>> >>>> On Tue, Jul 3, 2018 at 11:14 AM David Davis >>>> wrote: >>>> >>>>> While there is a process for revising PUPs before they are >>>>> accepted[0], we don’t have any process for revising PUPs after they are >>>>> accepted. I’d like to upate PUP-1[1] to create a simple but formal process >>>>> for revising accepted PUPs. >>>>> >>>>> I was thinking we should add a section (“Revising an Accepted PUP”) >>>>> that says say revising a PUP follows the same process as creating a new >>>>> PUP. This includes an initial discussion period followed by a PR against >>>>> the PUP with the proposed change. After that, there should be a vote >>>>> decided by our existing lazy consensus model. >>>>> >>>>> Thoughts? >>>>> >>>>> [0] https://github.com/pulp/pups/blob/master/pup-0001.md#revision >>>>> [1] https://github.com/pulp/pups/blob/master/pup-0001.md >>>>> >>>>> David >>>>> >>>> >>>> ___ >>>> 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 >> >> > > ___ > 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] Branch protection
+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, Jul 10, 2018 at 11:31 PM, Jeff Ortel wrote: > +1 > > > On 07/10/2018 02: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 tests, docs test, flake8) > > If so, I think we should also do this for all master and 2-master branches > for all Pulp core repos (where applicable). Does anyone have any thoughts > or objections? > > I’ll leave this discussion open until July 22, 2018. > > David > > > ___ > 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] 2.17.0 Dev Freeze - Tuesday, July 31
2.17.0 Release is delayed due to unforeseen discovered issues. For the new tentative dates please check the release schedule [0] Thank you. [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Schedule 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 Wed, Aug 1, 2018 at 4:17 AM, Robin Chan wrote: > All Pulp2 core or plugin code included in the 2.17.0 release should > already be: > a) merged to master > b) associated with a story, refactor, task or a bugfix issue. > > Sorry for the late notice, our release contact is out sick unexpectedly > and I failed to handle this as the backup. > > The list of features & bug fixes to be included in 2.17.0 can be found > here[0]. The beta schedule[1] shows the 2.17.0 beta release date as > Tuesday August 7th. > > [0] https://tinyurl.com/y96j92hl > [1] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Schedule > > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC
All outstanding issues and regressions were resolved. The code for 2.17.0 is now frozen. Check the list of work completed and prepared for the release: https://tinyurl.com/y96j92hl 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp Code Owners
+1 for the pup. Milan, I guess you are SME, when you are publicly recognized to understand the topic. You will ask *when* this public recognition is happening? When the answer to the such question like: -Who is person to contact for X? And the answer will be : - It's this guy Y. 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, Aug 14, 2018 at 3:56 PM, Milan Kovacik wrote: > > > On Tue, Aug 14, 2018 at 3:47 PM, David Davis > wrote: > >> On Tue, Aug 14, 2018 at 9:35 AM Milan Kovacik >> wrote: >> >>> >>> >>> On Tue, Aug 14, 2018 at 1:26 PM, David Davis >>> wrote: >>> >>>> The relevant party could either be a subset of the commit bit owners >>>> (e.g. task group) or a set of people who don’t have the commit bit (e.g. >>>> QE). See the team examples from my original email. >>>> >>> >>> So what you mean is actually a trusted subset of commit bit owners, >>> like the SMEs? >>> >> >> These teams aren’t necessarily a subset of commit bit owners but yes >> they’ll be subject matter experts (SMEs) for the code they own. Take QE for >> example. They might not have the commit bit to the pulp repo but they are >> still the SMEs for pulp_smash tests and thus they’ll probably be code >> owners for the smash tests in pulp and pulp_file. >> >> >>> So we don't trust all commit bit owners equally when it comes to >>> particular git (sub)tree? >>> >> And we trust (by blocking the merge) on e.g QE approving a PR more than >>> the commit bit owner that is outside of the subset? >>> Or is it rather about decoupling the code review duty from the commit >>> bit ownership? >>> >> >> To answer these questions, I don’t think it’s about trust. It’s about (as >> you mention) decoupling merging code from code reviews. We want to make >> sure the appropriate people get notified and have a chance to review the >> PRs for which they are SMEs. >> > > This has the same issue as the commit bit ownership, it's just more fine > grained and bound to particular subtrees: how does one become an SME? > What's the SME lifecycle? > > >> >> >>> Why do we need commit bit owners then? >>> >> >> How else do we merge the code if no one has a commit bit? >> > > thru a bot for instance > > >> >> >>> >>> Cheers, >>> milan >>> >>> >>>> >>>> Daniel, you are correct. The only caveat is that PRs can’t be merged if >>>> they touch a file owned by a team and haven’t been approved by that team. >>>> >>>> David >>>> >>>> >>>> On Tue, Aug 14, 2018 at 6:35 AM Milan Kovacik >>>> wrote: >>>> >>>>> +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 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. Feedback on the initial proposal below is welcome. I >>>>>>> will >>>>>>> try to collect the feedback and open a PUP by the end of the week. >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> # Problem Statement >>>>>>> >>>>>>> For Pulp's review process, there are several areas we could improve: >>>>>>> >>>>>>> 1. It’s not always clear who should review files. Over time we have >>>>>>> developed subject matter experts for different areas of the codebase, >>>>>>> but >>>>>>> these are not codified anywhere. It would be useful for us to define >>>>>>>
[Pulp-dev] Commit bit PUP-6
I have opened a PR for PUP-6 [0] which describes the commit bit assignment/revocation process. Please take a look to review and provide feedback. I'd like to call for a vote by August 28, 2018. Per PUP-1[1], are the voting options: +1: "Will benefit the project and should definitely be adopted." +0: "Might benefit the project and is acceptable." -0: "Might not be the right choice but is acceptable." -1: "I have serious reservations that need to be thought through and addressed." Thank you! [0] https://github.com/pulp/pups/pull/15 [1] https://github.com/pulp/pups/blob/master/pup-0001.md 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Requiring 2FA in Github
+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 Thu, Aug 16, 2018 at 3:08 PM, Dennis Kliban wrote: > +1 > > On Wed, Aug 15, 2018 at 4:06 PM, Brian Bouterse > wrote: > >> +1 >> >> tiny grammar fix on the PR requested. Thank you for organizing this! >> >> On Wed, Aug 15, 2018 at 2:10 PM, David Davis >> wrote: >> >>> Thanks everyone for the feedback. I have opened a PR for PUP-7 which (if >>> approved) will require 2FA for the Pulp organization in Github: >>> >>> https://github.com/pulp/pups/pull/14 >>> >>> Feedback welcome. Also, I'd like to call for a vote by August 27, 2018. >>> Per PUP-1[0], are the voting options: >>> >>> +1: "Will benefit the project and should definitely be adopted." >>> +0: "Might benefit the project and is acceptable." >>> -0: "Might not be the right choice but is acceptable." >>> -1: "I have serious reservations that need to be thought through and >>> addressed." >>> >>> [0] https://github.com/pulp/pups/blob/master/pup-0001.md >>> >>> David >>> >>> >>> On Wed, Aug 1, 2018 at 3:00 PM David Davis >>> wrote: >>> >>>> +1 to opening a PUP. Seems like that’s the best way to document the >>>> policy. I will start working on this. >>>> >>>> David >>>> >>>> >>>> On Mon, Jul 30, 2018 at 2:21 PM Brian Bouterse >>>> wrote: >>>> >>>>> +1 to requiring it. I also already have it enabled. Would it be >>>>> possible to either (a) turn this into a short pup and call for a vote or >>>>> (b) add a date to close this email thread decision by? >>>>> >>>>> Let me know if I should help write/review any. >>>>> >>>>> On Sat, Jul 28, 2018 at 6:09 AM, Tatiana Tereshchenko < >>>>> ttere...@redhat.com> wrote: >>>>> >>>>>> +1, enabled. >>>>>> >>>>>> On Fri, Jul 27, 2018 at 12:02 AM, Dennis Kliban >>>>>> wrote: >>>>>> >>>>>>> +1, but I already have it enabled. >>>>>>> >>>>>>> On Thu, Jul 26, 2018 at 3:53 PM, David Davis >>>>>>> wrote: >>>>>>> >>>>>>>> I got a notification from another organization I am a member of on >>>>>>>> Github[0] that they are going to require Two Factor Authentication[1] >>>>>>>> in >>>>>>>> response to recent news about some malicious code being shipped in a >>>>>>>> compromised npm package[2]. >>>>>>>> >>>>>>>> We are vulnerable to having malicious code deployed to PyPI if one >>>>>>>> of our Github accounts is compromised. Thus, I wonder if we should also >>>>>>>> require that people with a commit bit have Two Factor Authentication >>>>>>>> enabled. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> [0] https://community.theforeman.org/t/require-2fa-for-githu >>>>>>>> b-organization-members/10404 >>>>>>>> [1] https://help.github.com/articles/requiring-two-factor-au >>>>>>>> thentication-in-your-organization/ >>>>>>>> [2] https://www.theregister.co.uk/2018/07/12/npm_eslint/ >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> ___ >>>>>>>> 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 >>>>>> >>>>>> >>>>> >> >> ___ >> 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
Re: [Pulp-dev] Commit bit PUP-6
PR updated, ready for re-review. 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 Thu, Aug 16, 2018 at 1:00 PM, Ina Panova wrote: > I have opened a PR for PUP-6 [0] which describes the commit bit > assignment/revocation process. > > Please take a look to review and provide feedback. > > I'd like to call for a vote by August 28, 2018. Per PUP-1[1], are the > voting options: > > +1: "Will benefit the project and should definitely be adopted." > +0: "Might benefit the project and is acceptable." > -0: "Might not be the right choice but is acceptable." > -1: "I have serious reservations that need to be thought through and > addressed." > > Thank you! > > [0] https://github.com/pulp/pups/pull/15 > [1] https://github.com/pulp/pups/blob/master/pup-0001.md > > 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." > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] 2.17.0 RC delay.
Blocking issues were identified which prevent from building an RC. RC and GA tentative dates will be identified once blocking issues will be resolved. Please, check the release schedule page for more information [0] Thank you! [0] https://pulp.plan.io/projects/pulp/wiki/2170_Release_Schedule 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." ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Commit bit PUP-6
I tried to address all the comments and updates the PR. Please give another look and vote once you're ready! 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 Thu, Aug 23, 2018 at 5:54 PM, Dana Walker wrote: > +1 > > I'm a little concerned about the stated drawbacks, but even the > alternatives can have issues, so I think this is a good place to start and > we can amend the process later if we run into problems and/or we arrive at > a good solution to mitigate the drawbacks. > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat > > <https://www.redhat.com> > <https://red.ht/sig> > > On Fri, Aug 17, 2018 at 4:13 PM, Robin Chan wrote: > >> +1 >> I like the clarification to the removal piece. You may accept the >> suggestions if they are helpful. >> >> >> >> >> On Fri, Aug 17, 2018 at 9:32 AM, David Davis >> wrote: >> >>> Assuming there are no major changes to the PUP, I’ll vote +1. >>> >>> Thanks for putting this together. >>> >>> David >>> >>> >>> On Fri, Aug 17, 2018 at 7:21 AM Ina Panova wrote: >>> >>>> PR updated, >>>> ready for re-review. >>>> >>>> >>>> >>>> >>>> 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 Thu, Aug 16, 2018 at 1:00 PM, Ina Panova wrote: >>>> >>>>> I have opened a PR for PUP-6 [0] which describes the commit bit >>>>> assignment/revocation process. >>>>> >>>>> Please take a look to review and provide feedback. >>>>> >>>>> I'd like to call for a vote by August 28, 2018. Per PUP-1[1], are the >>>>> voting options: >>>>> >>>>> +1: "Will benefit the project and should definitely be adopted." >>>>> +0: "Might benefit the project and is acceptable." >>>>> -0: "Might not be the right choice but is acceptable." >>>>> -1: "I have serious reservations that need to be thought through and >>>>> addressed." >>>>> >>>>> Thank you! >>>>> >>>>> [0] https://github.com/pulp/pups/pull/15 >>>>> [1] https://github.com/pulp/pups/blob/master/pup-0001.md >>>>> >>>>> 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." >>>>> >>>> >>>> ___ >>>> 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 >> >> > > ___ > 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] Commit bit PUP-6
I tried to address all the comments and updates the PR. Please give another look and vote once you're ready! 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 Thu, Aug 23, 2018 at 5:54 PM, Dana Walker wrote: > +1 > > I'm a little concerned about the stated drawbacks, but even the > alternatives can have issues, so I think this is a good place to start and > we can amend the process later if we run into problems and/or we arrive at > a good solution to mitigate the drawbacks. > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat > > <https://www.redhat.com> > <https://red.ht/sig> > > On Fri, Aug 17, 2018 at 4:13 PM, Robin Chan wrote: > >> +1 >> I like the clarification to the removal piece. You may accept the >> suggestions if they are helpful. >> >> >> >> >> On Fri, Aug 17, 2018 at 9:32 AM, David Davis >> wrote: >> >>> Assuming there are no major changes to the PUP, I’ll vote +1. >>> >>> Thanks for putting this together. >>> >>> David >>> >>> >>> On Fri, Aug 17, 2018 at 7:21 AM Ina Panova wrote: >>> >>>> PR updated, >>>> ready for re-review. >>>> >>>> >>>> >>>> >>>> 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 Thu, Aug 16, 2018 at 1:00 PM, Ina Panova wrote: >>>> >>>>> I have opened a PR for PUP-6 [0] which describes the commit bit >>>>> assignment/revocation process. >>>>> >>>>> Please take a look to review and provide feedback. >>>>> >>>>> I'd like to call for a vote by August 28, 2018. Per PUP-1[1], are the >>>>> voting options: >>>>> >>>>> +1: "Will benefit the project and should definitely be adopted." >>>>> +0: "Might benefit the project and is acceptable." >>>>> -0: "Might not be the right choice but is acceptable." >>>>> -1: "I have serious reservations that need to be thought through and >>>>> addressed." >>>>> >>>>> Thank you! >>>>> >>>>> [0] https://github.com/pulp/pups/pull/15 >>>>> [1] https://github.com/pulp/pups/blob/master/pup-0001.md >>>>> >>>>> 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." >>>>> >>>> >>>> ___ >>>> 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 >> >> > > ___ > 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] Commit bit PUP-6
Voting on PUP-6 ended on August 28. The PUP passed with five +1 and no -1. Tomorrow I will send out an announcement with the link to the adopted and documented process of Commit bit assignment. Thanks all for participating! 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 Mon, Aug 27, 2018 at 2:19 PM, Milan Kovacik wrote: > +1 > > Thanks Ina! > milan > > On Fri, Aug 24, 2018 at 8:44 PM, Brian Bouterse > wrote: > >> I left some more feedback. The only substantive request is >> s/supermajority/two-thirds/ since supermajority can mean several things >> per: https://en.wikipedia.org/wiki/Supermajority >> >> Assuming those comments are addressed, I'm +1. >> >> Thank you so much for putting this together @ipanova! >> >> >> On Fri, Aug 24, 2018 at 9:59 AM, Ina Panova wrote: >> >>> I tried to address all the comments and updates the PR. >>> >>> Please give another look and vote once you're ready! >>> >>> >>> >>> >>> 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 Thu, Aug 23, 2018 at 5:54 PM, Dana Walker >>> wrote: >>> >>>> +1 >>>> >>>> I'm a little concerned about the stated drawbacks, but even the >>>> alternatives can have issues, so I think this is a good place to start and >>>> we can amend the process later if we run into problems and/or we arrive at >>>> a good solution to mitigate the drawbacks. >>>> >>>> --Dana >>>> >>>> Dana Walker >>>> >>>> Associate Software Engineer >>>> >>>> Red Hat >>>> >>>> <https://www.redhat.com> >>>> <https://red.ht/sig> >>>> >>>> On Fri, Aug 17, 2018 at 4:13 PM, Robin Chan wrote: >>>> >>>>> +1 >>>>> I like the clarification to the removal piece. You may accept the >>>>> suggestions if they are helpful. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 17, 2018 at 9:32 AM, David Davis >>>>> wrote: >>>>> >>>>>> Assuming there are no major changes to the PUP, I’ll vote +1. >>>>>> >>>>>> Thanks for putting this together. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On Fri, Aug 17, 2018 at 7:21 AM Ina Panova >>>>>> wrote: >>>>>> >>>>>>> PR updated, >>>>>>> ready for re-review. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 Thu, Aug 16, 2018 at 1:00 PM, Ina Panova >>>>>>> wrote: >>>>>>> >>>>>>>> I have opened a PR for PUP-6 [0] which describes the commit bit >>>>>>>> assignment/revocation process. >>>>>>>> >>>>>>>> Please take a look to review and provide feedback. >>>>>>>> >>>>>>>> I'd like to call for a vote by August 28, 2018. Per PUP-1[1], are >>>>>>>> the voting options: >>>>>>>> >>>>>>>> +1: "Will benefit the project and should definitely be adopted." >>>>>>>> +0: "Might benefit the project and is acceptable." >>>>>>>> -0: "Might not be the right choice but is acceptable." >>>>>>>> -1: "I have serious reservations that need to be thought through >>>>>>>> and addressed." >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> [0] https://github.com/pulp/pups/pull/15 >>>>>>>> [1] https://github.com/pulp/pups/blob/master/pup-0001.md >>>>>>>> >>>>>>>> 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." >>>>>>>> >>>>>>> >>>>>>> ___ >>>>>>> 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 >>>>> >>>>> >>>> >>>> ___ >>>> 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 >> >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Commit bit assignment.
Hello Pulpers, We have just adopted an officially documented process of commit bit assignment. We believe the community will embrace this change which we hope will in turn encourage even more contributions. For more information check out this PUP [0]. With <3, Pulp Team. [0] https://github.com/pulp/pups/blob/master/pup-0006.md ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Voluntary Resignation of the Commit Bit
Bihan, as per your request, the commit bit was removed from the following repositories: pulp/pulp pulp/pulp_docker Thanks a lot for all your contributions and project involvement! 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 Thu, Aug 30, 2018 at 2:46 PM, Bihan Zhang wrote: > Lol. Can't keep the commit bit if it doesn't exist ;) > > On Thu, Aug 30, 2018, 08:24 Bryan Kearney wrote: > >> What about pulp_flatpack? >> >> -- bk >> >> On 08/30/2018 08:21 AM, Bihan Zhang wrote: >> > Team, >> > I would like to revoke my commit bit to pulp core. Since I will not be >> > able to put in the time needed to keep up to date with the core >> changes. >> > >> > I would like to also resign my commit bit to pulp_docker with the same >> > reasoning. >> > >> > But I want to keep my commit bit to pulp_python. >> > >> > Cheers, >> > Bihan >> > >> > >> > ___ >> > 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
Re: [Pulp-dev] Pulp 3.0 RC roadmap and check-ins
Did we identify and confirm that the mentioned deadline is feasible? Or in order to complete this on time installer team members need to share the workload and commitment? 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 Wed, Aug 29, 2018 at 11:35 PM, Brian Bouterse wrote: > That all sounds great. > > re: the installer. pulp_ansible as a plugin in particular is blocked on > the installer work, so I want to identify the timeline needs there. We're > marketing pulp_ansible at AnsibleFest starting Oct 2, and we need to have > the installer be ready for users then. Additionally we have to get the > installer's roles hosted on Galaxy by then, test using it from Galaxy, work > out any issues we find, rewrite the pulp_ansible install docs to recommend > the installer, and make instructional content around after that (blogs, > demos, etc). @daviddavis and I think that's going to take about 3 weeks of > effort, which means we really need the installer with all it's feature and > documentation by Sept 7th. We've mentioned this during some calls, but I > wanted to outline the need more here. > > On Tue, Aug 28, 2018 at 4:14 PM, David Davis > wrote: > >> Last week we met and discussed a release candidate (RC) milestone for >> Pulp 3.0. Here are the high level components we identified as being part of >> this RC milestone. I’ve also put down a feature shepherd for each (more on >> this below). >> >> Core >> - Ansible Installer - @asmacdo >> - Lazy sync - @bmbouter/@dawalker >> - Katello P1 items - @daviddavis (or another volunteer) >> - Content Protection - @jortel >> >> Other deliverables >> - Supported Bindings - @dkliban >> - Pulp 3 RPM Plugin Beta - @ttereshc >> - Pulp 3 Docker Plugins Beta - @ipanova >> >> In the next two weeks, I think we should create roadmaps of the remaining >> stories for each of these items. This should also ideally include a rough >> timeline or estimate of when the work can be completed. I'm imagining that >> each team can handle this and work with @rchan to discuss any staffing >> needs/assumptions. >> >> Secondly, during our Monday team meetings I’d propose we have brief >> weekly check-ins on the status of each feature until we reach our RC >> milestone. Each feature shepherd could provide a short, 1-2 min update on >> their component's status. I think this will help us remain focused on >> getting to an RC release without taking up too much time. >> >> Lastly, I am planning on getting the remaining Katello P1 items groomed >> and added to the next sprint (unless someone else wants to handle this >> work, let me know). >> >> As always, feedback is welcome. Thank you. >> >> David >> >> >> ___ >> 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
Re: [Pulp-dev] commit-bit nomination
Brian, it feels like your reply is in contradiction of what we are trying to achieve as a community project: 1) I am concerned that this reply can be perceived very badly by the community, especially once we approved the pup and announced this in hope of community embracing this change, by encouraging new contributions and motivating them with one of the retributions of becoming a committer. 2) We cannot afford ourselves to behave like a dental clinic which will say: we are too full and we are not accepting new patients ATM. There are community projects with a larger committer base and somehow they still manage to develop and evolve. 3) Do you suggest splitting the team in 2 with the acknowledgement of the fact that pulp2 is near EOF which means those people will be pinned just for the maintenance mode? I wonder if we have such volunteers doing this job daily. Anyone? :) I agree with Dana, we adopted the pup, team has voted, now we need to deal with the decisions we as a project have made. I think Milan has met the criteria listed in the pup, and if he has systematically demonstrated diligence and commitment i do not really think once he gets the commit bit he will go right away and screw up pulp3 code base because he has less experience in that area than in another. I understand that in this email thread have popped up multiple problems we are struggling with, but I would at least try to stay focused on the initial email topic and create separate discussions for the other topics. +1 on the voting. I also solicit the team to be pro-active, so we can fail fast things which do not work out for us. 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 Fri, Sep 7, 2018 at 2:17 AM, Dana Walker wrote: > I respectfully disagree. > > I was hoping for more discussion before the calling of a vote. >> > > The process described in PUP6 specifically states that the nominating > email should have a vote end date, thus calling a vote. There's nothing > wrong with having discussion now on this thread, as part of explaining your > stance or asking questions before deciding, but voting is still actively > taking place. People can always change their vote based on the results of > discussion up to the vote end date in seven calendar days. > > With Pulp2 nearing maintenance mode, the core and plugin teams need to >> assess what their needs are both in code and people. I feel that with 9 >> people on the core team, maintaining vision is hard/impossible, and the >> mailing list discussions have demonstrated that. >> > > No, what the mailing list discussions have demonstrated is that we have a > problem with our decision making process. Plenty of projects have larger > teams, but they usually have a team lead for breaking ties and ensuring > that forward progress is made even with difficult decisions where a team is > split on what to do. The bright side is, no matter what decisions are made > on any of those discussions, the project moves forward, and can always > pivot in future versions based on feedback or with community submitted open > source work. But decisions must be made and if our lazy consensus method > where even a single -1 is blocking prevents work from moving forward and > releases from arriving on schedule, it's time we reconsider that process, > and that is a separate discussion for another place and time. > > Also consider that Pulp3 is an order of magnitude smaller codebase >> (literally) so keeping the same number of committers seems too many. >> > > Again, I disagree with this focus on number of committers for many reasons. > > 1) @bizhang just left the team and resigned a commit bit, so there is now > an opening and if there had been a problem with the number of commit bits > before today, then that should have been brought up previously, perhaps by > having no grandfathered-in committers and all team members voted on by > majority when this decision was made last fall, or perhaps by explicitly > limiting the number of commit bits in the PUP. > > 2) We just had lengthy discussions in meetings a week ago about ways to > improve the speed with which we respond to PRs. There were suggestions > ranging from email notifications of every one that is submitted, a weekly > PR triage, having subject matter "experts" designated to divide up the > work, or it being on the shoulders of the pull requesters to continually > poke channels/individuals for a response until they get one. The response > to all of this was simply that we are all too busy. Too busy implies that > there is more than enough work to go around for more people, and the only > people who can approve and mer
Re: [Pulp-dev] Namespacing plugins, looking for feedback
+1 to namespace master/detail as well.
+1 to Brian's suggestion to try.
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, Dec 18, 2018 at 12:15 AM Brian Bouterse wrote:
> +1 to namespacing all Master/Detail objects (Remotes, Publishers, etc).
> Namespacing will increase consistency w/ the user experience and will avoid
> plugin-to-plugin naming collisions. @ttereshc +1 to the url changes and
> content summary changes you've described.
>
> I think it would be ideal if the app specified its 'label' attribute on
> the PulpPluginAppconfig subclass, e.g here in pulp_file
> https://github.com/pulp/pulp_file/blob/24881314372b9c1c505ff687c15238126b261afa/pulp_file/app/__init__.py#L10
> Then the Model for, e.g. the FileContent would have the second portion of
> the string 'file' as an example and Master/Detail would assemble them.
>
> Is this implementation how you imagined it?
>
>
>
>
> On Mon, Dec 17, 2018 at 9:29 AM Tatiana Tereshchenko
> wrote:
>
>> Just to clarify, the type field is not used in the endpoint construction,
>> so two changes described in the original e-mail are independent.
>>
>> In my opinion:
>> - it is possible to have type collisions.
>> - it is possible to have the same endpoints (endpoint_name in a viewset).
>>
>> FWIW, the endpoint collision is not unique to the master/detail models'
>> endpoints. A plugin, in theory, can define any endpoint they want.
>> Though not preventing collisions it for endpoints related to
>> master/detail models makes it easier to create such collision accidentally.
>>
>> Tanya
>>
>> On Mon, Dec 17, 2018 at 2:27 PM David Davis
>> wrote:
>>
>>> Is it possible (under the current model, without namespacing) to have
>>> type collisions in the database for master/detail models? Like what if two
>>> plugins define two Contents with the same type or two Remotes with the same
>>> type? This kind of leads me to believe we should namespace everything. On
>>> the Ansible plugin for example, I started working on a git Remote[0].
>>> Luckily I chose "ansible_git" as the type but I could see plugin writers
>>> running into problems if they are not so careful.
>>>
>>> [0]
>>> https://github.com/pulp/pulp_ansible/pull/38/files#diff-debb42c875c19140793de39be3696ee3
>>>
>>> David
>>>
>>>
>>> On Sun, Dec 16, 2018 at 4:41 PM Tatiana Tereshchenko <
>>> ttere...@redhat.com> wrote:
>>>
>>>> There is an issue [0] of colliding type names in the content summary
>>>> which evolved into more general namespacing problem for plugins.
>>>>
>>>> The suggested changes [1] are:
>>>> 1. include plugin name into the content summary
>>>>
>>>> "content_summary": {
>>>> "pulp_rpm.package": 50,
>>>> "pulp_rpm.errata": 2,
>>>> "pulp_file.file": 5
>>>> }
>>>>
>>>>
>>>> 2. include plugin name into content endpoints
>>>> /api/v3/content/file/files/ --> /api/v3/content/pulp_file/files/
>>>> /api/v3/content/rpm/packages/ --> /api/v3/content/pulp_rpm/packages/
>>>> /api/v3/content/rpm/errata/ --> /api/v3/content/pulp_rpm/errata/
>>>> ...
>>>>
>>>> For the change #1, not only content summary output is changed but the
>>>> type itself in the database. If the content type is used somewhere in the
>>>> filters, it should be specified in that format: "plugin_name.plugin_type".
>>>> Does it makes sense to extend the master model and have a plugin name field
>>>> and a type field, instead of putting preformatted string into the type
>>>> field?
>>>>
>>>> For the change #2, endpoints are namespaced only for the content
>>>> endpoint and not for other endpoints related to master/detail models, like
>>>> remotes, publishers, etc. It's inconsistent, however it makes the most
>>>> sense to have it for content endpoints.
>>>>
>>>> Any concerns or thoughts?
>>>>
>>>> Thank you,
>>>> Tanya
>>>>
>>>> [0] https://pulp.plan.io/issues/4185#note-8
>>>> [1] https://github.com/pulp/pulp/pull/3801
>>>> ___
>>>> 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
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Namespacing plugins, looking for feedback
+1 namespacing all master/detail For consistency, i would prefer to see same format i see in `content_summary` as in content endpoints, even if it does not make sense from user's perspective, because what we now have in content_summary, i would not say that it makes much sense from user's perspective ;) 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 Wed, Jan 2, 2019 at 8:55 PM Austin Macdonald wrote: > +1 automatic namespacing for master/detail. I realize the easiest way to > do this would be to use the app_label, giving us: > > /api/v3/content/pulp_rpm/packages/ > > > However, I feel like this url is pretty clunky. The "pulp_" is totally > unnecessary, from the user's perspective. Instead, I think I'd prefer to > add an attribute to the App config. > > https://github.com/pulp/plugin_template/blob/master/pulp_plugin_template/app/__init__.py#L8 > > `endpoint_namespace = rpm` or `short_label = rpm` > > Result: /api/v3/content/rpm/packages/ > > The downside is that every plugin would need 1 more line of code. The > upside is that we could implement it exactly same way as app_label but > without url redundancy. > > On Wed, Jan 2, 2019 at 2:39 PM Tatiana Tereshchenko > wrote: > >> It would be automatic, and plugins need a change only to avoid redundant >> prepending. >> E.g. If RPM plugin makes no changes, the endpoint for RPM content will be: >> >> /api/v3/content/pulp_rpm/rpm/packages/ >> >> because endpoint_name = 'rpm/packages'. >> >> So plugin should leave only endpoint_name = 'packages'. >> >> The endpoint with redundant plugin name will work fine, just doesn't look >> good :) >> >> Tanya >> >> >> On Wed, Jan 2, 2019 at 7:20 PM David Davis wrote: >> >>> I am +1 to namespacing all master detail models with the plugin name. >>> Would this be automatic or something that the plugin writers would be >>> encouraged to do? >>> >>> David >>> >>> >>> On Wed, Jan 2, 2019 at 12:58 PM Tatiana Tereshchenko < >>> ttere...@redhat.com> wrote: >>> >>>> Thank you all for the discussion so far. >>>> The question - the type field and namespacing in content summary - is >>>> solved with https://pulp.plan.io/issues/4185. >>>> >>>> The last remaining question is whether we want to prepend endpoints for >>>> master/detail models with plugin label. If yes, then everything or for >>>> Content only. >>>> See details on the issue https://pulp.plan.io/issues/4279. >>>> >>>> Examples of the suggested change: >>>> >>>> /api/v3/content/rpm/packages/ --> /api/v3/content/pulp_rpm/packages/ >>>> /api/v3/remotes/rpm/ --> /api/v3/content/remotes/pulp_rpm/rpm/ >>>> /api/v3/publishers/rpm/ --> /api/v3/content/publishers/pulp_rpm/rpm/ >>>> >>>> Changes which will be needed in plugins: >>>> - adjust the value of the `endpoint_name` attribute in the viewsets we >>>> introduce changes to >>>> >>>> Please provide feedback, here or on the issue >>>> https://pulp.plan.io/issues/4279. >>>> This is an RC blocker, so it would be great to groom it over the next >>>> couple of days. >>>> >>>> Thank you, >>>> Tanya >>>> >>>> On Thu, Dec 20, 2018 at 9:41 AM Tatiana Tereshchenko < >>>> ttere...@redhat.com> wrote: >>>> >>>>> Since we are leaning towards prepending types for _all_ master/detail >>>>> models and not only for the content model, that Django fix is no longer >>>>> important for us. >>>>> >>>>> Tanya >>>>> >>>>> On Wed, Dec 19, 2018 at 6:18 PM Daniel Alley >>>>> wrote: >>>>> >>>>>> David, was that a vote to make it explicit? >>>>>> >>>>>> I would regard this as fairly intuitive as far as "magic-ness" goes, >>>>>> acceptable from the user POV in my opinion. And if Django is explicitly >>>>>> trying to support this functionality and relies on it working properly, >>>>>> and >>>>>> has a unittest for it going forwards, then I'm fairly confident it won't >>>>>> be >>>>>> too fragile. My v
Re: [Pulp-dev] QE commit bit
+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 Thu, Jan 17, 2019 at 10:18 AM Tatiana Tereshchenko wrote: > +1 > > On Wed, Jan 16, 2019 at 8:32 PM Brian Bouterse > wrote: > >> This all sounds good to me. >> >> On Tue, Jan 15, 2019 at 2:25 PM Kersom wrote: >> >>> Robin, yeap. Exactly what you described it. >>> >>> On Tue, Jan 15, 2019 at 2:22 PM Robin Chan wrote: >>> >>>> Great. I withdraw: >>>> #3. Shall we also agree that those not in [1] - in other words, the >>>> developers give up commit bit for #2. Can still contribute but don't need >>>> to be involved in #1 agreements. >>>> >>>> And to re-iterate and be very clear, Kersom's ", just to communicate QE >>>> in case of test changes. We already have a system in place on git." looks >>>> like getting an approved code review from someone in [1]. >>>> >>>> That works for me and I appreciate the clarifications. >>>> Robin >>>> >>>> >>>> On Tue, Jan 15, 2019 at 2:15 PM David Davis >>>> wrote: >>>> >>>>> I agree. I think devs can merge changes to pulp-smash tests in pulp >>>>> repos but they should get it reviewed by QE before merging--which, as >>>>> Kersom says, we've been doing. >>>>> >>>>> David >>>>> >>>>> >>>>> On Tue, Jan 15, 2019 at 2:11 PM Kersom wrote: >>>>> >>>>>> David, thanks for driving this. >>>>>> >>>>>> I agree with your suggestions Robin. >>>>>> >>>>>> All currently present on [1] should have commit bit for those repos. >>>>>> >>>>>> I think it is fine to the devs to have commit to the test repos, just >>>>>> to communicate QE in case of test changes. We already have a system in >>>>>> place on git. >>>>>> >>>>>> [1] https://github.com/orgs/pulp/teams/qe >>>>>> >>>>>> Thanks, >>>>>> >>>>>> On Tue, Jan 15, 2019 at 11:07 AM Robin Chan wrote: >>>>>> >>>>>>> A few suggestions. >>>>>>> >>>>>>> #1. QE good with [1] - you all agree these are the folks with commit >>>>>>> bit? In other words, you trust each other to do the merge with your own >>>>>>> agreements of who has expertise and when things are ready - all the >>>>>>> details? >>>>>>> #2. I would suggest we are suggesting QE have commit bit access to >>>>>>> the specific subdirectories; >>>>>>> a) pulp_file/pulp_file/tests/functional/ (in pulp/pulp_file repo) >>>>>>> b) pulp/pulp_core/tests/functional/ (in pulp/pulp repo) >>>>>>> I know this is not enforceable via the GIT settings, but helpful to >>>>>>> be explicit about as we include this in agreement. >>>>>>> #3. Shall we also agree that those not in [1] - in other words, the >>>>>>> developers give up commit bit for #2. Can still contribute but don't >>>>>>> need >>>>>>> to be involved in #1 agreements. >>>>>>> >>>>>>> Fully supportive of this effort. I was one of the folks who gave my >>>>>>> word prior to PUP-6 and see this as making sure the folks have what they >>>>>>> need to get stuff done and keeping decision making with the folks >>>>>>> closest >>>>>>> to the work (i.e. QE makes decisions about all things QE.) >>>>>>> >>>>>>> Thanks, >>>>>>> Robin >>>>>>> >>>>>>> On Tue, Jan 15, 2019 at 10:37 AM David Davis >>>>>>> wrote: >>>>>>> >>>>>>>> When we moved the pulp-smash tests out of the pulp-smash >>>>>>>> repository, we promised to give QE ownership of the smash tests within >>>>>>>> the >>>>>>>> Pulp repositories on github. I know we have a process in place to give >>>>>>>> the >>>>>>>> commit bit to contributors[0] but this promise p
Re: [Pulp-dev] pin pulpcore?
if we won't pin pulpcore we'll keep receiving such reports as #4317. +1 to option1 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 Thu, Jan 17, 2019 at 2:06 PM Tatiana Tereshchenko wrote: > With more plugins going Beta and with frequent releases of pulpcore and > pulpcore-plugin an issue with dependencies version showed up: > - plugin requires pulpcore-plugin == 0.1.0bX > - pulpcore-plugin 0.1.0bX requires pulpcore >= 3.0.0bY > - at some point pulpcore introduces backward incompatible changes and the > newest pulpcore is incompatible with the old pulpcore-plugin. E.g. > https://pulp.plan.io/issues/4317 > > It would be less of a problem when pulpcore goes GA but till then it is > not nice user experience. > > Options to solve the issue: > 1. Pin pulpcore with every pulpcore-plugin release > 2. Pin pulpcore directly in a plugin > 3. Don't do anything, we are in Beta, it will be fine when pulpcore is > GA, semver will keep us from introducing backward incompatible changes in > the Y or Z releases. > 4. anything else? > > As a side note, we already have an issue with having multiple plugins > installed if they require different pulpcore-plugin versions, so pinning > pulpcore wouldn't introduce a new problem. Again this should be solved > when we go GA, in my opinion. > > Any thoughts or concerns are welcome. > > Thank you, > Tanya > > ___ > 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] Pulplift responsibilities
I have created a team in our github organization and have added current volunteers. https://github.com/orgs/pulp/teams/pulplift/ 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 Mon, Feb 11, 2019 at 10:35 PM Dana Walker wrote: > Thanks, Dennis! > > I would also like to be part of this team. > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat > > <https://www.redhat.com> > <https://red.ht/sig> > > > On Mon, Feb 11, 2019 at 4:23 PM Dennis Kliban wrote: > >> A new mini-team should be responsible for pulplift. I would like to be >> part of that team. I welcome others to join the team or to just send >> contributions. >> >> On Tue, Feb 5, 2019 at 9:15 AM Dana Walker wrote: >> >>> Eric Helms did a great job getting Pulplift off the ground and >>> transferred it to the Pulp organization. Since then, several of us have >>> helped with PRs on it. Now the question is--who all is interested in being >>> tasked with maintaining it moving forward? >>> >>> We have several miniteams for our plugins already--should it have its >>> own or be part of another? >>> >>> Thoughts? >>> >>> --Dana >>> >>> Dana Walker >>> >>> 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 >>> >> ___ > 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] Pulplift responsibilities
I had some irc convo with Austin and as a result i removed pulplift team and updated ansible installer team with new members :) 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 Thu, Feb 14, 2019 at 3:13 PM Ina Panova wrote: > I have created a team in our github organization and have added current > volunteers. > https://github.com/orgs/pulp/teams/pulplift/ > > > ---- > 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 Mon, Feb 11, 2019 at 10:35 PM Dana Walker wrote: > >> Thanks, Dennis! >> >> I would also like to be part of this team. >> >> --Dana >> >> Dana Walker >> >> Associate Software Engineer >> >> Red Hat >> >> <https://www.redhat.com> >> <https://red.ht/sig> >> >> >> On Mon, Feb 11, 2019 at 4:23 PM Dennis Kliban wrote: >> >>> A new mini-team should be responsible for pulplift. I would like to be >>> part of that team. I welcome others to join the team or to just send >>> contributions. >>> >>> On Tue, Feb 5, 2019 at 9:15 AM Dana Walker wrote: >>> >>>> Eric Helms did a great job getting Pulplift off the ground and >>>> transferred it to the Pulp organization. Since then, several of us have >>>> helped with PRs on it. Now the question is--who all is interested in being >>>> tasked with maintaining it moving forward? >>>> >>>> We have several miniteams for our plugins already--should it have its >>>> own or be part of another? >>>> >>>> Thoughts? >>>> >>>> --Dana >>>> >>>> Dana Walker >>>> >>>> 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 >>>> >>> ___ >> 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] Changes in the Pulp 3 Upload story
+1 to facilitate the upload process. At the conferences, there have been many users pointing out how inconvenient current upload process is . 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 Mon, Feb 18, 2019 at 8:42 PM Austin Macdonald wrote: > Originally, our upload story was as follows: > The user will upload a new file to Pulp via POST to /artifacts/ (provided > by core) > The user will create a new plugin specific Content via POST to > /path/to/plugin/content/, referencing whatever artifacts that are > contained, and whatever fields are expected for the new content. > The user will add the new content to a repository via POST to > /repositories/1/versions/ > > However, this is somewhat cumbersome to the user with 3 API calls to > accomplish something that only took one call in Pulp 2. > > There are a couple of different paths plugins have taken to improve the > user experience: > The Python plugin follows the above workflow, but reads the Artifact file > to determine the values for the fields. The RPM plugin has gone even > farther and created a new endpoint for "one shot" upload that perform all > of this in a single call. I think it is likely that the Python plugin will > move more in the "one shot" direction, and other plugins will probably > follow. > > That said, I think we should discuss this as a community to encourage > plugins to behave similarly, and because there may also be a possibility > for sharing some of code. It is my hope that a "one shot upload" could do 2 > things: 1) Upload and create Content. 2) Optionally add that content to > repositories. > ___ > 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] Skipping plugin issues during triage
+1 to the proposal 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 Wed, Feb 27, 2019 at 9:05 PM Daniel Alley wrote: > +1 > > On Wed, Feb 27, 2019 at 2:08 PM Brian Bouterse > wrote: > >> +1 >> >> On Wed, Feb 27, 2019 at 2:00 PM Dana Walker wrote: >> >>> +1 >>> >>> Dana Walker >>> >>> Associate Software Engineer >>> >>> Red Hat >>> >>> <https://www.redhat.com> >>> <https://red.ht/sig> >>> >>> >>> On Wed, Feb 27, 2019 at 1:57 PM Tatiana Tereshchenko < >>> ttere...@redhat.com> wrote: >>> >>>> +1 to triage only pulp2/pulp3 core + pulp3 file plugin at that IRC >>>> meeting. >>>> We are doing it de facto anyway. It would be less !skip-!accept for a >>>> triage leader. >>>> ___ >>>> 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 >> > ___ > 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
