The actual skin would also be bad for a Medium-alike with a huge image of a tree or a house or whatever at the top since you couldn't preview it meaningfully.

I'm trying out Phame for providing companion notes to the Changelog so I'm going to file some stuff I hit. This is probably mostly stuff that we would have naturally fixed anyway, but some of it isn't totally obvious.

Yeah, that seems reasonable to me. You can already "Close Branch" today which is effectively the same action as "Freeze Release". I'm broadly comfortable with moving Harbormaster in the direction of having richer application awareness and interactions, although we'll have to think a bit about what happens when you "Freeze Release" in a build plan and run it on a commit (does it fail? get skipped? configurable?).

• Go to a Branch/Release page.
  • Click the "New Pull Request" button.
  • That goes into the queue for the Branch/Release.
  • Whoever owns the Branch/Release can approve/reject it.
  • That's the end of the workflow today since Harbormaster didn't exist and none of T182 was planned. Last I knew, Facebook completed the rest of the workflow with custom arc do-a-bunch-of-git-stuff extensions.

(The pull requests are just useless outside of the Facebook workflow because they can't merge and the "you can do hundreds of them really quickly" aspect isn't useful at less-than-Facebook scales.)

"Pull Requests" are the existing "Pull Requests" in Releeph. They're literally just pull requests. Releeph today is like 90% about implementing pull requests and then 10% about surfacing pertinent details about those requests prominently so chuckr and peers can bulk process hundreds of them per day.

Specifically, here are three workflows with different levels of mutability that I'd like to support:

