-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/11/2010 11:45 AM, Tor Arne Vestbø wrote: > On 11.11.10 08.28, Mcdonald Jason (Nokia-MS-Qt/Brisbane) wrote: >>> - Check that there's only one author in the patch-set >> >> That restriction seems a little odd to me. Can you explain the reason >> behind it? > > I was not very clear on that one. It's more about making sure that we > have signed contributor agreements for every contributor in a patch-set > than actually limiting the number of authors in a set.
As a project, if you want to encourage contribution and collaboration, then you need to minimise the number of hurdles and barriers that people face when getting changes integrated. Technical barriers should be the only clearly visible ones when trying to integrate a contribution. Legal or political barriers are a good way to ensure that you won't have repeat contributors sticking around, and should be minimised for that reason. For instance, Something I'm working on right now, Qt on Skia, is too big a task for me to handle personally (as I'm totally new to graphics), so I"m collaborating with a close friend of mine who has significantly more experience in the area. Thanks to this rule, I'm having to be the one doing the actual commits, thus getting my name on their work, for no good reason. If both of us weren't a so passionate about Qt, we might just not bother. If it must be enforced that all contributors have signed a CA, then that shouldn't be too hard to implement, and is much more fair than arbitrarily saying that a single person must write everything. I bet that isn't true for things like Lighthouse or QtDeclarative. It goes without saying, but if everyone is going through this process, then this process is going to have to work for everyone. >> I would see the EWS as a means to catch errors that are obvious and/or >> are easy/cheap to find automatically -- the kind of things that a human >> reviewer would likely see as wasting their time: >> >> - check that there are no new compiler warnings, >> - check that new classes/functions have docs, >> - check that there are no new qdoc warnings, >> - run static checking tools, e.g. Coverity, if it runs fast enough. > > Absolutely agree. The idea of the EWS is to catch things so that the > human reviewers don't have to waste precious cycles on it. > > But, if you apply that principle to the integrators as well, you might > want to "summon" a bot for doing static analysis, or a full build, or a > build on a slow platform, so that you (as a contributor), can find and > fix any errors _before_ the patch gets through to a > maintainer/integrator, possibly wasting his or hers time by blowing up > in the final quality gate. > > In that sense the EWS is more like a network of try-bots. I don't think you necessarily need to automate it quite this far. Human interaction is, after all, how communities get built, and how people learn to do better. It also means that false positives won't mean that someone's hard work gets chucked in the trash without an easy recourse for getting it in. The idea of automation is great, but at the end of the day, I think there should be humans making the final calls in most cases. >> Finally, I think there needs to be a way for a human arbiter to override >> the decision of the EWS in the (hopefully rare) cases where the EWS will >> reject a valid change. > > Right. I think the bots should be mostly advisory, not have any real > power in accepting (definitely not), or rejecting (perhaps only if the > apply fails) patches. This is how things work in the WebKit project: Ah, OK, perhaps I misinterpreted what you meant by the "maintainer/integrator wasting his or hers time" bit. If that's the case, disregard the above. > > Tor Arne -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2+ElAAoJEL09WxvSn7p9h+UIAJtkYWZdNxNzt6nNuIv67lbO JeBKxRsOmpRYZVmi5L6qefhLDrTJaIx6dGc8sdCUliXJ42YTKk4IEH3FP5AcmSEy 2q1jBJF+3bnV+k1yLzL3E3mYwE7OeDX/AMyh+PI43oBMgUbgfukawSXfP8S6BmYD G2RUkH3P3NLEAy/a/17KH0taSs3E232VNksuRHe/T6aSqaS6gJgH2yJmFzLfCt6b uj4YGkK8WaXS80oZS97deGGHBcMs+QurunHWgCg9tMCVqWVvB7PYtVgxnLXL/E7L qNP51AEtHLPXjIMuFaswAiEsQbFGTvp9bSQg7tUD7LyRHRv74QbOU3VXuApn9bk= =SO2P -----END PGP SIGNATURE----- _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
