fails for my MacBook:

Thank you for replay.
Umm..., Reproduce with the same procedure on my environment.
It may depend on the client environment.

It would be useful to extend this concept to the lifecycles of other Phabricator objects, not just Maniphest tasks. For example, people on my team have sometimes wanted to see a histogram of how long it takes Differential diffs to get reviewed, especially if we can break it down by author and/or reviewer.

No problem, thanks for the report!

Thanks for a fast response!

I'm going to declassify this too since there's nothing private.

Oh, you're right. I misread an implication of implementation specifics into "set", but the actual language doesn't actually suggest an implementation.

I tried to not specifically ask for a change to API or parsing, just that the missing bit I need is a base revision set on the new diff.

We're happy to take a patch, too!

In T8845#214252, @SvHu wrote:

It's pretty big deal for us because we are using phriction to collect helpdesk FAQ. We have modified TOC to be displayed in the beginning of the page and would like to use ponder are storing questions. Atm using ponder links in phriction as headings also shows toc values as X.

From above, I think there are really three use cases here:

And hg export is mostly the same deal as git format-patch.

T12618 could be accomplished by parsing hg log --patch --rev <rev>, which is similar to git show.

A maybe-less-complicated approach here could be:

Also, projects in this world are not allowed to explicitly manage their dependencies since other teams need to submit newer and newer versions and you NEED to build against whatever code they submit to the build. I think Phabricator is approaching build with the assumption that you can use a dependency manager like pip/composer/name-your-favorite-here and that a project can explicitly manage its dependencies and their versions which is just not true when building any OS.

(Although that gets into a whole other mess.)

We could reasonably give you the hash we expect the ref to contain, and should do this anyway as a correctness check to make sure someone hasn't --force pushed something else over it to do something tricky.

But maybe the systems I'm aware of are all just toys for building web apps and all serious systems programmers use branch names to manage dependencies, but this is a very hard sell for me. Perhaps I'll have a change of heart eventually.

Given all of the above, why is repository.staging.ref provided as a Harbormaster build variable?

That was unclear: we can parameterize on lots of things, just not the commit hash, which is conceivably what you want us to parameterize on.

@nervus70, I use satis to do this and it works fine with phabricator. You should easy be able to use https://secure.phabricator.com/api/diffusion.repository.search to generate the satis config if you have a ton of repos.

I have a related question regarding this quote:

This isn't a good fit for the upstream.

Is exposing this information in conduit which Phabricator already stores that bad?

For reproduceable builds we only need to be able to reproduce official builds and for that the central build team stores all the tags and projects submitted to each build for a given train.

Commits may be on multiple releases but issues are reported from a platform that is associated with a particular sdk/release. Engineers work backwards from there. In addition, for us every commit message has a tracking ticket in it as well and the official build system updates those tickets with information on where it got incorporated when etc.

For someone debugging on their desk they will normally build with the latest sdk for that release or if they suspect some issue related to build then they will use the sdk generated from when that commit was built in the official (internal) release.

Today, how do you build any commit which isn't a branch head (for example, to bisect a bug to a commit which introduced it)?

Dependency information between projects in the real build team is kept for the general project a needs b and c and when that new dependency is introduced. They can update this before a build by looking for any new dylib/static lib/header dependencies that were not there before and looking up what project produces that file. They do not have a version level dependency since teams don't always coordinate like that unless an API breakage is coming. Even then the build team may roll back a projects submission if it causes other teams to fail to build in the official nightlies.

You may be right, that the root problem is people putting to much content in Phriction articles. But even a need content seperation like this one

This makes it impossible to build after branch heads move forward, but presumably you already have a solution for that or you would be unable to repeat builds in the general case.

So branch names are basically a key into a big map somewhere else which stores the actual complicated dependency information in a normal way and is probably backed by a file on disk somewhere?

We already build reviews after they land since it's now obvious to our build system what it needs to do.

The ToC is a currently a bandaid to a design problem, that people put too much information into a single page due to lack of alternative choices. Our solution moving forward isn't to just improve the ToC, but to improve Phriction overall and allow more CMS level customization (like a permanent sidenav). Knowing why so much information is placed on a page is the root problem we're looking for. If we just improve the ToC, I don't feel we're solved the root problem.

