Create a patch article

[Henry Conceição]

Hi mates,

I did update all the subversion mentions on the website and pointed to
github or the git repository. The only exception is the create a patch
page.

@git experts: can someone update it with a nice guide, please?

Cheers,
Henry Conceição

[John Simons]

We also need to update the Release Guide - http://www.castleproject.org/community/releaseguide.html

Cheers
John

[Simon]

perhaps just point to a few intros on github and git?

eg
http://help.github.com/forking/
http://kylecordes.com/2008/04/30/git-windows-go/

On Mar 24, 10:03 am, John Simons <johnsimons...@yahoo.com.au> wrote:
> We also need to update the Release Guide -http://www.castleproject.org/community/releaseguide.html

[John Simons]

Also should we add to each repository a readme file with info like
this:
http://github.com/DarthFubuMVC/fubumvc#readme

Cheers
John

On Mar 26, 7:49 am, Simon <simon.cr...@gmail.com> wrote:
> perhaps just point to a few intros on github and git?
>

> eghttp://help.github.com/forking/http://kylecordes.com/2008/04/30/git-windows-go/

[Michael Davis]

Are there any guidelines on which people to include on a pull request?

I've got a patch for Windsor I'd like to submit (see
http://groups.google.com/group/castle-project-users/browse_frm/thread/672c3302430d0e72
and http://groups.google.com/group/castle-project-users/browse_frm/thread/695494bdf18059fa
), and when I go to make the pull request, there are 15 accounts
selected by default and 5 more that aren't.

Is it preferred to send the request to all of the people selected by
default, or should I limit it to just a few or one? And if I limit
the request, who should get it?

If any of this depends on the project, then that definitely should be
documented somewhere, as well.

Thanks,
Michael Davis

On Mar 25, 3:55 pm, John Simons <johnsimons...@yahoo.com.au> wrote:
> Also should we add to each repository a readme file with info like
> this:http://github.com/DarthFubuMVC/fubumvc#readme
>
> Cheers
> John
>
> On Mar 26, 7:49 am, Simon <simon.cr...@gmail.com> wrote:
>
> > perhaps just point to a few intros on github and git?
>

> > eghttp://help.github.com/forking/http://kylecordes.com/2008/04/30/git-w...

[John Simons]

Actually it gets even worse.
Now if you try to do a pull request "maxild" appears in the list as
well, for all castle projects!
So, does this mean that every time we merge a pull request the user
that sent it gets automatically added to the list?

Cheers
John

On Mar 30, 5:52 am, Michael Davis <nerei...@gmail.com> wrote:
> Are there any guidelines on which people to include on a pull request?
>

> I've got a patch for Windsor I'd like to submit (seehttp://groups.google.com/group/castle-project-users/browse_frm/thread...
> andhttp://groups.google.com/group/castle-project-users/browse_frm/thread...

[John Simons]

I found a few instructions on how to send a patch:
http://wiki.github.com/rakudo/rakudo/steps-to-create-a-patch
http://wiki.github.com/rakudo/rakudo/frews-recommended-workflow
Are these instructions usable for us? or are we just going to support
pull requests?

Git experts, we do need some advice?

Cheers
John

[Morten Maxild]

The docs say that by default, you will see everyone who has a project in
your projects 'network'. Because I forked castle.core I am there too;-(

I agree this may seem unfortunate, but github has all forks on an equal
footing. Maybe the confusing thing right now is that so many people are
receiving the pull request by default (15 seems like a lot of people
considering the size of the network?). As more and more people are forking
(to create their own branches, and contributing changes) most contributors
will not add recipients by hand, and the recipients added by default, should
be the right people. I cannot say if the default recipients are the right
people, because I know very little about Castle project.

For a popular project like jquery there are 197 people in their network, and
rails has 899 people. The pull request dialog has a checkbox list for
everyone, but only 'core' people are chosen by default!

I know we are foremost talking about improving the pull request workflow on
github, but maybe the move away from centralized control of revisions, to
decentralized branching/forking and merging of tracked changes plays a role
here?

Cheers
Maxild

Cheers
John

--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to
castle-project-d...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.

[Mauricio Scheffer]

For Castle, I'd just forget about github's pull request feature and instead recommend people to post on this group. Something like:

"Hi Castle team, I have implemented/fixed/improved such and such for <insert project> here: http://github.com/maxild/Castle.Core/tree/dev, please review it / merge it"

IMHO github's pull request is only useful if there's a single central maintainer. But in Castle, nobody really owns the user "castleproject".

On patches vs forking: I'd recommend patches only for very trivial, single-file fixes, which can be posted and reviewed on this group. Otherwise, fork.

Comments?

Cheers,

Mauricio

[Morten Maxild]

I usually do something like this http://wiki.github.com/rakudo/rakudo/frews-recommended-workflow (Note: I would never use an old-time patch/diff file when using git, but the rest of article is fine)

That is master (as in learn) rebase and interactive rebase when creating a patch (or patch series). Simplified workflow (add, commit, diff etc. of local workflow assumed known here):

0) Always work on 'myname/workbranch' (never myname/master), then before sharing local work...
1) use 'git rebase': to rebase work-branch to tip of master before pushing (to avoid conflicts for upstream integrator)
2) use 'git rebase -i': to clean up patch series before pushing (squash, pick etc) and deliver 'logical/clean changes' to upstream integrator
3) git push to myname/work-branch (git push origin workbranch)
4) Send pull request....and wait for feedback
5) If accepted (i.e. pulled in upstream) a 'git pull upstream master' will work without conflicts, and workbranch can be deleted.

