> >
> > Just one thought maybe we can enforce the process to achieve docs, maybe
> via pre-commit hooks/updating the `breeze release-management publish-docs`
> command. So that anytime there is something new published we also check the
> docs to achieve
.
>
Yep. That would be nice to archive the d
Hey everyone,
Thank Bowrna :)
@Jarek Dream Team, Indeed.
@Amogh Sure, no problem, we can sync on Slack when you are back.
As Ryan mentioned, we need to be able to deal with two types of docs.
1. Docs that are published before 18 months, older docs.
2. Docs that are published somewhere between
Yeah, excellent team!
Utkarsh note that I will be on vacation from today till Nov 6. I should be
able to help after that :)
Even during this period i will have slack on mobile, so I can help
asynchronously if needed.
Thanks & Regards,
Amogh Desai
On Fri, Oct 27, 2023, 14:22 Jarek Potiuk wrote
Whoa. Dream team :) .
And of course - if you need any of my input of how it works or get
stuck with something - feel absolutely free to ping me on slack. While I
have not developed the build process I probably tinkered and touched it in
the past in many places and reverse engineered some parts of
I would also like to join in this efforts.
On Fri, Oct 27, 2023 at 8:19 AM Ryan Hatter
wrote:
> I'm happy to work on this alongside Utkarsh, Amogh Desai, and Aritra Basu
> :)
> Some thoughts on Utkarsh's proposal (and what him and I have been
> discussing offline):
>
>1. I think we should s
I'm happy to work on this alongside Utkarsh, Amogh Desai, and Aritra Basu
:)
Some thoughts on Utkarsh's proposal (and what him and I have been
discussing offline):
1. I think we should start with enabling Hugo in the documentation build
process for new releases
1. This may need to incl
That sounds good, I'll start with creating smaller tickets for the above
task, which I intend to do by the end of this week.
Thanks,
Utkarsh Sharma
On Thu, Oct 26, 2023 at 4:16 PM Aritra Basu
wrote:
> Yup, sounds good to me let's go for it!
>
> --
> Regards,
> Aritra Basu
>
> On Thu, Oct 26, 2
Yup, sounds good to me let's go for it!
--
Regards,
Aritra Basu
On Thu, Oct 26, 2023, 1:47 PM Amogh Desai wrote:
> Go ahead Utkarsh. It would be nice to work with you along this.
>
> Thanks,
> Amogh Desai
>
> On Wed, Oct 25, 2023 at 10:02 PM Jarek Potiuk wrote:
>
> > +1. I think no-one will ob
Go ahead Utkarsh. It would be nice to work with you along this.
Thanks,
Amogh Desai
On Wed, Oct 25, 2023 at 10:02 PM Jarek Potiuk wrote:
> +1. I think no-one will object to improve the current situation :)
>
> On Wed, Oct 25, 2023 at 5:02 PM utkarsh sharma
> wrote:
>
> > Hey everyone,
> >
> >
+1. I think no-one will object to improve the current situation :)
On Wed, Oct 25, 2023 at 5:02 PM utkarsh sharma
wrote:
> Hey everyone,
>
> If we have a consensus on the suggestions in my previous email, I would
> like to subdivide the task into smaller tickets and distribute them among
> Aritr
Hey everyone,
If we have a consensus on the suggestions in my previous email, I would
like to subdivide the task into smaller tickets and distribute them among
Aritra Basu, Amogh Desai, and myself.
Thanks,
Utkarsh Sharma
On Tue, Oct 24, 2023 at 10:12 PM Jarek Potiuk wrote:
> Those look like gr
Those look like great ideas.
On Tue, Oct 24, 2023 at 4:23 PM utkarsh sharma
wrote:
> Just forgot to mention in my previous mail, that I'm suggesting the above
> changes since the storage is not the primary concern right now but I'm
> happy to contribute either way. :)
>
> On Tue, Oct 24, 2023 at
Just forgot to mention in my previous mail, that I'm suggesting the above
changes since the storage is not the primary concern right now but I'm
happy to contribute either way. :)
On Tue, Oct 24, 2023 at 7:43 PM utkarsh sharma
wrote:
> Hey everyone,
>
> I have a couple of tasks in mind, that mig
Hey everyone,
I have a couple of tasks in mind, that might aid in reducing the efforts
while working with docs. Right now tasks listed below are difficult to
achieve.
1. Adding a warning based on a specific provider/version of a
provider/range of providers. Which was also the task that Ryan was w
So it looks like we have some helping hands and we need someone to lead it
:) (just saying).
On Tue, Oct 24, 2023 at 8:15 AM Amogh Desai
wrote:
> +1 (non binding) from me on the thought of moving the older docs (~18
> months seems ok) to an archive instead of the repository.
>
> Coming to the ot
+1 (non binding) from me on the thought of moving the older docs (~18
months seems ok) to an archive instead of the repository.
Coming to the other problem of copying the built docs into airflow-site for
releases, maybe we can fix that using a script? Open for thoughts here.
I would be very happy
This definitely sounds like something that needs doing sooner rather than
later.
While I'd love to help, I'm not too experienced with this area so I might
not be able to actually propose what changes need doing, but if someone has
a path forward on this I can definitely contribute some time to hel
Some news here.
I caught up with some infra changes that happened while I was travelling -
and I have just (with https://github.com/apache/airflow-site/pull/879)
switched the "airflow-site" building to the new, self-hosted "asf-runners".
This is a new option that ASF infra has given to test for th
+1 from moving archived docs outside of airflow-site.
Even if that might mean a little more maintenance in case we need to
propagate changes to all historical versions, we would have to handle 2
repositories, but that seems like a minor downside compared to the quality
of life improvement that it
Let me just clarify (because that could be unclear) what my +1 was about.
I was not talking (and I believe Ryan was not talking either) about
removing the old docs but about archiving them and serving from elsewhere
(cloud storage).
I think discussing changing to more shared HTML/JS/CSS is also a
Hey everyone,
Thanks, Ryan for stating the thread :)
Big +1 For archiving docs older than 18 months. We can still make the older
docs available in `rst` doc form.
But eventually, we might again run into this problem because of the growing
no. of providers. I think the main reason for this issue
I am not happy about removing "old" docs.
There are still users on older versions but given the situation I am not
sure what other option we have.
Maybe we should cut from a specific provider rather than from all of them?
Why does Google provider consume 4 GB and Amazon 1.7 GB?
Is there a specific
Yes. Moving the old version to somewhere that we can keep/archive static
historical versions of those historical docs and publish them from there.
What you proposed is exactly the solution I thought might be best as well.
It would be a great task to contribute to the stability of our docs
generati
23 matches
Mail list logo
