That looks really useful. With such a view, perhaps the existence of inline comments that are Not Done can be a blocker for arc land.

In my jenkins setup, I wanted to keep auth, so I did this:

• Disable all the Build With Tokens options
• Enabled Jenkins SSH-CLI plugin (Which lets you SSH into it and run commands)
• Wrote my own "start a build" command, which is also returns enough information to keep track of the build (Queue ID, which the http-invoke method does)
• Wrote a JenkinsSSHBuildStepImplementation that uses that build via SSH, and has a funny JSON field for the arguments.

this relies on the "run with token as root" extension (https://wiki.jenkins-ci.org/display/JENKINS/Build+Token+Root+Plugin) which mostly bypasses other authentication mechanisms. This isn't that much of a problem in our environment, but is clearly non-optimal

yeah, there is an option to enable building via a specific URL and a GET request. Cool

after a deeper look it seems there might be an option to use a token for this. Let me play around with this a bit more

I think this is a perfectly reasonable capability to want in the general case, I just want to make sure that this isn't a big fancy solution to a problem that could also be solved by checking a checkbox or making a one-line change to the build or whatever. Definitely possible that most Jenkins users are just doing very basic stuff with it, though.

I suspect that others don't need parameters in the kickoff process? Let me look into it. Maybe we have not explored Jenkins in detail.

I'm not super familiar with Jenkins -- what makes this job require parameters in the body? Other users seem to be using Jenkins successfully without requiring this capability on the Phabricator side, as far as I know.

We're targeting jenkins. We just need to kick off a jenkins job.

Ah, that one's easier.

plain old www-url-normal-web-form-encoded

@eadler, does your use case need a fancy content type like application/json, or just plain old www-url-normal-web-form-encoded?

Ah, I didn't even notice there was a sorting criterion.

I don't think this is a sort stability issue: we're preserving the order which the user who entered the tags originally used (in this particular UI it looks like we actually use reverse order, which I'd consider a bug, but other UIs like the "Tags" in the rightmost column and when editing the tags via "Edit Task" we use the original order).

The reason we require it upfront is that it's a large support burden to ask for this information. It costs Phacility money. If users provide it upfront, we spend less time on support and more time building Phabricator. If you're a frequent contributor, this obviously compounds and make providing support even more cost effective. We just want to be able to provide everyone with free support. See also T9212 for longer discussion.

I don't know if this is a bug report or feature request. It's missing information for both. Please read and follow Contributing Bug Reports and Contributing Feature Requests for how to file stuff into the upstream. How can we make it more clear this information is always required?

In T4316#49406, @epriestley wrote:

The comment should be merged into the same row if you perform an edit and then leave a comment, as long as it takes you less than 2-3 minutes to write your comment and no intervening activity takes place.

@hach-que I have understood that Windows is not the best OS for development, on the other hand you cannot ignore users that use this OS.
Anyway, what can be done in order to fix that ? what do you want me to do ? please be practical. I don't have any budget from the company right now so paying Phacility is not an option right now. I am very talented developer :)

We're going to likely move the hierarchy and give you control over what it shows. Merging in favor or T8552

Ah thanks, thought we did but couldn't find it since "subproject" was spelled "sub-project"

In T10915#188338, @epriestley wrote:

Just to be completely sure I understand this:

Since the switch to the point limit, we haven't been able to do that.

You can do this by noticing that X is greater than Z, right? You'd just prefer that the UI turn red too? Or am I still misunderstanding, and there's some actual information missing beyond the red color?

T11102 is identical

I have no idea what percentage of phabricator current or future users will be task-count-centric rather than story-point-centric. Speaking generally, the Kanban ideal would use task counts, not points. (As compared to the Scrum and XP ideals, which would use points.)

Just to be completely sure I understand this:

@epriestley, I'd like to add a bit of extra support for this request. We used to use the column limit to see when we had too many tasks in a certain column. Since the switch to the point limit, we haven't been able to do that.

What about using the batch editor instead?

You can use --verbatim to cause this update.

Just to clarify, workboard columns with a limit should currently show text like this in the header:

The specific request of the WMF teams is for the workboard column WIP limit to be measured in task count rather than story points. We have been directed to this task for that request, although it's not clear to me that they are actually the same thing. We really don't want to treat tasks as if they had a story point value of 1.

If you can identify why sudo was broken and what you did to fix it, we can probably add a setup warning to test for this problem. However, since we haven't seen other users with broken sudo and we couldn't help users resolve the issue with available information even if we did detect it, I don't think pursuing a check in the upstream is worthwhile.

You should talk to whoever administrates your install. They may have it locked.

@chad Thanks! And thanks to @epriestley, too. When I tried that, I got error "You do not have permission to configure forms for this application"

In T10915#173714, @epriestley wrote:

You can set a global default in Edit Task → Configure Form → Edit Form Configuration → Change Default Values → Type Some Number → Save Defaults.

There has been some discussion about this request in T120042. It would be very useful to some teams that I work with as an Agile Coach for them to have the ability to limit work in process in columns by number of tasks rather than points. That is their workflow which Phab used to support, and the change has led to some confusion about how much work is in process.

Usage Exception: Linter 'versions' specifies invalid type 'libversion'. Available linters are: csharp, chmod, composer, filename, xhpast, csslint, gjslint, coffeelint, cppcheck, cpplint, flake8, golint, hlint, jshint, jsonlint, jscs, lessc, pep8, php, phpcs, puppet-lint, pyflakes, pylint, rubocop, ruby, generated, json, merge-conflict, nolint, phutil-library, script-and-regex, spelling, text, xml, checkstyle.

MSIE behaves better:

thanks, that clears it up for me!

Feed, from here:

Is this only on /feed/ or on other pages as well

Regular comments and inlines in differential, and records in Feed.
Does not reproduce in Maniphest.

maybe you can post screenshots so I don't have to guess what we're talking about.

Yeah, inlines too

So regular comments on the feed page, nothing to do with differential or inline comments?

Regular comments, not inline comments (Although I haven't checked those yet).

So feed and differential inline comments?

@michaeljs1990, is was actually not possible to install PHP5 on Ubuntu 16.04 through a safe means (an apt repository or similar) for some time.

Ha! It's bad in the feed page.

Sounds like this is resolved? Or should we attempt to catch this case?

Or are you just concerned that they may make mistakes

The whole "identify the packager problem" with composer is indeed a big one and i'm not suggesting you use composer in any way for the arcanist/phabricator packages! Generally i agree that i want to primarily trust the packager and not the developer. This is the way this is handled with os packages (rpm/deb) and companies are used to the workflow: Getting new packages from a somewhat trusted/signed source (e.g. redhat/canonical), testing them yourself, signing them with your own key as well and then distributing to the internal repositories and "end users" only trust your own internal key.

(You can't write "Run Build Plans: ..." personal rules, but you can write them in object rules, which isn't too much different.)

It's also probably bad/inconsistent that you can run builds via Herald which you could not run via the web UI.

I have mixed feelings about relaxing this. I think there are basically two parts to this:

I generally expect all signing to be external, at least for the foreseeable future.

It might be beneficial to generally support gpg signed commits / tags in phabricators git repos and then use the same mechanism for the arcanist packages.
Since github recently started pushing this feature a bit (https://github.com/blog/2144-gpg-signature-verification) quite a few library maintainers started signing their release tags.
And i just recently spoke to a lib maintainer about extending composer to verify all packages (on install or upgrade) against a list of authors trusted by the user (or an enterprise wide list).

It seems likely, as well, until php 7.1 is officially supported that you probably don't want to sign-up for some potential pain points by choosing to roll the dice.

Thanks. Appreciate the quick fix on this.