Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

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

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

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 P

Re: [Pulp-dev] Improving technical decision making

On Wed, Apr 4, 2018 at 12:48 PM, Brian Bouterse wrote: > The lazy model is lazy, but I don't think it's ineffective. If there are > issues with the lazy consensus model, let's talk about what those are. > I dub this problem the "lazy veto". If there is a choice is between "do something" and "don

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

> > >> 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 e

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

All this looks good to me, ty so much for organizing. I left 1 inline comment On Wed, Apr 4, 2018 at 3:23 PM, Austin Macdonald wrote: > David and I went through all the pulpcore issues that have the "Pulp3 MVP" > tag. > > We added this one to the sprint: > >- https://pulp.plan.io/issues/3545

Re: [Pulp-dev] Improving technical decision making

On Wed, Apr 4, 2018 at 6:48 PM, Brian Bouterse wrote: > The lazy model is lazy, but I don't think it's ineffective. If there are > issues with the lazy consensus model, let's talk about what those are. > Adding a new, second process to-the-side I think will only muddy the water. > > I believe in t

Re: [Pulp-dev] Improving technical decision making

> The lazy model is lazy, but I don't think it's ineffective. Important topics have stayed open to debate for months at a time. I'm still frustrated by having spent over six months trying to resolve open questions about the Pulp 3 installation tooling, and coming to absolutely no conclusion. There

[Pulp-dev] Pulp 3 MVP Issue Cleanup

David and I went through all the pulpcore issues that have the "Pulp3 MVP" tag. We added this one to the sprint: - https://pulp.plan.io/issues/3545 These two need to be updated before we can move forward: - @dalley https://pulp.plan.io/issues/3505 - @asmacdo https://pulp.plan.io/issue

Re: [Pulp-dev] Removing id_in_list/href_in_list

+1 remove tag +1 remove mention from MVP On Tue, Apr 3, 2018 at 12:30 PM, David Davis wrote: > In the MVP document, we have several filtering user stories that call out > an id_in_list filter. During our sprint planning, there was a suggestion to > leave this out until after the MVP. I think one

[Pulp-dev] Demos switching to pre-recorded videos

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 update

Re: [Pulp-dev] remove AUTHORS

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

Re: [Pulp-dev] remove AUTHORS

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 t

Re: [Pulp-dev] Improving technical decision making

The lazy model is lazy, but I don't think it's ineffective. If there are issues with the lazy consensus model, let's talk about what those are. Adding a new, second process to-the-side I think will only muddy the water. I believe in the benefit of asynchronous decision making for open source proje

Re: [Pulp-dev] remove AUTHORS

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 alternativ

Re: [Pulp-dev] Improving technical decision making

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

Re: [Pulp-dev] remove AUTHORS

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

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,

Re: [Pulp-dev] Improving technical decision making

On Wed, Apr 4, 2018 at 9:01 AM, Brian Bouterse wrote: > I'm not ready to pursue a single decision maker model for Pulp's technical > decisions or community leadership. > OpenStack tech leads aren't "single decision makers", they are a fallback for when consensus isn't reached. In theory the role

Re: [Pulp-dev] remove AUTHORS

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

Re: [Pulp-dev] remove AUTHORS

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

Re: [Pulp-dev] remove AUTHORS

An extra +1 based on David's good points. --Dana Dana Walker Associate Software Engineer Red Hat On Wed, Apr 4, 2018 at 9:12 AM, David Davis wrote: > There are problems I see with the AUTHORS file: > > - It exposes personal info. It makes it eas

Re: [Pulp-dev] remove AUTHORS

There are problems I see with the AUTHORS file: - It exposes personal info. It makes it easy for headhunters to reap email addresses. - Currently it’s out of date and authors are missing (e.g. @dawalker) - It’s badly formatted. It looks like it’s somewhat alphabetical order but the last entry is M

Re: [Pulp-dev] Improving technical decision making

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

Re: [Pulp-dev] remove AUTHORS

One reason to keep the AUTHORS file is that it allows contributors to specify their contact info instead of just linking to their GitHub page, were they might not have an email listed. I assume this discussion is restricted to pulp/pulp. The plugins are free to handle however they prefer. Persona

[Pulp-dev] remove AUTHORS

Hello Pulp Team, Recently, I have opened a PR to remove the AUTHORS file [1], and was suggested to bring it up here. Please let us/me know what you think about it. Any feedback will be appreciated. Happy Wednesday, Irina [1] https://github.com/pulp/pulp/pull/3393 __

Re: [Pulp-dev] Improving technical decision making

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