(In this case I think your behavior is the more natural one and I'd probably want to tell the hypothetical future users wanting the other behavior to go build a custom version of "land" via T5055 with one million flags, and they may not really exist, I just want to have some sort of contingency plan in mind before making the change.)

Release will be as immutable as possible

A culvert is just a big drainpipe.

Per the title, the issue is that the description column on DifferentialDiff is declared as text255? for historical reasons that have been lost to the ages, but should just be text.

@jshirley, the project detail page should have a "Hashtags" field which lists the tags that will work. "/" should never be part of a hashtag. The value that will work is probably something like "team_oncall" by default, but you can customize that by adding or changing the hashtag.

Anyway, pretty much same story here as T9537 -- I want to sort out T3855 better first, then we can tackle refinements here.

I guess that won't quite do what you want since you're legitimately tracking a local branch which tracks a different remote branch in this case. But maybe you're partially doing this only because T9537 doesn't work?

I think we probably solve this incidentally by doing T3855, T9537, making --onto mean in the remote, and defaulting it to the tracked branch (although I think it already does?). The only problem with this is that land-example wont get updated but from T9537 maybe you're completely fine with that?

(And the project description can be used to document what the project means, how to respond to it, etc. And you can search for revisions with those projects, etc.)

Flags are personal bookmarks (other users can not see your flags), so I think they aren't compatible with your goal. You want everyone looking at a revision to be able to see the note, right?

I'm going to merge this into T9537, which has more discussion and an additional use case that I find slightly more compelling as a motivator (numerous targets in the remote).

Can you show me a screenshot of an example that demonstrates this problem? It's hard for me to imagine what sort of warnings are valuable enough to raise but not valuable enough to fix.

Given that, I think the fundamental feature request here is for arc land to target a temporary local branch that is used just for staging and pushing the final commit, rather than targeting an existing local branch.

I'd recommend looking at exactly what arc does and following that, rather than trying to construct calls from scratch.

Why are you trying to create revisions with a direct API call? Can you describe the broader problem you're facing? There may be a better solution. See:

The name "Pipeline" brings "Data Pipeline" to mind for me, possibly because AWS has a product called "AWS Data Pipeline", although it looks like no one else particularly likes "Releeph" either.

Yeah -- at least in HTML mail, the cows aren't getting properly linebreak'd either. I don't think that's new but it should be pretty easy to fix.

That seems tentatively fine, although it may only solve some of the problems here and may create new problems.

This may all sort of be moot since there might be a relatively unambiguous approach to T9082 and this which uses a rule like: if the target does not exist locally, but does exist in the remote, use a separate workflow.

Yeah, they're a bit different. There's some nuance here, but basically T8620 is talking about landing from a detached HEAD, and T9082 is talking about landing without creating or interacting with a local target branch (usually "master"). This is potentially talking about both, I think, although more on the T9082 side.

I think this is about the same as T9082, does that sound right? (Is that a report from another team member on your team? This workflow seems completely unorthodox to me, although maybe it is less bizarre than I imagine.)

I'm pretty sure that if execx() an editor like vim or nano, whether you use bypass_shell or not, it just executes it uselessly in the background and hangs forever. That is, the behavior of these two programs is very different on Linux, and I believe it will be very different on Windows no matter what bypass_shell is set to:

How does that obsolete PhutilExecPassthru?

D1938 is the actual origin, I think.

Oh, that diff just moved it, so it's actually older than that.

Possibly. We've used it in PhutilExecPassthru since D6774.

D14246 / D11396 / T6966 are about a specific Windows issue where the command name is treated differently from other arguments. That is, these commands mean different things:

whether upstream wants to wait until it can tackle the generalized problem, or whether you'd be okay chipping away at smaller use cases first,

Ideally, just use a mail client with filters that are powerful enough to do full header matching.

providing an option to send email to a mailing list address associated with a project

Haha, no problem. I just mean:

Is there an unavoidable cost to keeping QA environments up for multiple days?

Yeah, this is still feeling pretty reasonable to me after thinking about it for a day or two.

This is definitely confusing and something we should fix. (We may get it from T9132 cheaply.)

I also sort of vaguely want to just rename Releeph to "Release". I don't actually know the origin of the name but I don't think it makes sense? It's just a word that sounds like "Release" but has an "f" in it? Why isn't it "Relieph"?

(I can also make a Community Skunkworks space or something for nefarious plotting if scope expands here, but I think there's good alignment with my vision for Releeph, triggers like Pipeline, your actual requirements, Harbormaster/Drydock starting to get useful in general, and plans for letting Phabricator do repository writes in T182.)

Oh, I actually meant "Releeph Branch" not "Releeph Product", I think. Products are like "The iPhone App", branches are like "The iPhone App, 2012 Week 29". Branches could be renamed to "Releases" reasonably.

There is a similar problem elsewhere of roughly "which of Debian Jessie, Debian Kraken, and Debian Longhorn is this bug fixed in?", where releases are mutable, and our stable "releases" are also mutable, and Facebook's www deploy is mutable, and Releeph currently spends most of its effort on making products mutable. But it makes sense that a large class of releases might reasonably be modeled as immutable, especially if they have meaningful build steps.

Broadly, here's where I think the closest mappings to roadmap/starmap stuff are:

In your situation, are releases mutable or immutable? That is, if you create release 3.11 and discover a bug in it, do you merge/cherry-pick the fix into 3.11 or do you throw 3.11 away and create 3.12?

Specifically, I think your ultimate call parameters should look something like this, if you are purely reporting coverage and not test results:

Yeah. If we did the bar UI, I think the length of the bar is just "U + C" (divided by the longest bar shown on the page, I guess? Or like log-base-something of that so the absolute length of the bar always has about the same meaning?) with something like "C / (U + C)" percent of it colored in.

See also:

Yes, you can use harbormaster.sendmessage to report coverage information and unit test results. The API call has fairly thorough documentation on the console page:

I'm tentatively OK with upstreaming that if we can find a way to present the data that communicates both the coverage percentage and total line size of each directory. In the screenshot above, the current directory might be nearly uncovered if async_diff/ has 95% of the code, or well on the way to coverage if submit_queue/ has most of the code, right?

Phurl is a prototype application. See:

Well, that was easy.

Oh! How could I forget about this unique, distinctive logo?

I don't think we actually have a vector version of this -- the original was through 99designs in 2011 before we had a real company and I was much more interested in getting a logo idea than a production-quality set of assets, as I figured I could always go trace the thing in Illustrator later given my boundless innate artistic talent:

Short answer is: yes, eventually, but it's not something I plan to prioritize in the near term.

I can't reproduce this:

D14243 should fix this. You can cherry-pick it safely if you don't want to upgrade yet, although cherry-picking changes to the Celerity map may be tricky.

I can get this working over HTTP by just removing the special casing around the "unbundle" command. However, doing this prevents hg from emitting errors from commit hooks.

Yeah, that makes sense. Neither Travis nor CircleCI appear to support Windows at all, nor does Codeship, nor did ship.io before shutting down. And all of them just build off GitHub. So I think these are all very low-complexity build systems from the Harbormaster / Drydock / Jenkins / Bamboo perspective, but it makes sense that a lot of consumer web software doesn't need more than "build master off GitHub on linux".