Kubeflow 1.3 release doc updates #2546
Comments
|
I'm following https://github.com/kubeflow/kubeflow/blob/master/docs_dev/releasing.md#lifecycle. I just forked current master branch as v1.2-branch, and pinned www.kubeflow.org to |
|
/cc @joeliedtke @RFMVasconcelos |
|
Thank you for taking on this work @Bobgy ! |
rui-vas
moved this from Started
to Blocking issue for v1.3
in Kubeflow docs restructure
|
@RFMVasconcelos before we close this, I think we should make https://www.kubeflow.org/ default to Also we should resolve the issue about not having |
|
@thesuperzapper this is part of the docs release process. I will follow these steps to have Kubeflow.org point to master and there will be v1.2 in the selector. This is a state in transition. When we point it to |
|
In fact, trying to do this now I realize this is done on Netlify which I have not played with yet, I am not sure this is googlers only. I think @Bobgy did this for us in the previous release. I think the best thing to do is for me to get the |
|
Sounds good @Bobgy ? |
|
I think we can try and resolve #2536 before doing the master switch. If your willing to make a PR @RFMVasconcelos? |
|
Sure, for any netlify related steps. You can ping @joeliedtke or me about them. |
|
Given the ETA for release process » Step 6: Tuesday, EOD 2021-04-06 [Pacific Time] Should we aim at pointing the docs to @joeliedtke would you be able to make the necessary netlify changes by then? thoughts? @Bobgy @thesuperzapper @yanniszark @8bitmp3 @animeshsingh @castrojo @jbottum |
|
IIUC, I think we need to wait for at least most distributions are ready with their docs, so it will very likely be a later time than that date |
|
That is a good point @Bobgy! It does raise some concerns - what if distribution X does not have the resources to update docs within the next months? In the past we added the "Outdated" banners to guide users to what docs are outdated, while not freezing improvements. I think that the current |
|
@Bobgy We should aim to point the docs at Note that "Step 6" is the offical release for Kubeflow 1.3 (From the OSS community perspective), as after that date a distribution could release Kubeflow 1.3 to their users. (There is no reason to penalise the faster distributions if the slow ones aren't ready) Also, there is a case to point at |
|
I don't understand the benefit, at that date, no distribution is ready to release and there can be issues found that require a rc1. Why would that be a date to switch to master branch? I love the improvements in master branch, but as they are mostly information restructuring, I don't feel the urgency to release them. Can we wait until most of the next release is ready? I think it's reasonable to set a cut date for doc when at least 2 distributions are ready. What do you think? |
|
@Bobgy I think it's just semantics, as some of the smaller distributions will be ready in the first few days. This is the same as how Kuberntes does not delay their release if GKE is not ready (just as an example, not picking on GKE). Furthermore we would have to open the debate of what a "distribution" even means, as we have no validation process right now, which is not really a discussion we need to start just before 1.3 is released. |
|
Can I confirm if we align on this? |
|
@Bobgy I agree that docs should only be released once people can use them in the equivalent release. I think this problem arrives from the fact that we're synchronizing a docs release with a docs restructuring, and so by holding off both, we keep users in a non-optimal information structure when we have a better alternative. I don't see urgency in pointing to master from the docs release, but I do see it from the docs restructure standpoint. I am unsure on what percentage of the docs is actually tied to a specific version of KF, I would say that the rate of change in docs has been fairly slow and that we likely will need only a few version-specific changes. WDYT? |
|
@RFMVasconcelos @Bobgy I think its probably OK to move to point at |
|
+1 ! :) |
|
What do you think about merging master to v1.2 branch? If the restructuring is what you care about |
|
@Bobgy this is a good idea, we should probably just take |
|
+1. That is a good idea! |
|
Are there any v1.3 specific commits we should cherry-pick out of this move? If not, I can simply make a PR to merge all the commits currently in |
|
@Bobgy @thesuperzapper WDYT? |
|
@Bobgy, at what point do you think we should move the docs to point to |
|
There are a bunch of ongoing fixes being done in |
|
And unfortunately this is taking a bit longer as well #2612 |
|
@RFMVasconcelos I personally think as long as master branch is not confusing in obvious ways, it's okay to switch. In previous releases, we wait until most distributions are ready, but I don't think that is necessary, as long as each distribution can release their docs on their own, it's fine. |
|
@Bobgy I agree! #2612 has been merged, so we already have a good structure of the docs. 🎉 But in any case, small fixes and updates are being done in master now that are relevant for v1.3 users - e.g. #2595. I propose we move to |
|
I just realized that |
|
@Bobgy @joeliedtke @animeshsingh @thesuperzapper @castrojo @jbottum @cvenets @yanniszark @theadactyl We just merged the last PRs that IMO were critical for a successful v1.3 release, we now just need to point the website to Many thanks to all for this push! |
|
@Bobgy I think we are all good to make the switch to master tonight/ASAP, as we are about to release the 1.3 blog. |
|
Discussed over the release meeting, I'm going to change website to master branch right now. /cc @yanniszark @RFMVasconcelos @thesuperzapper UPDATE: done the switch, the next push in master will switch the website to master branch. |
|
To close out this issue, we just need to fix issue: #2657 I believe we can track other doc issues separately, for example:
|
|
I've made a couple of PRs to solve #2657 |
|
@thesuperzapper @Bobgy could you please review and LGTM #2666 and #2667 ? :) Thank you @thesuperzapper for listing what's left! Let's try to use the |
|
@RFMVasconcelos can you add me as an editor on that project? I cant add cards right now |
|
For sure! I thought this was open to the community, let me check how to open permissions |
|
@thesuperzapper This is very strange, there is no @Bobgy are you able to verify that you can? |
|
@RFMVasconcelos I personally use projects which are on the kubeflow organisation, but if you are the owner of the docs refactor project, you should be able to:
|
|
@thesuperzapper thank you for the guidance! I don't see settings, maybe I am not an owner? I did create the project and am able to use it... @Bobgy do you see settings? |
|
@RFMVasconcelos I created a project on the kubeflow org for the docs and made you It's probably easier to just move over to that one, where we have actual admin access, feel free to change the structure, etc. |
|
@thesuperzapper thanks for this! We can classify the current |
|
I believe we can now close this tracking issue! Thank you all for the amazing work :) |
Creating an issue to track updates preparing for Kubeflow 1.3 doc release.
The text was updated successfully, but these errors were encountered: