On 19 February 2014 15:25, Robert Samuel Newson <[email protected]> wrote:
> Yes. It’s misleading for folks that stumble on it. > +1 > On 19 Feb 2014, at 14:22, Noah Slater <[email protected]> wrote: > > > Should we decommission our Review Board instance? > > > > On 19 February 2014 14:49, Andy Wenk <[email protected]> wrote: > >> On 19 February 2014 14:15, Jan Lehnardt <[email protected]> wrote: > >> > >>> > >>> On 19 Feb 2014, at 13:51 , Garren Smith <[email protected]> > wrote: > >>> > >>>> I agree with Robert here. Github integration is getting really good > now > >>> and its so easy to review a pull request with Github. I think we should > >>> rather use github. > >>> > >>> +1 > >>> > >> > >> also +1 for github ... Humbedooh does magic things :) > >> > >> > >> > >>>> > >>>> On 19 Feb 2014, at 2:49 PM, Robert Samuel Newson <[email protected]> > >>> wrote: > >>>> > >>>>> We intend to review work before merging to master, which is why we > have > >>> an account on Review Board in the first place, to see if it can help. > >>>>> > >>>>> Given the level of integration with github now, I think we can and > >>> should use pull requests for intra-team work just like we already do > for > >>> requests from outside of the group with commit bits. > >>>>> > >>>>> B. > >>>>> > >>>>> On 19 Feb 2014, at 12:45, Florian Westreicher Bakk.techn. < > >>> [email protected]> wrote: > >>>>> > >>>>>> That's also how we did it. It seems the most sensible way to handle > >>> reviews. > >>>>>> > >>>>>> I would really encourage you all to try reviews, they are a great > way > >>> to improve code quality. They are quick to create and quick to read. A > >>> typical review takes less than 20 minutes. > >>>>>> > >>>>>> Jan Lehnardt <[email protected]> wrote: > >>>>>>> > >>>>>>> On 19 Feb 2014, at 03:13 , Florian Westreicher Bakk.techn. > >>>>>>> <[email protected]> wrote: > >>>>>>> > >>>>>>>> The patch creation is simple but the real problem is the culture. > >>>>>>> Review board assumes pre commit Reviews where on fact the code is > >>>>>>> usually already pushed, which makes the review post commit. > >>>>>>> > >>>>>>> That's why we use feature/fix branches. The review happens before > the > >>>>>>> code lands on master (or other release branch). In our git world, > >>>>>>> pre/post commit is pre/post push. > >>>>>>> > >>>>>>> Jan > >>>>>>> -- > >>>>>>> > >>>>>>>> > >>>>>>>> Robert Samuel Newson <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>> I think we should use github instead (especially as the > integration > >>>>>>>>> continues to improve). > >>>>>>>>> > >>>>>>>>> The 'upload patch file' approach for Review Board makes it a > >>>>>>>>> non-starter in my opinion. (Yes, we could insist every > participant > >>>>>>>>> installs command lines tools to finesse that, but come on) > >>>>>>>>> > >>>>>>>>> B. > >>>>>>>>> > >>>>>>>>> On 18 Feb 2014, at 18:25, Florian Westreicher Bakk.techn. > >>>>>>>>> <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>>> I have used review board in the past. It's easy to use but you > can > >>>>>>> do > >>>>>>>>> most of it on > >>>>>>>>>> github nowadays. Just open pull requests, others can review and > >>>>>>>>> comment them. > >>>>>>>>>> > >>>>>>>>>> Noah Slater <[email protected]> wrote: > >>>>>>>>>>> Hi folks, > >>>>>>>>>>> > >>>>>>>>>>> It's been two weeks since we got our Review Board set up. But > it > >>>>>>>>> looks > >>>>>>>>>>> like nobody is using it. Is this something we want to continue > >>>>>>>>> using? > >>>>>>>>>>> Does someone want to draft some documentation for it? (Or just > go > >>>>>>>>>>> first and get the ball rolling?) > >>>>>>>>>>> > >>>>>>>>>>> https://reviews.apache.org/groups/couchdb/ > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Sent from Kaiten Mail. Please excuse my brevity. > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Sent from Kaiten Mail. Please excuse my brevity. > >>>>>> > >>>>>> -- > >>>>>> Sent from Kaiten Mail. Please excuse my brevity. > >>>>> > >>>> > >>> > >>> > >> > >> > >> -- > >> Andy Wenk > >> Hamburg - Germany > >> RockIt! > >> > >> http://www.couchdb-buch.de > >> http://www.pg-praxisbuch.de > >> > >> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 > >> > >> https://people.apache.org/keys/committer/andywenk.asc > > > > > > > > -- > > Noah Slater > > https://twitter.com/nslater > > -- Andy Wenk Hamburg - Germany RockIt! http://www.couchdb-buch.de http://www.pg-praxisbuch.de GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 https://people.apache.org/keys/committer/andywenk.asc
