(The major goal of using refs instead of tags wouldn't really be to hide them per se, just to make them extremely difficult to fetch by accident.)

Maybe my assumptions about default behaviors are off, or the more-recent base tags (but not necessarily the diff tags) are getting fetched because they're often ancestors of master?

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

In T8238#196187, @epriestley wrote:

I think cleaning up closed tags probably isn't a particularly great long-term solution since some fraction of the revisions likely just get left open forever -- so you'd have 500 tags instead of 50000, but I assume that still causes about as many problems, and you'll be back to 50000 in just 100 more years anyway.

I think cleaning up closed tags probably isn't a particularly great long-term solution since some fraction of the revisions likely just get left open forever -- so you'd have 500 tags instead of 50000, but I assume that still causes about as many problems, and you'll be back to 50000 in just 100 more years anyway.

See some discussion in T7944, particularly T7944#194982.

We're planning to put application-level stemming on the MySQL index (see T6740). Are there problems with the InnoDB search that you're aware of that aren't fixable with application adjustments?

With InnoDB now mostly finished indexing, search seems to be working and the service isn't getting killed by locked tables. More info at the link I pasted above ^

We see how bad this is (does pushing tags to the same repository create a big user-facing mess?) and then go from there.

a quick and dirty fix for this could be

Wikimedia is considering another stab at elasticsearch because we just hit a fairly serious scalability issue with myisam (https://phabricator.wikimedia.org/T146673) and it looks like innodb isn't a lot better. In addition to that, the mysql fulltext engines don't seem to handle stemming or even simple prefix matching.

I clicked "Update Now" and the update frequency for our most active repository has dropped back down to 15 seconds.

+1 for mentions, that would serve the same purpose as see also: or related tasks: would. Primarily it would just be nice to be able to see them in one place instead of hiding in comments...

@beber does setting EFL to "Public" resolve your issue?s

Yes, thanks!

https://phab.enlightenment.org/diffusion/EFL/ view policy is set to "All Users".

This has been solved AFAIK since I haven't seen this issue in a while.

(I'll follow up on this once I have a chance to bang on it a bit, but I want to try to finish up the RRULE stuff while it's still somewhat fresh in my mind.)

This went out a while ago and I confirmed the fix in production.

I'm going to presume we got this, but reopen or yell if you're still seeing issues on the new code.

Thanks for the report! The detailed reproduction instructions were very helpful in resolving this.

I did order an iPhone 7 plus, so I'll have a better understanding if 2x is actually noticeably bad.

This isn't like something I'm looking for immediately, btw. Just like, next time I have to make 50 images.

I'm also not sure if we can use SVG as a data: URL in CSS. It probably should work, but if it doesn't we'll have to rasterize (and, I guess, serve 5+ different sizes to every user).

Alright -- we can have bin/celerity map rasterize SVG into arbitrary sizes if I'm not comfortable serving SVG directly from Celerity.

I'd like to generate 1 image and have them work 1x, 2x, 3x, etc or any size I need. I can't think of any other long term solution.

• Create a badge.
• Award it to a user.
• Visit their profile page.
• On the profile page, the badge title should link to the badge detail page (currently: no way to get to the badge detail page).

I'm not really sure this is actually useful given that every method is now named <application>.whatever and you can search by substring.

(That will give us slightly bad scale-downs on 1X screens, but I bet they're not worse than scaling down an SVG would be.)

I think we can just do 2x in all cases for these, if that's reasonable?

fwiw, I want to convert all bitmaps to SVG if possible, so we can skip building 1x and 2x images.

Don't know if D16178 is worth comandeering? But feel free.

This one is a little scattered, so let me know where I can fill in any gaps. Most of the details are in D16178.

Thanks!

Thanks, Chad. I've just used the Administrators group and adjusted the EditEngine permissions, which is sufficient for us; anyone authoritative enough to create blogs is authoritative and technically proficient enough to have admin privs, too.

Please see Contributing Bug Reports for what information is required for bug reports.

On the right side in actions

(not building locally anymore, eg, any time I want to do anything with a built binary at all, i'm actually doing it with a binary on a remote server because I can get the build results faster)

Well one facet of this is that remote servers tend to be significantly more powerful than developer machines, and so since I've implemented this downstream, I have basically taken to not building locally anymore.

In T8135#195971, @chad wrote:

@olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

Yeah, it makes sense to not auto-subscribe and I'm afraid I don't have better plans ready for cases where you don't want everyone creating blogs. You could at least make a group like "blog creators" and delegate.

+1 it's very confusing

Do you have any use cases which are not approximately some flavor of:

Maaaybe Iam misinterpreting but if enabling sort by priority why not show in workboards something like

@olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

I mean, it's probably not worse-worse, and but it feels like trading one kind of confusion for possibly-moderately-less-confusion more than putting a reasonable stopgap behavior in place until we can fix it properly.

Oh. To me, that's sort of worse? You end up with "Sort by priority" and your tasks aren't actually sorted by priority if you've moved them between columns, and jump around if you reload, and other users won't see the same ordering if they're trying to follow along in a presentation or whatever.

I think I'm doing a bad job at saying that though.

I'm suggesting removing it until T10333

Sorry, I think I'm still not understanding. When the column is grouped by priority, I still expect the auto-reprioritize behavior to work more or less as it does today: if you drag a task into the "High" group, it will change to "High" priority. I don't think we can avoid that without greater confusion.

I assume "Group by" would have dragging support, so by assignee, I could easily re-assign tasks. With that in mind "Group by" and priority, you could drag and drop by priority, thus allowing us to remove the "automatic" feature we have today in the current priority sort.