[fred_durst]

> I did get a “pull request welcome” response on a legitimate bug, which is an anti-pattern in the open source world.

Can someone explain why this is an anti-pattern? Is there some sarcasm I'm missing? Seems like exactly the kind of response I appreciate when I submit issues in open source projects.

[cheald]

"Pull request welcome" usually means "This is a legitimate bug, but I don't care enough to fix this for you."

Some people believe that maintainers should fix all bugs that are reported to them. Other people believe that the open-source nature of the software should cause people to fix their own bugs and contribute the fixes back to the project, and both camps often believe that demands on their own time and effort are unreasonable.

[mpdehaan2]

Fortunately it doesn't for us.

In our case, one of the things I want to do is run it as a fully legitimate open source project.

In this case, we're going to be open and say when we can't work on something, or when we're unlikely to work on something, because we've got those 800+ contributors at or door asking for things.

There's a lot of triage.

In the past I've seen other projects take a few alternate routes - leave everyone hanging (unfair) or auto-merge everything (unstable). So that's kind of where we're at.

We do recognize we don't have /limitless/ resources, but this is kind of what you get for having a project on GitHub with so many stars and forks.

The user and testing community is absolutely awesome, but I when we say we aren't going to do something, it's because we want to be clear where we stand or have a conversation, or encourage people to contribute.

As Spock said "the needs of the many, outweigh the needs of the few or the one". Triage!

[staz]

This is not a problem of entitlement where people expect that you fix their bug for them. This is an anti pattern because many people consider this type of answer rude and it doesn't create a welcoming community.

Saying "This is a legitimate bug, but I don't care enough to fix this for you." is already an order of magnitude more polite than "Pull request welcome" or the older "Patch welcome" , explaining in details why and if necessary how open source work even more so. You have to remember than not every one know the Open Source community speak. If you can guide the reporter on how to create said pull request, even better.

Yes its take more works and it's less fun than hacking at code, but building a great community is a lot of works. It's also, for me at least, what separate good projects from great ones

[mpdehaan2]

Yeah, but it's not the same thing.

This is a legit bug results in the bug staying open.

Pull requests welcome is "I feel this is a feature, but we'd be open to you working on it".

I think one of the great tragedies of the internet is people assuming people say things they don't mean.

And yes, building a great community is a lot of work, and it's something we spend a TON of time on. And it's why we have one of the most contributed to projects on Github.

Getting to 810 contributors is really hard, and you don't do it easily :)

[fred_durst]

EDIT: It looks like you did a quick edit to clarify your response. I think I understand that now. Thanks.

[ryan_lane]

In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. After I pointed out why this was in fact a valid bug, the bug wasn't reopened, but instead left closed while I was told "you're welcome to submit a PR". Basically I'm being told the bug isn't important enough for the upstream to fix and that they care so little about the bug that they won't even leave it open for someone other than me to fix.

It's generally considered a rude response in the open source world because it's telling users they aren't worth your time. It's a warning sign of an unfriendly upstream.

[mpdehaan2]

Hi Ryan,

I'm sorry you feel that way. In our case, we get a TON of bug report traffic - many are just user questions which we'll direct to the list, some are just nice to haves, we file most of the good ones, but not always.

Though I would consider performance tuning of the user module not a bug, and I do not think the newline behavior of copying the file on the filesystem was a bug either.

A discussion on ansible-project would have been welcome after you felt we had taken the wrong track, but when we feel some requests aren't worth our time, it's because we have a huge audience to serve and are triaging everything.

We feel it would have been unfair to you to let it sit infinitely when we were unlikely to spend time on it.

[ryan_lane]

Yep. I understand that, but part of having an open source project is that others may find open bugs and decide to fix them because they're also having the same issue. Closing legitimate bugs hides them from the world and also gives people the impression that it's not something to fix.

The performance issue was very likely one of the more major deciding factors. Managing users was so slow that it was painful to do small iterative development. Slow performance is definitely a bug.

[mpdehaan2]

I think it's something that can be improved, yes. I'm not sure it's a bug, and I'm not sure it's really all that slow. We're talking about 0.5 seconds and maybe it could get down to 0.4? If you dig into the module I'm not sure what you would change. (Again, a fine discussion for ansible-devel probably? How would you solve it?)

In your case, managing a list of 80 users to be sure there or not, I might have suggested perhaps tagging that action and only running that every so often, but I do think that, in general, it wasn't a pressing thing for us.

There are going to be occasional tradeoffs to the way the task system does work (ability to be split declarative/imperative), but those are some of the prices to be had for the flexibility that can by (like "register:" versus the limitations of a server side compile up front).

I think I'm ok with that, all being said. It's how ansible came to be.

There are choices that you take building things one way versus another, and if we're down for time for a coffee and three spins around the office chair, or time for coffe and two spins around the office chair, it's still in statistical noise territory.

We have spent a lot of time optimizing the HECK out of the SSH transport, but no matter what, almost all deployments in any config tool, the majority of the time comes down to waiting on yum and apt. And yum and apt are brilliant and I love them, it's just where things lurk :)

[ryan_lane]

As a comparison, Salt checks the users, groups, ssh keys, etc. in under 1 second. Ansible to do the same set of actions was taking nearly 2 minutes. This was just to check, not even to take action.

So, yeah, the majority of time in an initial run is waiting on apt/yum, when nothing is changing the majority of the time is spent on checking things.

When you're making config management a part of your application's deployment process, waiting on checking is painful. This would have added 2 minutes to deployment time. When we doubled the number of users managed it would add 4. That's a really, really long time.

[jsosic]

CM tools are not supposed to do the deployment but configuration and management of environment. You should do deployments with a tool like Jenkins.

[reality_czech]

Ansible seems like a cool project... thanks for stopping by here.

One question, though. 0.4 seconds seems like a very long time to query one user/group, though. You should be able to query thousans of UIDs a second, minimum... unless you're using LDAP and you have a slow network or something. You could write a simple C program to query a bunch of UIDs and I bet it wouldn't even take a millisecond to run. So where is the overhead here for ansible? I apologize if this is a dumb question... I am not very familiar with the architecture.

[mpdehaan2]

it's definitely true that most of our users are deploying configs and applications so there's not a lot of user management, but the user management is definitely robust.

We're using GNU user tools in many cases for correctness and efficiency of not reinventing the wheel so you might wait a little more for them.

We're open to tuning but it's really not been a problem.

It's still statistical noise in the end, and, yeah, like we said, we've got more important things to work on first. It would be nice if we had time for everything, but this just doesn't rate in the grand scheme of things right now, still.

Someday, perhaps! Meanwhile, try things out, I don't think this will matter in practice for most folks :)

[fred_durst]

> In this specific case I submitted a bug and was told the bug wasn't valid and it was closed.

Maybe that is what you might have said in your blog post instead of a snarky comment. Remember, many people in open source are not from the upper middle class United States / West Coast and will likely not pick up on clever passive aggressive jabs. I completely understand that they are great for being able to deny any accountability for your attacks, but it generally leads to a lot of misunderstanding. Especially from those who do not speak English as their first language.

I really don't mean this to jump on you, but hopefully you might take it as some advice when dealing with large distributed projects that passive aggressive snark, I would guess, ends up actually going over the head of 50% or more of the people.

[ryan_lane]

It wasn't meant as snark or passive aggressive. It's a common topic in open source projects, but it's possible that I was speaking towards an audience that already knows the topic. Sorry if I hadn't explained well, that's my failure.