Update project references to Apache Burr and remove DAGWorks attributions

[harishkesavarao]

Update project references to Apache Burr and remove DAGWorks attributions

Changes

• Update GitHub URLs from dagworks-inc and DAGWorks-Inc to apache.
• Update documentation links from burr.dagworks.io to burr.apache.org.
• Update package references dagWorks-Inc/hamilton to apache/hamilton.
• Remove by DAGWorks Inc. attributions from documentation and examples.
• Standardize project URLs across READMEs, examples, and backend code.

How I tested this

Checked if all the URLs are valid after replacing DAGWorks with Apache Burr references

Notes

None

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[harishkesavarao]

Implements item 1 mentioned in #589 (comment)

[andreahlert]

This covers a good chunk of #589. After reviewing the codebase, there are still some remaining references not addressed here:

• pyproject.toml: author emails ([email protected], [email protected]), homepage/docs/repo URLs still pointing to dagworks-inc/burr
• burr/core/application.py: GitHub links to DAGWorks-Inc/burr
• burr/core/state.py: issue link to DAGWorks-Inc/burr
• burr/integrations/base.py: URL burr.dagworks.io
• Some notebooks in docs/examples/ still reference "by DAGWorks Inc. (YCW23 & StartX)"

[andreahlert]

Thanks for tackling this, @harishkesavarao! Cleaning up the DAGWorks references is important for the project moving forward.

Just a heads up: in #679 I'm adding a Next.js landing page that also touches sphinx-docs.yml (the deploy step moves to a new unified workflow). If this merges first I'll just rebase on my end, no worries.

I spotted a couple of things that might be worth a quick look:

1. In appcontainer.tsx, the Examples link ended up as -Inc/burr instead of apache/burr, which gives a broken URL (https://github.com/-Inc/burr/tree/main/examples).
2. @pjfanning raised a good point about the issues: write permission on a pull_request-triggered workflow that's still open.

Regarding the Substack blog links, I'd keep them for now since the content lives there and redirecting to burr.apache.org would lead to a dead end. Long term we should have a blog section on the official site where this kind of content can live under the Apache umbrella. I can open an issue to track that as a roadmap item. @skrawcz does that approach work for you?

Happy to help if needed!

[harishkesavarao]

This covers a good chunk of #589. After reviewing the codebase, there are still some remaining references not addressed here:

* `pyproject.toml`: author emails (`[email protected]`, `[email protected]`), homepage/docs/repo URLs still pointing to `dagworks-inc/burr`

* `burr/core/application.py`: GitHub links to `DAGWorks-Inc/burr`

* `burr/core/state.py`: issue link to `DAGWorks-Inc/burr`

* `burr/integrations/base.py`: URL `burr.dagworks.io`

* Some notebooks in `docs/examples/` still reference "by DAGWorks Inc. (YCW23 & StartX)"

Thank you for flagging these, I will work on it and push a change.

[harishkesavarao]

@andreahlert @skrawcz @pjfanning I have added a couple more commits to replace all the remaining DAGWorks references, except the fact that there are several instances in the repository where references are made to the DAGWorks blog, which is a Substack page. Should this be retained as it is or should I point it to https://burr.apache.org/?

[andreahlert]

@andreahlert @skrawcz @pjfanning I have added a couple more commits to replace all the remaining DAGWorks references, except the fact that there are several instances in the repository where references are made to the DAGWorks blog, which is a Substack page. Should this be retained as it is or should I point it to https://burr.apache.org/?

Thanks @harishkesavarao!

Just a heads up: in #679 I'm adding a Next.js landing page that also touches sphinx-docs.yml (the deploy step moves to a new unified workflow). If this merges first I'll just rebase on my end, no worries.

I spotted a couple of things that might be worth a quick look. Comments bellow.

Regarding the Substack blog links, I'd keep them for now since the content lives there and redirecting to burr.apache.org would lead to a dead end. Long term we should have a blog section on the official site where this kind of content can live under the Apache umbrella. I can open an issue to track that as a roadmap item if that sounds good. @skrawcz WDYT?

Happy to help if needed!

[andreahlert]

I spotted a couple of things that might be worth a quick look:

1. In appcontainer.tsx, the Examples link ended up as -Inc/burr instead of apache/burr, which gives a broken URL (https://github.com/-Inc/burr/tree/main/examples).
2. @pjfanning raised a good point about the issues: write permission on a pull_request-triggered workflow that's still open.

[harishkesavarao]

I spotted a couple of things that might be worth a quick look:

1. In appcontainer.tsx, the Examples link ended up as -Inc/burr instead of apache/burr, which gives a broken URL (https://github.com/-Inc/burr/tree/main/examples).

2. @pjfanning raised a good point about the issues: write permission on a pull_request-triggered workflow that's still open.

@andreahlert Thank you for the quick review! I have pushed a commit for the 2 items above. Please do let me know if it looks good now. I am sorry about the typo 😄

[harishkesavarao]

@andreahlert @skrawcz @pjfanning I have added a couple more commits to replace all the remaining DAGWorks references, except the fact that there are several instances in the repository where references are made to the DAGWorks blog, which is a Substack page. Should this be retained as it is or should I point it to https://burr.apache.org/?

Thanks @harishkesavarao!

Just a heads up: in #679 I'm adding a Next.js landing page that also touches sphinx-docs.yml (the deploy step moves to a new unified workflow). If this merges first I'll just rebase on my end, no worries.

I spotted a couple of things that might be worth a quick look. Comments bellow.

Regarding the Substack blog links, I'd keep them for now since the content lives there and redirecting to burr.apache.org would lead to a dead end. Long term we should have a blog section on the official site where this kind of content can live under the Apache umbrella. I can open an issue to track that as a roadmap item if that sounds good. @skrawcz WDYT?

Happy to help if needed!

Sounds good - regarding the Substack URLs.

Thanks for the heads up about your PR #679 , I will keep an eye to see which one is merged first and rebase as required.

[andreahlert]

LGTM. Just one small thing below.

[harishkesavarao]

LGTM. Just one small thing below.

Now fixed. Thank you!