A little enforced away-from-computer time with power-cuts is not a bad idea - some of my most productive periods are spent on good old fashioned pen-and-paper work on planning, or even just staring at a computer printout of code-listings. I think you could spend some of the down time just thinking and writing things down with pen and paper: 1) what are the still missing pieces, and future directions? 2) what would a user or a developer interested in contributing/enhancing/adapting needs to know, and not yet obvious? 3) what are the known problems?
I just remember that we talked about python 3 support at the very beginning. I guess that's a "known problem" at the moment; I don't think you should tackle that at this point though - it is more important to get what's done into a state which is inviting for others to use and experiment, and comment, and maintainable in the long term, than adding new and buggy features in a rush. You can certainly adding a note about the "2to3" script which helps to migrate from python 2 and 3, and also the "from __future__ import ..." idiom for such things also, just as a note of help for possible future work. FWIW, out of the 173 commits as of just now, minus 1 from somebody else for the initial set up, there were just over 30 commits with a messages longer than the signed-off line. (one of them don't have a signed-off line - not compulsory - just that it suggests you either work on two computers, one of which doesn't have the auto-signed-off set up, or that you are inserting it by hand. Inserting by hand is not efficient, that's all). That's somewhat improvement - around commit 120, there were about 14. One of the things that bothered me a lot were the "refactor xyz" commits, for all the reasons why short commit mesages are bad: (1) the message is all too brief about what actually changed, (2) some words should be said about "why" it is done, (3) and "how" - what is moving from where to where, (4) frequently, what the message says, is not what is actually done - there are additional changes mixed in, which is unrelated to "refactoring". I think (4) is the worst crime in general - when a commit description does not match what the code diff actually does. -------------------------------------------- On Mon, 4/8/14, ahi <[email protected]> wrote: Subject: Re: status update? To: "Hin-Tak Leung" <[email protected]> Cc: "[email protected]" <[email protected]> Date: Monday, 4 August, 2014, 14:53 Current status:RDF Parsing Tag value parsingtag/value writingI have added a usage instructions page on the wiki https://github.com/ah450/sdpx-tools-python/wiki/Usage-instructions as for the known issues https://github.com/ah450/sdpx-tools-python/issues I have updated the README files and added example files to demonstrate all features. The next expected feature should be RDF writing since now we can format tag/value files and convert from RDF to tag/value but not the other way. <snipped> I have setup a local branch for editing my commit messages and experimenting with rebase. I am sorry I was unable to reply to your email sooner I have been experiencing severe connection issues and power cuts (throughout the country). -- Best Regards, Ahmed _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
