Merge ~racb/git-ubuntu:more-project-rename into git-ubuntu:main

Looks good, but waiting for approval from others.

PASSED: Continuous integration, rev:7ef484a96b74df4ded94cff0096c88f5a1244a1a
https://jenkins.canonical.com/server-team/job/git-ubuntu-ci/7/
Executed test runs:
    SUCCESS: VM Setup
    SUCCESS: Build
    SUCCESS: VM Reset
    SUCCESS: Unit Tests
    IN_PROGRESS: Declarative: Post Actions

Click here to trigger a rebuild:
https://jenkins.canonical.com/server-team/job/git-ubuntu-ci/7//rebuild

You're doing too many disparate things in a single commit. Just focus this on project renaming.

I'd want to see better justification for deletion of the migration code, given that it represented a large investment of effort to implement in the first place, however I am biased against deleting my own contributions. So you may be better to find someone else to do the reviewing. As I understood it, you disabled it (temporarily I assumed) to facilitate migrating the code, so it is startling to see it on the chopping block.

I guess the underlying case here is that we want "some kind of monitoring" to alert us of failed imports, but do not insist too hard which solution that is.

Is there already something new present and working that will replace the old mailing feature?
I know it was off recently, but dropping it entirely from the codebase without a successor feels odd indeed.

If there is a plan or even code already we could - while dropping the mail feature - at least outline a bit like "this used to use mails summarizing the fail reason which no more works because X<reason>, instead as part of version x.y <plan> it will switch to report such issues via Y<solution that fits better because>".

If we do not yet have an Y, maybe we should keep X for now (even disabled)?

On Mon, Jun 27, 2022 at 07:06:43AM -0000, Christian Ehrhardt  wrote:
> I guess the underlying case here is that we want "some kind of monitoring" to alert us of failed imports, but do not insist too hard which solution that is.
>
> Is there already something new present and working that will replace the old mailing feature?

Since then we now have the tracking system. We have a database tracking
progress and can list errored imports from the database. So we aren't
getting directly notified, but can generate a report of everything that
needs retrying, for example.

In practice, this emailing code was useful when we had many failures for
various reasons and were struggling to keep track of them. Now, the
majority of those issues are fixed, the remaining failures are mostly
transient and I don't think that receiving emails for them invidiually
would be useful any more. Maybe we should have some automatic retry
system hit failures first, but we don't currently have that.

I spoke to Andreas about future design for observability/monitoring and
I think the conclusion was that InfluxDB probably made sense to log
"events" such as "package A succeeded; processing time X" and "package B
failed". But no, that's not there today, and it's not currently a
priority to implement.

> I know it was off recently, but dropping it entirely from the codebase without a successor feels odd indeed.

I'm surprised at this reaction because I don't see this as a decision
that's being made now. The code has already been "skeleton" for a long
time.

It is already effectively dropped - it isn't connected to any live code.
It's de-facto not being maintained _because_ it isn't connected to
anything so doesn't get adjusted as the rest of the code changes.
Reconnecting it would involve some work because the paradigm has
changed. We no longer have a set of failures that happen in sequence
that we then batch the results email out.

Removing it is merely cleaning up the source tree for a change that
already took place. If we want to bring it back to live status later, it
will still be in VCS. It makes little difference whether it is in the
source tree or in VCS history except that if it stays I have to keep
half-maintaining it when refactoring.

That's the cost. What would be the benefit?

PASSED: Continuous integration, rev:1fa430fc8efd64bfda20bd8b5321ef790f6e162b
https://jenkins.canonical.com/server-team/job/git-ubuntu-ci/9/
Executed test runs:
    SUCCESS: VM Setup
    SUCCESS: Build
    SUCCESS: VM Reset
    SUCCESS: Unit Tests
    IN_PROGRESS: Declarative: Post Actions

Click here to trigger a rebuild:
https://jenkins.canonical.com/server-team/job/git-ubuntu-ci/9//rebuild

Thanks Robie,
since the feature was no more used for a while and is no more as-needed due to the queuing I agree to merge this MP. Thanks for adding an acknowledgement to what we had in the past and a plan for what we should/could add (and where) - that is the least we can do when removing code that was quite useful when it was active still.

If along the PS5 setup we identify any kind of need to mail us about status please do not hesitate to revive fragments of this as-needed (would not in the same place anyway, but some elements might still be valid).

PASSED: Continuous integration, rev:4d497a77ae031f49980ae50af5b1fb079fce3e8f
https://jenkins.canonical.com/server-team/job/git-ubuntu-ci/10/
Executed test runs:
    SUCCESS: VM Setup
    SUCCESS: Build
    SUCCESS: VM Reset
    SUCCESS: Unit Tests
    IN_PROGRESS: Declarative: Post Actions

Click here to trigger a rebuild:
https://jenkins.canonical.com/server-team/job/git-ubuntu-ci/10//rebuild