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). > 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? -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b372d774-b381-4452-8134-98948762d830%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
