We now have nightly docs build:
https://github.com/kszucs/crossbow/branches/all?utf8=%E2%9C%93=docs
If We decide where to upload it, We can publish nightly dev docs.
On Wed, Dec 19, 2018 at 3:12 PM Wes McKinney wrote:
> Indeed. I had opened an issue about this some time ago
>
>
Indeed. I had opened an issue about this some time ago
https://issues.apache.org/jira/browse/ARROW-1299
On Wed, Dec 19, 2018 at 8:10 AM Antoine Pitrou wrote:
>
>
> Le 19/12/2018 à 15:07, Wes McKinney a écrit :
> > +1 also. The C++ README has grown quite long, for example. Probably to
> > put
Le 19/12/2018 à 15:07, Wes McKinney a écrit :
> +1 also. The C++ README has grown quite long, for example. Probably to
> put all of that in the Sphinx project.
>
> One downside of Sphinx is that some things can grow out of date on the
> website in between releases. Within the codebase itself,
+1 also. The C++ README has grown quite long, for example. Probably to
put all of that in the Sphinx project.
One downside of Sphinx is that some things can grow out of date on the
website in between releases. Within the codebase itself, we can remedy
this by directing people to the .rst files
+1, I would also like to see them in Sphinx.
Uwe
> Am 19.12.2018 um 11:13 schrieb Antoine Pitrou :
>
>
> We should decide where we want to put developer docs.
>
> I would favour putting them in the Sphinx docs, personally.
>
> Regards
>
> Antoine.
>
>
>> Le 19/12/2018 à 02:20, Wes
We should decide where we want to put developer docs.
I would favour putting them in the Sphinx docs, personally.
Regards
Antoine.
Le 19/12/2018 à 02:20, Wes McKinney a écrit :
> Some projects have a REVIEWERS.md file
>
>
Some projects have a REVIEWERS.md file
https://github.com/apache/parquet-mr/blob/master/parquet-common/REVIEWERS.md
We could do the same, or keep the file on the project wiki so it's
lighter-weight to change (no pull request required)
https://cwiki.apache.org/confluence/display/ARROW
+1 for
+1 on adding labels for languages, review states, components, etc. This
makes it much easier to filter PRs.
Chao
On Wed, Dec 12, 2018 at 11:54 AM Krisztián Szűcs
wrote:
> Create a new one and set arrow-xxx as parent:
> [image: image.png]
>
> On Wed, Dec 12, 2018 at 7:46 PM Antoine Pitrou
Create a new one and set arrow-xxx as parent:
[image: image.png]
On Wed, Dec 12, 2018 at 7:46 PM Antoine Pitrou wrote:
>
> Apparently it's possible to create GitHub teams inside the Apache
> organization ourselves. I've just created a dummy one:
>
I'd also suggest that we extend Romain's effort to add labels to all
languages, review states, and mabye. While the string labeling with [],
works, github search/filtering is not very good compared to filtering by
labels.
lang-{R,c++,py,java,...}
review-{wip,ready}
Apparently it's possible to create GitHub teams inside the Apache
organization ourselves. I've just created a dummy one:
https://github.com/orgs/apache/teams/arrow-xxx/members
However, I cannot create a child team inside of the arrow-committers
team. The button "Add a team" here is grayed
I like the GitHub teams approach. Do We need to ask INFRA to create them?
On Wed, Dec 12, 2018, 7:28 PM Sebastien Binet On Wed, Dec 12, 2018 at 7:25 PM Antoine Pitrou wrote:
>
> >
> > Hi,
> >
> > Now that we have a lot of different implementations and a growing number
> > of assorted topics, it
On Wed, Dec 12, 2018 at 7:25 PM Antoine Pitrou wrote:
>
> Hi,
>
> Now that we have a lot of different implementations and a growing number
> of assorted topics, it becomes hard to know whether a PR or issue has a
> dedicated expert or would benefit from an outsider look.
>
> In Python we have
Hi,
Now that we have a lot of different implementations and a growing number
of assorted topics, it becomes hard to know whether a PR or issue has a
dedicated expert or would benefit from an outsider look.
In Python we have what we call the "experts" list which is a per-topic
(or per-library
14 matches
Mail list logo