There are so many tutorials and best practices, but I haver found that the official GIT manual has some great advice about working with patch (series).

HTH
Maxild

[Morten Maxild]

That explains the many recipients (person(s) managing integration) in the network compared to the size of the network. In fluent nhibernate (146 people in the network) it seems there is a more tree-like 'network of trust'. James (the owner) pulls from Paul and Hudson (the 'Lieutenants')....okay it is probably not like Linux kernel at all.....but you get the idea 

But how on earth will you communicate to 'complete utterly newbies' like me that pull requests is against the Castle workflow, when every github project (I know of) embraces pull requests?

I agree patches is for centralized/controlled source control management. Forking/branching and merging in a network is the way to do it. So much easier to contribute that way.  

Cheers

Maxild

[John Simons]

I don't really see a problem with using github pull requests, as long
as we document how we want the users to use it, eg. leave the default
users ticked.
That way all committers get notified by email and anyone can act on
it.
Regarding user "castleproject", can we associate this user with
castle-pro...@googlegroups.com, so that pull requests get
emailed to the list?

> instead recommend people to post on this group.

I don't like the idea of sending emails to this list, I much rather
use the issue tracker for that, after all that is what is for.

> On patches vs forking: I'd recommend patches only for very trivial, single-file fixes, which can be posted and reviewed on this group.
> Otherwise, fork.

agree, but once again we need to document or provide links to eg
http://wiki.github.com/rakudo/rakudo/frews-recommended-workflow

Also are we turning on core.autocrlf ?

Cheers
John

On Mar 30, 9:57 am, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:

> For Castle, I'd just forget about github's pull request feature and instead
> recommend people to post on this group. Something like:
>
> "Hi Castle team, I have implemented/fixed/improved such and such for <insert
> project> here:http://github.com/maxild/Castle.Core/tree/dev, please review
> it / merge it"
>
> IMHO github's pull request is only useful if there's a single central
> maintainer. But in Castle, nobody really owns the user "castleproject".
>
> On patches vs forking: I'd recommend patches only for very trivial,
> single-file fixes, which can be posted and reviewed on this group.
> Otherwise, fork.
>
> Comments?
>
> Cheers,
> Mauricio
>

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/castle-project-devel?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>

[Morten Maxild]

I don't think core.autocrlf can be changed at this stage? You have to live with no line-ending conversions. Otherwise you have to convert your existing working tree, which is not an easy task.

> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[Mauricio Scheffer]

Yes, it can be changed at any time (not for the entire history of course, that would need history rewriting), it's not hard, see http://help.github.com/dealing-with-lineendings/

This was discussed not long ago and several people voted against autocrlf so it remains that way: http://www.mail-archive.com/castle-pro...@googlegroups.com/msg07804.html

Cheers,

Mauricio

[John Simons]

We can use "Fork Queue" instead of patch files, see
http://github.com/blog/270-the-fork-queue

On Mar 30, 9:57 am, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:

> For Castle, I'd just forget about github's pull request feature and instead
> recommend people to post on this group. Something like:
>
> "Hi Castle team, I have implemented/fixed/improved such and such for <insert
> project> here:http://github.com/maxild/Castle.Core/tree/dev, please review
> it / merge it"
>
> IMHO github's pull request is only useful if there's a single central
> maintainer. But in Castle, nobody really owns the user "castleproject".
>
> On patches vs forking: I'd recommend patches only for very trivial,
> single-file fixes, which can be posted and reviewed on this group.
> Otherwise, fork.
>
> Comments?
>
> Cheers,
> Mauricio
>

> > (seehttp://groups.google.com/group/castle-project-users/browse_frm/thread.
> > ..
>
> > andhttp://groups.google.com/group/castle-project-users/browse_frm/thread.
> > ..

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/castle-project-devel?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>