General mailing list for discussions and development of PeerLibrary and related software.

List archive Help


Re: [PeerLibrary dev] Regular development


Chronological Thread 
  • From: Xuan An Thi Ho < >
  • To:
  • Subject: Re: [PeerLibrary dev] Regular development
  • Date: Tue, 10 Sep 2013 19:33:20 -0700

Hi,

Can I access the building and lab by myself? Last time Rodrigo took me and he used a card, so I'm not sure what I'm supposed to do...

An


On Tue, Sep 10, 2013 at 6:09 PM, Mitar < > wrote:
Hi!

If you want, sure! So we always have some things to write, but probably
not for the whole evening, so bring some your own stuff to work on as
well. We would love your company. :-)

(This goes for others as well. We have plenty of free tea, cheap
chocolate and our nice company, so just come around.)


Mitar

> Hi!
>
> Should I come to the lab also?
>
> Best,
> An
>
>
> On Tue, Sep 10, 2013 at 2:13 PM, Mitar < > wrote:
>
>> Hi!
>>
>> Ah, I forgot. The idea is that we teach others in this way better
>> programming. Everyone has different experience and by code reviewing we
>> can help each other to become better programers.
>>
>> And remember, somebody commenting on your code is a good thing. This is
>> a comment of the code, not of you as a person.
>>
>>
>> Mitar
>>
>>> Hi!
>>>
>>> We started working regularly in person on Mondays, Tuesdays, Wednesdays
>>> at 8 PM in BiD lab:
>>>
>>> http://bid.berkeley.edu/
>>>
>>> We started using pull requests for internal development as well, so you
>>> can follow progress on various features online on GitHub:
>>>
>>> https://github.com/peerlibrary/peerlibrary/pulls
>>>
>>> (You can check closed pull requests for already merged pull requests as
>>> well.)
>>>
>>> So in short, the idea is that whoever starts working on a feature in
>>> PeerLibrary, makes:
>>>
>>> - a branch (called feature branch) where only the commits related to
>>> this one planed feature or fix or whatever will be
>>> - pushes the branch to GitHub PeerLibrary repository (no need to use
>>> your fork)
>>> - makes a pull request from that branch to master branch of PeerLibrary
>>> repository
>>> - then others can review the code, put comments and so on
>>> - when somebody else agrees that the code is OK and that is ready to
>>> merge (by commenting LGTM (look goods to me)), a person who opened the
>>> pull request can (if he or she things it is ready as well) merge it into
>>> master
>>>
>>> So the main idea is that the same person both opens and merges the pull
>>> request (he or she knows if this is all that was planned for this pull
>>> request). And in meantime others can comment and review code.
>>>
>>> Command line git commands for all this should be learned. If there are
>>> some issues with that, the best is to show them in person. Or we can
>>> write a guide as well.
>>>
>>> One mine suggestion is also to not be afraid to have PeerLibrary cloned
>>> multiple times locally, for example, for each branch. It is much better
>>> to have each branch in its own local clone than to try to switch between
>>> branches in one directory. It can get quite messy sometimes (with files
>>> git is not tracking especially).
>>>
>>> We are loosely basing our development on this model (we don't yet need
>>> master/develop distinction because we have not yet released anything):
>>>
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>
>>> I hope this will make the whole development more open and easier for
>>> others to join. If you have any questions, just ask.
>>>
>>>
>>> Mitar
>>>
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>>
>> Settings and unsubscription:
>> http://lists.peerlibrary.org/lists/info/dev
>>
>> Public archive:
>> http://lists.peerlibrary.org/lists/arc/dev
>>
>

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Settings and unsubscription:
http://lists.peerlibrary.org/lists/info/dev

Public archive:
http://lists.peerlibrary.org/lists/arc/dev




Archive powered by MHonArc 2.6.18.

Top of page