|
| From: | Reuben Thomas |
| Subject: | Re: [Bug-zile] Google Summer of Code 2014 |
| Date: | Tue, 11 Mar 2014 18:28:18 +0000 |
Sumeet GarnaikThank YouHello Sir,Thank you for your support and all the primer you just gave me to start developing.It is really helpful,I am on it and will keep you posted regarding the progress of my current task on list.
On Tue, Mar 11, 2014 at 3:51 AM, Gary V. Vaughan <address@hidden> wrote:
Hi Garnaik,
Recently, I began keeping a mirror of GNU Zile in my github account:
On Mar 10, 2014, at 5:56 AM, Garnaik Sumeet <address@hidden> wrote:
> It would be really great if you point me in certain direction to focus to,then I would start working on that part,like @gary Sir said about adding unicode support to zile would be a great start,I would love to do that part first,please give me some starters on adding that functionality.
http://github.com/gvvaughan/zile
I recommend that you fork that so that you have a copy in your own
github account, and make sure that you can rebuild it from there, as
well as the copy you have from savannah. This will make it much
faster and easier for you to submit pull-requests for your changes,
and for us to give you feedback and merge them back into the main
repository.
The first task on your list is the easiest, so feel free to dive
right in and start developing it - feel free to use github facilities
to ask for help or feedback as you go, and each time you have any
small self-contained patch that is an improvement (no matter how
small) you can initiate a github pull request to have one of us
review it and return feedback or merge it into the main repository.
In terms of how to start working on unicode functionality, I
recommend that you look through the recently added unicode support
modules in luarocks, choose the one that seems most suited to
integration, and begin to work on patches for that.
You can commit frequently to your forked repository, and the best
way to make reintegration upstream as easy as possible is to work
in a feature branch. E.g. from your local working directory from
your own github fork of Zile:
git checkout -b feature/unicode
Another thing you should do, to minimize the amount of reworking we'll
ask you for, is to make sure you commit every small self-contained
change, with a log message suitable for reformatting into the release
ChangeLog. I'll help you with this as we go along, but the main point
at this stage is to be careful not to commit when the test suite
doesn't complete correctly, and not to conflate two (or more!) changes
in a single commit.
There are lots more useful hints in the generated HACKING file in
the top level directory of the Zile tree that you'll find useful too.
Beware that you'll need to to have run bootstrap successfully to see
that file.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
| [Prev in Thread] | Current Thread | [Next in Thread] |