3 for all reasons above.
Keeping the examples in the Beam repository is a straightforward way to let
the examples being visible and maintainable. And as Lukasz Cwik mentioned,
the Quickstart makes a clear and easy approach for users to generate the
archetype and run examples.
I did not see enough b
+1 for 2, it would be nice to have a example project in it's own GitHub
repo. Might not need to be an "official" repo thought. Could we provide
links to community supplied examples?
On Thu, Aug 9, 2018, 2:30 PM Robert Bradshaw wrote:
> (3)
>
> In particular, I see a lot of value for (quoting the
(3)
In particular, I see a lot of value for (quoting the proposal)
"""
Since then, there have been
numerous updates, increased Python parity, and new features that do
not have accompanying examples employing best practices and
demonstrating an end-to-end experience for new users. We would like to
3 for all the reasons discussed above. I think there are better ways to
improve the status quo without the extra maintenance of having a new repo
for this.
On Thu, Aug 9, 2018 at 7:00 PM Ahmet Altay wrote:
> If we go forward with (3), could we actually update our documentation on
> how we will s
If we go forward with (3), could we actually update our documentation on
how we will support casual example contributions? I think we will need to
have information on how to add links to the new examples people want to add
to the set, what examples would be good additions to the Beam repo and what
3 (if contributors are up for voting) - We want to have beam maintained
examples in main repo. This will give good man to users and allow us to
test those easily with minimal maintenance.
We can add links to opensource user repositories to our documentation/wiki.
This will be flexible enough to pr
Here is the Rose', David's, and Gris' proposal in text form, I hope
the copy/paste helps:
Apache Beam Examples Repository
Authors: Rose Nguyen (rtngu...@google.com), David Cavazos
(dcava...@google.com), Gris Cuevas (g...@apache.org)
Status: Proposal
Created: 2018-07-30
Updated: 2018-07-30
Summ
I'd also vote for 3: I don't see much added value in separating the
repos and I see much additional effort to be done in maintaining extra
repo(s) (updating examples when new version of beam sdk comes out) and
their infrastructure (jenkins, etc). What Lukasz Cwik said about mvn
archetypes and how e
3 - I agree with JB, Charles and Lukasz arguments above saying why we need to
have examples and main code in the same repository (+ website code base will
move there soon). I don’t see any huge benefits to have examples aside and, at
the same time, it will bring additional complexity and burden
Hi guys,
For this kind of discussion, I would prefer to avoid Google Doc and
directly put the point/proposal on the mailing list.
It's easier for the community to follow.
The statement is more for 3 because it's more convenient for users to
easily find the examples and include in the distributio
Charles, I agree with your comments and questions. I want to add one more
benefit that was mentioned earlier:
A place for people to contribute example that is not tied to the beam
release cycle. Such a repository could be a place for casual contributors
to add examples over time.
On Wed, Aug 8, 2
It looks like the main claim is that 1 and 2 have the benefit of increasing
visibility for examples on the Beam site. I agree with Robert's comments
on the doc which claim that this is orthogonal to whether a separate
repository is created (the comments are unresolved:
https://docs.google.com/a/go
I'd vote for 2.
Giving independence to an example repository and creating the right
infrastructure to maintain them will give visibility to the efforts our
users are creating to solve their uses cases with Beam. I also want to make
the process of sharing common work more easily.
Re:The examples t
I would go for 1 or 3 to be consistent.
Regards
JB
On 08/08/2018 18:38, David Cavazos wrote:
> Hi everyone!
>
> We discussed several options as well as some of the implications of each
> option. Please vote for your favorite option, feel free to back it up
> with any reasons that make you feel t
I would vote for 3.
My reasoning is that Java has a good mechanism to get a starter/example
project going by using the the maven archetypes already. Our quickstart
guide for Apache Beam for the Java SDK already covers generating the
examples archetype.
We could point users to the starter project a
I guess I'm voting for 2. Tests obviously belong in the code repo, both as
a sample usage (not "how-to", more like "man") and, well, for testing.
These pipelines might not be annotated as completely and include hitting
edge cases and other non-standard situations.
Any example where the primary pu
2 - examples that rely on experimental API can still stay in where they are
because such examples could be changed.
-Rui
On Wed, Aug 8, 2018 at 10:52 AM Charles Chen wrote:
> 3 - We benefit from increased test coverage by having examples together
> with the rest of the code. As Robert mentions
3 - We benefit from increased test coverage by having examples together
with the rest of the code. As Robert mentions in the doc, hosting the Beam
examples in the main repository is the best way to keep the examples
visible, tested and maintained. Given that we recently moved to a single
reposito
2 - Similar to Huygaa, I see value in keeping a core set of examples tested
and maintained against head. At the same time I understand the value of a
growing set of community grown examples that are targeted against a
pre-defined versions of Beam and not necessarily updated at every release.
On We
2 - I like the idea of having a separate repo where we can have more
freedom to check in examples. However, we benefit from having immediate
core examples in Beam for testing purposes.
On Wed, Aug 8, 2018 at 9:38 AM David Cavazos wrote:
> Hi everyone!
>
> We discussed several options as well as
Hi everyone!
We discussed several options as well as some of the implications of each
option. Please vote for your favorite option, feel free to back it up with
any reasons that make you feel that way.
1) Move *all* samples to a *new *examples* repository*
2) Move *some* samples to a *new *exampl
21 matches
Mail list logo