There's two parts to the process (being transparent here). For official builds we submit tags to the "real" build team for a given release line. The submission info contains any new dependency information etc. Teams tend to generate these tags from branches with names matching the release code name.

So happy that this is now being discussed again. I have almost the same use case is jcarrillo7.

(If not, how does OSv977 know that it depends on HTTP-v224, Scheduler-v416, Documentation-v84, etc?)

So when you cut a new minor release of your OS (say, v9.9.7), you go to every single library/project you depend on, cut a minor release there with the exact same version number, and create a branch with exactly the same name?

We don't consider that to a be a root problem.

We adopted this convention (instead of a file containing the mappings or settings etc) because we have many many major versions of the OS we have to support with fixes and it's for all developers to just create branches with a specific scheme instead of constantly updating a file everywhere or having to look in a file to know where this code will go.

The root problem is clear: The ToC is useless in a highly hierarchical Phriction article with many nested headers.

@epriestley calling it a odd use case is a little rough. It's quiet common in the systems programming world. Especially when you are building operating systems. The main reason for the branch naming scheme is that we have multiple sdks being produced (one for each version of the OS). There are multiple versions being developed for release (master may have moved on to far future work and it's sdk is no longer compatible when building another branch that branched because a release is coming soon). Even the sdk is being used is built iteratively from the results of other projects completing their build.

No no, I am wrong. I did plan this into the mocks.

No plans to move forward with this.

It does include this direction (T9868), so I'm looking forward to this.

The state transitions are a bit tricky. "Plan Changes" temporarily sets the status to "Plan Changes", but does not "address" (internally, "void") individual reviewer state on its own.

So by going through a Plan Changes status it would "clear" or "address" the prior Request Changes status?

I believe you can arc diff --plan-changes if your intent with (3) and (5) is to partially address feedback but not return it to me for review.

That is, the expected state at (6) is:

Okay - wanted to double check

The revision was created on 56dd1b297c3e5cdbb477acc7435d6aa5749f33f2. While at that same revision I had updated the diff.

Oh wait. That is expected. The assumption is that the "one last change" in (5) is a response to my reject in (2), and that I need to look at it again.

That's not expected, but sounds like D17653. Did all the actions happen at rP517372a1?

A small update on this topic.
The diff I have submitted above in P1853#4950 is not working anymore since rP45b386596e62.
The corrected patch would be:

--- a/InsecureRemarkupGraphvizBlockInterpreter.php      2016-02-24 08:47:54.517183033 +0000
+++ b/InsecureRemarkupGraphvizBlockInterpreter.php      2016-02-24 08:51:02.784873997 +0000
@@ -41,11 +41,14 @@
           $stderr));
     }

I'm not sure if what I'm seeing is a bug or expected (or even if related to this). We have sticky accept set to true (just as default).

Adding the file should fix this error, but we'll almost certainly break it again when we go to 800x800 without a test.

Basically, we routinely double the size of transforms. When we do, we also need to replace default-111x111.png with default-222x222.png so we have a fallback. We have failed to do this ~every time we've doubled things since it's impossible to know/remember, so getting test coverage seems like a good idea.

oh i see... so I just make one for now?

In D17295, we changed the "profile" transform to generate 400x400px images instead of 200x200px images. When we add or change a transform, we need to include a default result file for that transform which can be used as a fallback if the transform fails (most often because an install does not have gd, but possibly because of a corrupt image, inaccessible file storage, etc). That change didn't update the default result file, resources/builtin/image-200x200.png, so we were left with a 400x400px transform but a 200x200px unused default image that were not linked to one another.

Er, sorry, what mistake did we make again? I can’t find 400x400 ever
existing?

Also javelinjs.com currently has bogus DNS, and there's probably no value in continuing to support it for the moment. I'll keep the bills paid on the domain in case we eventually revive Javelin as a standalone framework, but we could safely drop it from config.

I think the upstream actions are probably:

I don't see a 400x400.png anywhere in builtin history.

I suspect the reproduction steps are something like:

How can we reproduce this locally?