bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updating the progress


From: Madhusudan C.S
Subject: Re: Updating the progress
Date: Mon, 9 Jun 2008 20:45:06 +0530

Hi Olaf,

Well, not being familiar with libnetfs, I unfortunately can't really
tell whether the code makes sense.

I didn't discover any obvious errors when looking at it -- but then,
it's not surprising, considering that most of the code seems to be
template code more or less directly copied from some other translator(s)
:-)
I must again point out that if you copy code, you should mention (below
the copyright line) that the code is based on ftpfs (or whatever it is
based on), and include the copyright notice from the orignal file.
 
Yes, some parts of the code is a template of other netfs translators. But if seen keenly, nearly almost all the translators I am referring follows the same template or rather have copied the template from one another. Really without any documentation on how to actually use netfs, I have no other choice than doing that, since it is difficult to take the path of my own which should be different because thats not well tested. To be on safer side I thought of using the template of ftpfs which is in hurd main source only, since it is copyrighted to FSF. I hope that will not have any adverse effect on my code in terms of copyright and license issues.  Also I would like to tell and I have already said that, struct procfs_dir and procfs_dir_entry and related initializers was really taken ftpfs and so I would like to include the ftpfs copyright notice in those files only, though all the code is not an  exact copy.

Aside from that, you are not following conventions in the commit
messages (which has very adverse effects on some git tools): You should
start each commit message with a single line summing up the commit, a
blank line, and only then a detailed description what you changed.

If you find that you can't sum up the commit in a single line, this most
probably means that you have several individual changes, which should
actually go into seperate commits... From what I saw, this is often the
case.

Also, please check the diffs more closely before comitting: In several
commits you have changes that aren't mentioned in the commit message,
and in fact seem totally unrelated to the rest of the commit...

OOPS I am really sorry, I did not know about this convention till now, or nobody had pointed out to me for this wrong convention in commit messages. I am really sorry. I will follow the conventions henceforth and please point out if I break it.

Also before I read this mail I had done some large changes in the code. It will be an hectic task to revert back and follow these conventions for atomic commits. So that will be one last commit I will be doing not following this conventions. It takes simply too much of time to do that now. Kindly oblige. 

BTW I wonder, why are you keeping build logs in git?...

Aah I wanted to tell about that myself, when we discuss among our friends about the progress, I usually used to tell about the silliest programming errors we make during programming which leads to hours of work to find and fix it. So many of them asked me to maintain a build log so they can see how things are going, and also I thought it would be nice for me to go through such things, because this is the first big free software project I am doing that too from scratch. I understand your concern that it would make the repository very big unnecessarily. I wont be transferring that to Hurd CVS you provide us. Is that ok or should I discontinue that from git?
 



--
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

reply via email to

[Prev in Thread] Current Thread [Next in Thread]