Filip Maj <fil_at_adobe.com> writes:
> Without a doubt getting access to the project mirrors on GitHub is a
> must-have. Setting up different teams on GitHub is trivial. Could have a
> "committers" team, and any other team deemed necessary. We can then add
> permissions such as ability to administer the github project to these
> As for sending the patch, I don't see anything wrong with accepting a
> patch via GitHub. I fail to see the difference between accepting a patch
> via e-mail on dev lists vs. doing so via GitHub. In fact, I would say that
> accepting the patch on GitHub is *easier* than any other approved method
> in Apache so far (that I've experienced). You can comment on specific
> lines of code in a clearer fashion, keep track of changes to the patch (if
> necessary) also very cleanly, in a timeline sort of fashion, where changes
> to the patch as well as overall comments are chronologically ordered. Very
> easy to see how a patch evolves.
> As a current committer on an incubating project that went from a
> GitHub-based project to an Apache project (incubator-apache-cordova), this
> issue resounds very strongly in me. I would love to help out in any way I
> can to get this figured out.
I had a look at incubator-callback-dev and I didn't see much discussion
about pull requests or patches. I did find one:
which leads to
The discussion about the patch appears to be split across the dev list
and the github site.
The Subversion project discusses patches on dev_at_subversion.a.o. For me
it is much simpler if the patch appears in my email client. When I want
to comment on a patch it's available to quote and the discussion stays
in one place archived on the dev list. Your work flow appears to push
some/all patch discussion off the dev list and onto github.
uberSVN: Apache Subversion Made Easy
Received on 2012-05-24 13:11:51 CEST