Change Details

See PHI510. An install reports that mentioning ~80 objects in a task description takes more than 30 seconds to save. The install has ~1 second of Herald rules for tasks and ~2 seconds of Herald rules for revisions and evidence points at this just being a lot of time spent performing rule evaluation in Herald. Currently, we run Herald against an object when it is mentioned elsewhere. For example, if you mention `T123`, we'll go run Herald rules on `T123` in the process of adding `alice mentioned this in T456.` to the timeline. On this install, this is why you'll often see Herald add subscribers after something gets mentioned. This behavior doesn't feel good to me: I don't think users really want it, it's sort of confusing and unexpected, and (upstream) Herald rule results never change based on mentions. I've leaned toward removing it purely on the grounds of it not being very desirable as a behavior. Since it's also creating some flavor of scaling pressure here, I'm going to remove this behavior and stop firing Herald rules when `alice mentioned this on T456.` is added to a timeline. See PHI496. Multiple users have now reached the maximum level ("Heavy Wizard") on their Support characters, and we're overdue for an expansion pack to add new adventure content. See PHI513. `bin/drydock command ...` misuses `fprintf()`. See PHI514. See also PHI486. It appears that enormous change protection is having meaningfully negative effects in the real world, as described in T8951#233860, particularly on staging area imports. I'm going to make these changes: - When a push is an initial import, disable Herald pre-commit rules. - When a push is an initial import, disable enormous change protection. I think these modified rules align well with real-world usage, even though the special behavior of initial imports isn't completely obvious. An "initial import" is a push of at least 7 commits to an empty repository. See PHI515. At some point, likely D19175, a `differential.updaterevision` call to update a revision with the //same// diff changed from a no-op to an error. This is unorthodox but should be a no-op for consistency with how other transactions work. See PHI511. Currently, `HarbormasterBuild` does not implement `DestructibleInterface`, but, like other modern objects, it should. See PHI519. An install would like to edit custom fields (particularly, custom PHID/datasource fields) via the comment action dropdown. See PHI514. I dun goofed and need to put the cat back in the bag.

See PHI510. An install reports that mentioning ~80 objects in a task description takes more than 30 seconds to save. The install has ~1 second of Herald rules for tasks and ~2 seconds of Herald rules for revisions and evidence points at this just being a lot of time spent performing rule evaluation in Herald. Currently, we run Herald against an object when it is mentioned elsewhere. For example, if you mention `T123`, we'll go run Herald rules on `T123` in the process of adding `alice mentioned this in T456.` to the timeline. On this install, this is why you'll often see Herald add subscribers after something gets mentioned. This behavior doesn't feel good to me: I don't think users really want it, it's sort of confusing and unexpected, and (upstream) Herald rule results never change based on mentions. I've leaned toward removing it purely on the grounds of it not being very desirable as a behavior. Since it's also creating some flavor of scaling pressure here, I'm going to remove this behavior and stop firing Herald rules when `alice mentioned this on T456.` is added to a timeline. See PHI496. Multiple users have now reached the maximum level ("Heavy Wizard") on their Support characters, and we're overdue for an expansion pack to add new adventure content. See PHI513. `bin/drydock command ...` misuses `fprintf()`. See PHI514. See also PHI486. It appears that enormous change protection is having meaningfully negative effects in the real world, as described in T8951#233860, particularly on staging area imports. I'm going to make these changes: - When a push is an initial import, disable Herald pre-commit rules. - When a push is an initial import, disable enormous change protection. I think these modified rules align well with real-world usage, even though the special behavior of initial imports isn't completely obvious. An "initial import" is a push of at least 7 commits to an empty repository. See PHI515. At some point, likely D19175, a `differential.updaterevision` call to update a revision with the //same// diff changed from a no-op to an error. This is unorthodox but should be a no-op for consistency with how other transactions work. See PHI511. Currently, `HarbormasterBuild` does not implement `DestructibleInterface`, but, like other modern objects, it should. See PHI519. An install would like to edit custom fields (particularly, custom PHID/datasource fields) via the comment action dropdown. See PHI514. I dun goofed and need to put the cat back in the bag. See PHI522. Autocomplete typeaheads don't clearly indicate when you're completing a disabled user, and don't use the disabled user sorting rules.

See PHI510. An install reports that mentioning ~80 objects in a task description takes more than 30 seconds to save. The install has ~1 second of Herald rules for tasks and ~2 seconds of Herald rules for revisions and evidence points at this just being a lot of time spent performing rule evaluation in Herald. Currently, we run Herald against an object when it is mentioned elsewhere. For example, if you mention `T123`, we'll go run Herald rules on `T123` in the process of adding `alice mentioned this in T456.` to the timeline. On this install, this is why you'll often see Herald add subscribers after something gets mentioned. This behavior doesn't feel good to me: I don't think users really want it, it's sort of confusing and unexpected, and (upstream) Herald rule results never change based on mentions. I've leaned toward removing it purely on the grounds of it not being very desirable as a behavior. Since it's also creating some flavor of scaling pressure here, I'm going to remove this behavior and stop firing Herald rules when `alice mentioned this on T456.` is added to a timeline. See PHI496. Multiple users have now reached the maximum level ("Heavy Wizard") on their Support characters, and we're overdue for an expansion pack to add new adventure content. See PHI513. `bin/drydock command ...` misuses `fprintf()`. See PHI514. See also PHI486. It appears that enormous change protection is having meaningfully negative effects in the real world, as described in T8951#233860, particularly on staging area imports. I'm going to make these changes: - When a push is an initial import, disable Herald pre-commit rules. - When a push is an initial import, disable enormous change protection. I think these modified rules align well with real-world usage, even though the special behavior of initial imports isn't completely obvious. An "initial import" is a push of at least 7 commits to an empty repository. See PHI515. At some point, likely D19175, a `differential.updaterevision` call to update a revision with the //same// diff changed from a no-op to an error. This is unorthodox but should be a no-op for consistency with how other transactions work. See PHI511. Currently, `HarbormasterBuild` does not implement `DestructibleInterface`, but, like other modern objects, it should. See PHI519. An install would like to edit custom fields (particularly, custom PHID/datasource fields) via the comment action dropdown. See PHI514. I dun goofed and need to put the cat back in the bag. See PHI522. Autocomplete typeaheads don't clearly indicate when you're completing a disabled user, and don't use the disabled user sorting rules.