I don't think the current feed UI looks good in blue header, which is why I haven't moved it over. I'd need to fiddle with feed-view

Yeah I just didn't want to add the (...) view to DiffusionHistory if it's going to slow those pages down. I'd just leave the feature out.

@chad, I'd ideally like to put a "view more" on the feed on the project page so that the original issue here (wanting to page back in history) is easier to solve. This is what it looks like right now:

I think using a Pool (like HandlePool) is not too much more work (at least, if I'm implementing it) than AJAX it and will be useful in more cases. I believe we need the Pool implementation regardless, sooner or later.

@epriestley maybe this should just AJAX?

I think D18025 reasonably covered the immediate request we received, so just kicking this off the board until the next Phriction iteration.

lol, sigh

A handful of users had created Conpherence threads to help the community find HP printer fax support. I destroyed these threads manually. There's currently no "Can Create Threads" permission and I probably wouldn't want to lock this down today since we get some legit uses out of it too.

Or maybe even more specifically, I want to be able to tell a story on each commit in History. From start to finish every place code went or came from before it ended up in the repository.

Cool, I'll update the docs.

Your suggested edit is correct, "disable" meant "switch to No I/O" but is misleading here.

That could work too. Perhaps a box of donuts instead though.

A similar issue is that after configuring phd.user, you automatically get an SSH URI that won't work without setting up the other pieces required for working SSH clones. It's probably a little tricky to test all the various pieces, but maybe attempt a sudo -u <vcs-user> git help or something and create a setup issue on failure?

I think that should fix things, but yell if I missed anything or made it worse or whatever. Thanks for the report!

Another approach might be to do T11934 first, and then implement this as /accept-magnainmously. This would be very hard to discover, but it's possible that ~10 users worldwide are meaningfully impacted and I could send them each a nice fruit basket with a card explaining the feature.

In T12758#225035, @epriestley wrote:

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".

I'm hesitant to pursue this today because I want to be cautious about adding too many actions, and I think other changes may add more valuable actions ("Accept Next Update", draft-state actions from T2543, etc). This action would probably be fine today in isolation since the dropdown doesn't feel too cluttered right now, but if we added it I think it might be the least valuable / least frequently used action in a list that is starting to look pretty bloated six months from now.

(I think it's also somewhat hard to pick a 2-3 word phrase which clearly describes how this potential action differs from "Accept" -- I can't come up with anything good offhand.)

The major motivation for --no-discovery was to avoid this problem:

See also vaguely related T12590.

For git, is that because discovery only happens on the Almanac device on which the repository is bound to or is it because there is some sort of global lock taken for repository updates? I'm curious to learn more bout how this works.

Actually, "no longer necessary" might be overbroad. If you have some really bizarre setup with Mercurial repositories, --no-discovery might save you some log spew in some situations. But assuming you're all git, it should no longer do anything in any valid configuration.

Thanks.

@nemobis - um, you've ever been in enterprise software dependent business? I do consulting for companies that pay thousands euro per year per single solution (having 5-10 is norm) and within that they get sometimes as much as "3 free support ticket" or "50 free support tickets and 3 voting points for features". I personally developed some back-end solution to deal with one problem that started happening in version 4 of one software and got fixed after ~6 years. In version 10. why? because "this problem impacted only 17% of our customers and can be fixed manually. to have fix developed specially for you, pay us ~20x as much as you pay per yer per licence". And that.is.considered.normal.

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".

Yep, those repro steps look right to me.

FWIW, a check-all box is what we had in mind.

I feel like there's just some kind of bizarre disconnect:

Well, it is worded very playfully and not very serious corporate business-like.

See also vaguely related T12171.

@nemobis: when customers pay (for example) Atlassian for Atlassian Premier Support, what value/right/expectation do you believe they're getting out of that which we aren't also offering above?

We're planning on selling enterprise support contracts, like those you can purchase from other self-hosting providers like GitHub, Gitlab, and Atlassian. You are not donating money to Phacility.

Indeed I'm not confused about that. That's why I pointed out that giving money in return for no right/expectation to anything, AKA donating, is usually something done towards non-profit entities with certain requirements, not for-profit entities.

We're an evil, for profit company. I'm not sure what's confusing about that.

Sorry, I'm unable to answer your question because I have no idea how you could compare development support to hosting services, or equity to donations.

@epriestley - pholio needs some EditEngine love 😉

This was a misconfiguration on my part and I wasn't properly forwarding the query string from nginx to PHP.

This was a misconfiguration on my part and I wasn't properly forwarding the query string from nginx to PHP.

Subprojects do not currently appear on workboards as columns.

And keep this such way. Please take a look Comment with improvements to "Ability to reorder milestones on a project's workboard".

Milestones are a special kind of subproject for organizing tasks into blocks of work. You can use them to implement sprints, iterations, milestones, versions, etc.

Possibly related, I'm having issues with Almanac too. I created an Almanac device, but clicking on "Add Interface" takes me to /almanac/interface/edit/?deviceID=2 which shows a 404.

In T12547#219587, @epriestley wrote:

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

😢

hahaha

Does it at least tell you how fast you're going?

I have an extra laptop I can use to test this.

I'll do another photoshop pass here with those thoughts