Sounds good to me.
On Sun, May 17, 2015 at 1:40 AM Ali Lown wrote:
> Okay. I merged and pushed those changes.
>
> Should I be squashing the commits into a single one before pushing?
> Does anyone have any preferences on this/other parts of git -
> branching and tagging documentation?
>
> I was a
Okay. I merged and pushed those changes.
Should I be squashing the commits into a single one before pushing?
Does anyone have any preferences on this/other parts of git -
branching and tagging documentation?
I was assuming we have something along the lines of a branch of docs
for each major relea
I think it is.
On Sat, May 16, 2015 at 2:03 AM Ali Lown wrote:
> @Evan: Okay great.
>
> I have merged this PR into the incubator-wave-docs repo.
>
> For reference: as the github repo is a mirror, with the master being
> on git-wip-us.apache.org, I merged the PR by adding a new remote to my
> loc
Hi all,
I have sent in a pull request with some minor changes following
updating the help information.
https://github.com/apache/incubator-wave-docs/pull/2
Can someone review it, so I can commit?
Is github sending notification emails here in the same way review
board does when a PR is made? If n
@Evan: Okay great.
I have merged this PR into the incubator-wave-docs repo.
For reference: as the github repo is a mirror, with the master being
on git-wip-us.apache.org, I merged the PR by adding a new remote to my
local repository which was Evan's repository, then merging the
relevant commits l
@Ali, submitted today
On 15 May 2015 at 05:12, Ali Lown wrote:
> @Evan: That PR looks fine to me.
> One thing: Have you submitted an ICLA to Apache? It seems like it
> would be a good idea to do at some point, as you are likely to
> continue making not-insignificant changes to this repo.
>
> @Yu
@Evan: That PR looks fine to me.
One thing: Have you submitted an ICLA to Apache? It seems like it
would be a good idea to do at some point, as you are likely to
continue making not-insignificant changes to this repo.
@Yuri/Others: How do we want to handle PR reviews?
I propose doing it the same w
For Pull request
On 9 May 2015 at 17:12, Evan Hughes wrote:
> I believe we should split the docs into:
>
> Documentation => Documents how to build the documentation and how to use
> sphinx + ReST (mostly just an example and to help ease the transition)
> manual => The user manua
I believe we should split the docs into:
Documentation => Documents how to build the documentation and how to use
sphinx + ReST (mostly just an example and to help ease the transition)
manual => The user manual provided with the client (How to
make a wave, .)
developer
The repository is at https://github.com/apache/incubator-wave-docs,
and is rather empty at the moment.
I see no reason we shouldn't accept pull requests to this repo, so I
suggest you use that workflow...
Sphinx sounds fine. Many people will be familiar with rest (it shares
a lot with markdown but
I think sphinx would be a better option than jekyll for the documentation,
it does use restructured text instead of markdown but is more extensible
and can easily produce a pdf format compared to markdown. Gonna spin up my
own repo and see how it is, been looking at the syntax and it isn't that
bad
Okay. A new repository has been made:
https://git-wip-us.apache.org/repos/asf?p=incubator-wave-docs.git
I have requested github integration for it, so we can use pull
requests if we would like to...
Ali
On 29 April 2015 at 00:53, Evan Hughes wrote:
> I like the idea of also moving the website o
I ll submit the new RC today.
On Wed, Apr 29, 2015 at 2:54 AM Evan Hughes wrote:
> I like the idea of also moving the website off of the cms but not sure if
> it should be in same repository. Ill look into jekyll for the documentation
> but theres also other build systems which might be better f
I like the idea of also moving the website off of the cms but not sure if
it should be in same repository. Ill look into jekyll for the documentation
but theres also other build systems which might be better for us aka html
and pdf export.
Go ahead with the repository for the documentation and wel
+1 Moving doc to git would be good, moreover if we update and improve it a
litlle bit along the migration process (at least the organization).
2015-04-28 16:40 GMT+02:00 Ali Lown :
> Yuri,
>
> I think the main reason to move is to make it easier for people to
> make changes, over the existing con
Yuri,
I think the main reason to move is to make it easier for people to
make changes, over the existing confluence system. So I would have
though that improving the documentation is something people would be
more likely to do afterwards.
I agree that opening some tickets where the documentation
Maybe it would be better to move in small steps. Like to go over current
documentation and open tickets with requests for improvements wherever
something is missing or not clear.
On Tue, Apr 28, 2015 at 5:33 PM Ali Lown wrote:
> Well, doesn't look like anybody else has much opinion.
>
> Shall I
Well, doesn't look like anybody else has much opinion.
Shall I just raise a ticket for a new repo for this?
It probably makes sense to put the whole website under it, rather than
using the combination of Apache CMS website + Confluence that we do
currently. We could just use Jekyll for both websi
indeed and yea without a doubt
On 25 April 2015 at 09:59, Ali Lown wrote:
> Hi Evan,
>
> +1
>
> After giving this some more thought post the Hangout, I do think that
> moving the docs to Git provides us with a measurable improvement over
> the current situation - particularly with the ability to
Hi Evan,
+1
After giving this some more thought post the Hangout, I do think that
moving the docs to Git provides us with a measurable improvement over
the current situation - particularly with the ability to keep docs
synced with the releases via branches, and the reduced barrier to
entry for ch
woops, my bad
This is a proposal for the storage of documentation to be moved to a git
repository instead of on confluence and leave confluence as a place for
other technical documents used by developers.
*Confluence:*
*The issues:*
- contributors must ask for permission from the mai
This is a proposal for
TL;DR
22 matches
Mail list logo
