On Friday, November 17, 2017 at 10:37:59 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:
>>
>> Sounds like there is enough diversity of opinion that this discussion
>> should go on - first step seems to be deciding if we think the CLA
>>
>
> Some links about CLAs:
> https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/
> &
> https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/
>
> https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/
> http://contributoragreements.org/
> Some tools to manage CLAs: https://cla-assistant.io/ (by SAP),
> https://www.clahub.com/
>
> As a) purely "community-driven projects", that b) won't even be used by
> Google (their original author), I would say that we don't need CLAs (also,
> the choice of the Apache License protects the users from a lot of things
> already).
> That said, IANAL, and I'm not doing any work here on behalf of my
> employer; so people for whom CLAs are important should weigh in.
>
>
>> and/or gerrit-style review is important for all artifacts deployed to
>> org.gwtproject.
>>
>
> I *love* Gerrit, and use it daily at work; but I cannot ignore that GitHub
> pull requests have gotten a whole lot better those past years, and I have
> absolutely no problem using them instead of Gerrit; which is a barrier to
> entry that many don't even try passing (Go has had the same issue, they
> built tooling around it instead, and documentation, and despite that it's
> apparently still seen as a barrier to entry to many –Chrome and Android are
> different, as they're much bigger beasts already).
> Keeping in mind that gwt.googlesource.com is maintained by Google which
> wouldn't be involved in those projects, this poses the problem of who would
> admin Gerrit, and whether Google would host it indefinitely for us (Google
> is using pull requests for a lot of projects, and this includes j2cl –still
> a private repository–, jsinterop-base, jsinterop-generator, and elemental2).
> This all pushes for using GitHub pull requests.
> Now, from my PoV, each project maintainer would be free to choose how to
> manage code in their repo (see below): whether to use PRs for everything
> (never push to master), choosing a branching and merging strategies (I for
> one would use rebase and/or squash, possibly manually to squash some
> commits and preserve others, and follow "trunk based development"
> <https://trunkbaseddevelopment.com/> –this is actually what we do for GWT
> already; I'd love to see everyone embrace the same view, but I'm not sure
> forcing a "standard" is the way to go –bikeshedding, etc.), and versioning
> and release strategies (I think everyone would agree on using semver, but
> what about maintaining several versions in parallel? releasing at a
> scheduled cadence –like Guava and Dagger do for instance– vs. "release when
> it's ready", etc.)
>
> For the time being, it sounds like individual groupIds are the way
>> forward, with the expectation of migrating projects to org.gwtproject and
>> github.com/gwtproject once they reach a certain level of quality and
>> stability, once we decide what that is.
>>
>
> As far as I'm concerned, I'm formatting all my code using
> google-java-format (and enforce it in build) and checking it with Error
> Prone (FindBugs could possibly be a good addition).
> Wrt google-java-format, just like gofmt for Go, rustfmt for Rust,
> prettier+eslint for JS/CSS/etc., ktlint for Kotlin, etc. prevents
> bikeshedding on the formatting. I don't always like how it formats things,
> but at least I don't have to worry about it. “Gofmt's style is no one's
> favorite, yet gofmt is everyone's favorite.”
> <https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s>
> Similarly for Error Prone, nothing to configure, just let it fail your
> build (early, really early).
> But that's only a fraction of code quality (see also branching strategies
> above for another fraction).
> With smaller projects, I think we might be able to run tests on
> BrowserStack or SauceLabs, through Travis.
>
> Now, I'd like to advocate for more autonomy and responsibility for
> maintainers: manage their project the way they want, release when they
> want, use Maven or Gradle as they prefer, etc. This means that there might
> be projects that are more stable and/or of greater quality than others (but
> so are modules inside gwt-user already actually).
> Jenkins CI host all their plugin in their GitHub organization, and I don't
> remember someone being angry at the diverse levels of quality, stability,
> etc. Everyone seems to understand that they're maintained by different
> people and not "products from Jenkins". (btw, they don't seem to have a CLA
> either).
>
All sounds reasonable, but I'd want to see the committee agree as a group,
and our next meeting isn't for a bout 4 weeks. Might be nice to have more
process around those "maintainers" as well - adding/removing, ensuring they
are active, any dispute resolution. I might be putting the cart before the
horse, we can probably allocate a bunch of projects up front and worry
about this in a few months.
As per our name use policy, that should fall to the steering committee to
>> decide, but I at least would welcome more feedback from contributors on
>> what those standards might look like.
>>
>
> This is a good question Colin!
> Fwiw, I never had the intention to ever publish my work on
> gwt-{http,window,history,events,places} to any (binary) repository before I
> contributed it "back" to the @gwtproject organization. I had no reason to
> keep them private, so made them public, but I don't really expect anyone to
> use them yet, other than to experiment and give feedback to help make them
> better. It always was my intention to contribute them to @gwtproject, which
> is why I chose those gwt-* names and used the org.gwtproject package (and
> groupId).
>
>
>> Likewise from that name use document, we should avoid the use of
>> org.gwtproject packages as well until that time. This might make migration
>> a little trickier (changing packages multiple times) as we refactor various
>> modules out from gwt-user. For my part, I would like to see this line
>> blurred slightly or at least clarified - code which started its life in
>> com.google.gwt but isn't presently "controlled" by the committee due it it
>> being in progress should perhaps not be restricted in this way (in the same
>> way that Vaadin ships a GWT fork, but still uses com.google.gwt packages
>> for compatibility). We could phrase this in individual projects as "This
>> code came from GWT, and is incubating here until it is contributed back to
>> GWT", making it clear that the project is not intended to be a third party
>> tool, but is using the name in good faith that this will be again part of
>> GWT soon.
>>
>
> Sounds good.
> (won't do that for the above-mentioned projects though, as I'd like to see
> them moved to @gwtproject sooner rather than later; unless I'm asked to do
> so anyway)
> As soon as we start hosting projects in the @gwtproject org, this won't
> really be a problem either: with Andrei' proposal to ask for the repo and
> then start contributing to it.
> Though, what about GitHub forks that people use solely for contributing
> pull requests?
>
External gihub forks seem to be following the same spirit of the rule as
Vaadin's GWT fork I think, they just manage the release differently, and
are clear that they are shipping GWT, just with a different groupId, so I'm
inclined to go with it.
Likewise given Jens's and Goktug's remarks on standards and communication,
I'd personally like to see more dialog on the topic before making a
concrete decision and handing out control of repositories under gwtproject.
Given how permanent it is to deploy to central, maybe we consider just
snapshot releases for now, or third party maven repos?
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/044c93c8-0f6b-461f-8030-41c58bcd353d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
