Github is a new paradigm. We can go ahead with business as usual, but if we
want to get the good stuff out of github, we have to really lean on it, i.e.
use it properly.
as reference points.
If we have needs that those posts don't address, please raise them here, and
after discussion here: https://github.com/contact where some guy called Petros
Amiridis will courteously respond within a day or so.
On Mon, Nov 21, 2011 at 10:53 PM, Alex Clark <aclark@...> wrote:
>> On 21 November 2011 13:58, Anthony Gerrard<anthonygerrard@...> wrote:
>>> Just to clarify are we now not supposed to check in our own fixes but
>>> instead issue a pull request? On svn I used to just check in bug fixes as
>>> and when I needed to (not very often) and would post to this list whenever
>>> I thought a change might be controversial
You can go ahead with business as usual, but you can also log a pull request
and @mention someone with their github username, and they will be notified.
See https://github.com/blog/821 ("Mention @somebody. They're notified.")
What you would normally do: make a branch, check in to your heart's content on
your branch, and use pull requests @partner to talk about your work:
- "Actually, we use it more as a branch conversation view more than a pull
- "we use the Pull Requests to review the code long before we actually want to
merge it into master for deployment."
(from http://scottchacon.com/2011/08/31/github-flow.html )
I think we'd want @plonedev which notifies this list.
Delete the branch after merging.
>> My personal opinion: I think we should encourage people to check in
>> things directly and only use pull requests when they'd like review. I
>> sincerely doubt we'll have enough people who feel empowered and have
>> time to review pull requests and merge at a regular basis.
This is the wrong way to think about pull requests.
Pull requests don't go to "everybody", they go to specific collaborators.
If you're really working in glorious isolation, by all means check in directly.
I'm willing to bet that 99% of the time you are in conversation with others on
your team or with the original author or with others who are using the code
> The ability to fork & send pull requests TTW is an amazing feature, but
> in Plone's case it is better suited to folks outside the project who see
> some code and get inspired to fix it
Agreed, with the caveat regarding legality. People *inside* the project should
*branch* (short-lived branches) and send pull requests. Merge with no pull
request if you want to dispense with review, but review really doesn't hurt.
> That said, I find myself forking and sending pull requests (e.g.
> https://github.com/plone/plone.app.blob/pull/1) and in this case I don't
> have the expectation that my fork will be merged unless I take the time
> to work with the author (witsch in this case) to make it acceptable.
Yes, and for that pull requests are very convenient. But it's probably better
to get yourself added to https://github.com/plone/ and branch, rather than
jean . .. .... //\\\oo///\\