That's a good question. I'm fully for committing docs' changes straight to
the "ignite-2.9" branch without introducing superfluous branches such as
"ignite-2.9-docs".
Igniters, any notable reason why we can't commit changes to a branch of a
finished release? This "frozen" state sounds artificial,
Denis,
Thanks for the answer. Makes sense.
We already have 2.9.0 tag pointing to the release commit. Is it safe
changing docs right from ignite-2.9 branch? Why should we keep it
frozen?
On Fri, 30 Oct 2020 at 23:02, Denis Magda wrote:
>
> Maxim,
>
> The approach you're suggesting (to keep the
Maxim,
The approach you're suggesting (to keep the docs in a separate repo) was
among the two possible options we were reviewing while deciding where to
keep the docs. Eventually, we selected the current solution by storing the
docs together with the source code in a single repo.
As a technical wr
Denis, Alex
It's a bit confusing for me of having the main dedicated branches for
documentation (ignite-2.9-docs, ignite-2.9.1-docs etc.) instead of
keeping docs in the release branch. The drawback of freezing all the
documentation in the release branch is not good for our users also.
We already
Igniters,
I've created "ignite-2.9-docs" branch and cherry-picked documentation
related commits from master.
If you changing documentation in master branch and this fix should affect
Ignite 2.9, please cherry-pick this commit to "ignite-2.9-docs" branch too.
чт, 15 окт. 2020 г. в 01:58, Denis Mag
Igniters,
I've put together the first version of the documentation contribution and
publication process that is based on the new documentation engine we're
releasing with Ignite 2.9:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
Please find some time to check it out and sugge
Hi Maxim,
Those JIRA labels support the current process that assumes the creation of
a documentation ticket before a development ticket is closed. If a
contributor believes there is no need to update the docs (like in the case
of bug fixes) then "Documentation required" will stay disabled. Otherwi
Denis,
>From my recent practice with the release check-boxes "Release notes
required" and "Documentation required" also was not so helpful as
expected. Can we remove them from JIRA issues?
There is no magic pill to not forget to document improvements, but I
think a wide discussion of each major i
The Best way to require draft documentation with the proposed PR:) as a
part of TC check
чт, 19 мар. 2020 г., 21:06 Denis Magda :
> Igniters,
>
> I've modified our release process introducing this step that ensures
> documentation readiness before a vote can be started:
>
> https://cwiki.apache.o
Igniters,
I've modified our release process introducing this step that ensures
documentation readiness before a vote can be started:
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.1EnsureDocumentationReadinessandAccouncementBlogPostActivity
Thanks to everyone
Denis,
Both yours and Andrey's proposal are important. You should start to vote
after the documentation is ready, just like you start to vote after all
features are ready, and documentation is just another feature. However, the
documentation can't be prepared if there is no information on the feat
Hi Pavel,
We're thinking about the same in regards to the future of Ignite
documentation :) Artem and I had some kitchen talks recently and we'll
restart that activity. Ignite definitely deserves and requires next-gen
docs. Artem promised to share his thoughts soon.
Btw, check out How to write ef
I agree with Andrey.
And I'd like to reopen the discussion on "moving docs from readme.io to
git" [1] [2]
Looks like we reached some agreement there but never moved on with the
migration.
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-
Andrey,
Thanks for sharing your thoughts. Your second point made me recall several
occasions when only after a release of some public APIs we had a chance to
complete documentation and discovered the APIs' ineffectiveness and oddness
from the user usage perspective. But it was already late.
Gener
Denis,
I agree with you.
Also I think that we should move to process which will require
documentation updates during work on issue/feature and will part of
code review process. Such approach has some useful benefits:
- Documentation readiness at the same time when fix/implementation is
ready (re
Hi Denis,
My suggestion is that in the current version release process, when
planning to release a version, first determine the Time, Scope and
ReleaseManager. On this basis, we can add another work of documentation,
which is to determine which documents need to be written and who should
writ
16 matches
Mail list logo
