RE: [GSOC] Make the Go library go get-able
On Sun, 8/6/14, Gary O'Neall g...@sourceauditor.com wrote: I was not able to find an easy way to make the git repo cloneable without the .git. We are using gitolite to configure the repositories, so if there are any git experts on the mailing list with a solution, pls. let me know. That sounds rubbish. Although git has its own protocol (git://, over port 9418), it can operate over ftp, http, rsync, etc and a dozen of other network protocols also also. A non-exhaustive list is at the bottom of man git-clone. Though, it is not often documented that a directory needs to have an empty file git-daemon-export-ok to be acted on by the git server daemon. Please just read up on that. ___ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
RE: [GSOC] Make the Go library go get-able
Just to clarify - I only have access to the gitolite config file to configure git access. I do not have access to the server itself. I do admit I am not a git expert, so any advice or pointers is appreciated. If there is a configuration option to solve Vlad's problem, please be specific on the configuration changes. If there is something that Vlad can do in accessing the repository differently, please be specific on what steps can be taken. Thanks, Gary -Original Message- From: Hin-Tak Leung [mailto:ht...@users.sourceforge.net] Sent: Sunday, June 8, 2014 12:49 PM To: 'Vlad Velici'; spdx-tech@lists.spdx.org; Jack''Manbeck; Gary O'Neall Subject: RE: [GSOC] Make the Go library go get-able On Sun, 8/6/14, Gary O'Neall g...@sourceauditor.com wrote: I was not able to find an easy way to make the git repo cloneable without the .git. We are using gitolite to configure the repositories, so if there are any git experts on the mailing list with a solution, pls. let me know. That sounds rubbish. Although git has its own protocol (git://, over port 9418), it can operate over ftp, http, rsync, etc and a dozen of other network protocols also also. A non-exhaustive list is at the bottom of man git-clone. Though, it is not often documented that a directory needs to have an empty file git-daemon-export-ok to be acted on by the git server daemon. Please just read up on that. ___ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
current status of the java binding, and GSoC
Ahmed: I think I already explained that you must write a few words every
10 days or so during the GSoC period on progress. You can plan your own
work and how you want to spend your time on a day-to-day basis and the approach
you take; but GSoC is supposed to be equivalent to a 3-month summer job
and you should treat it as such. A few words every 10 days-ish is *not*
optional.
Others: I got the impression that the current java binding is unmaintained
and unmaintainable - please correct me if I am wrong. That said, there are
possibly lessons to be learned from what not to do, so I think it would
be useful to open the floor for discussion about the current status
of the java binding, what is good about it, what are the tools/functionalities
available, and what are the unfixable problems, etc.
I also got the impression that some assume a re-write (or an alternative
implementation) would be better. My sentiments are probably summarised in
somebody else's writing (http://www.jwz.org/doc/cadt.html); or that something
adopted
in GSoC would automatically get done, and get done well by a lot of
experienced people. Neither are the cases.
Realistically, we should get 3-months x 2 of work from two smart students,
by the end of the summer, that would be 2 additional language bindings; how much
that would engage contributions from the non-students, or other parties,
we'll have to see. The best case scenario would be some useable work
to base further work on by the end of the summer. It is unlikely
to replace existing work/usage wholesale after 6-student-man-months, however.
Based on past experience, it is unrealistic to expect the student to
continue much beyond the summer - school work, or getting a real job, etc
tend to come in. I have had one student who stated such honestly
('cannot see himself spending much time beyond'), and came back
about 5 years later asking for another GSoC job - some countries have
very long student lives - but that's rare. So 3-month is 3-month,
please don't wishful-think that it will be a life-long dedicated commitment. It
isn't.
Also, the failure rate of GSoC is about 10-15% overall, and quite
similiar in the linux foundation unbrella. About 1 in about 8 projects
does not pass mid-way evaluation, or the final evaluation.
Sometimes it is just no show, student disappearing after
the first payment, sometimes it is just excuses after excuses,
or a lot of grand planning/design mission statements, without
a single line of code to show; sometimes it is getting bog
down to other things - e.g. a fictious scenario where the
student spending a few weeks playing with git server
configurations not essential to the work and/or could be
solved in a few hours just by asking the right
person/mailing-list, etc. To be honest, there are probably
far more unsatisfactory projects than that 10-15%,
mostly because mentors are reluctant to stop a free
student from possibly contributing, even if all the signs
are not good. So we may not necessarily have 2 useable new
bindings by the end of the summer.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech
RE: [GSOC] Make the Go library go get-able
Hmm, maybe my message wasn't clear enough. (1) An empty file called git-daemon-export-ok needs to be created if you want a directory to be exported by the git daemon, (2) anything downloadable (http/ftp/rsyc/scp) is usually git clone'able. git clone even operates over local directories; there are no additional configuration for these. I think there were some confusion about what 'go get' does. it probably does not involve git. On Sun, 8/6/14, Gary O'Neall g...@sourceauditor.com wrote: Subject: RE: [GSOC] Make the Go library go get-able To: ht...@users.sourceforge.net, 'Vlad Velici' vlad.vel...@gmail.com, spdx-tech@lists.spdx.org, 'Jack''Manbeck' j-manbe...@ti.com Date: Sunday, 8 June, 2014, 20:57 Just to clarify - I only have access to the gitolite config file to configure git access. I do not have access to the server itself. I do admit I am not a git expert, so any advice or pointers is appreciated. If there is a configuration option to solve Vlad's problem, please be specific on the configuration changes. If there is something that Vlad can do in accessing the repository differently, please be specific on what steps can be taken. Thanks, Gary -Original Message- From: Hin-Tak Leung [mailto:ht...@users.sourceforge.net] Sent: Sunday, June 8, 2014 12:49 PM To: 'Vlad Velici'; spdx-tech@lists.spdx.org; Jack''Manbeck; Gary O'Neall Subject: RE: [GSOC] Make the Go library go get-able On Sun, 8/6/14, Gary O'Neall g...@sourceauditor.com wrote: I was not able to find an easy way to make the git repo cloneable without the .git. We are using gitolite to configure the repositories, so if there are any git experts on the mailing list with a solution, pls. let me know. That sounds rubbish. Although git has its own protocol (git://, over port 9418), it can operate over ftp, http, rsync, etc and a dozen of other network protocols also also. A non-exhaustive list is at the bottom of man git-clone. Though, it is not often documented that a directory needs to have an empty file git-daemon-export-ok to be acted on by the git server daemon. Please just read up on that. ___ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
Re: current status of the java binding, and GSoC
On Sun, Jun 8, 2014 at 11:46 PM, Hin-Tak Leung ht...@users.sourceforge.net wrote: Ahmed: I think I already explained that you must write a few words every 10 days or so during the GSoC period on progress. You can plan your own work and how you want to spend your time on a day-to-day basis and the approach you take; but GSoC is supposed to be equivalent to a 3-month summer job and you should treat it as such. A few words every 10 days-ish is *not* optional. I apologize for not sending updates, I will do my best to keep regular updates. I am currently working on the tag/value parser. I am using PLY https://pypi.python.org/pypi/ply/3.1 to implement the lexer and parser. The lexer is pretty much complete at this point, I am still testing it. Hopefully I will be testing the parser by this time tomorrow. I could really benefit from some sample SPDX files. I am currently using the ones from https://github.com/goneall/SPDX-Tools/tree/master/Examples and https://github.com/triplecheck/reporter/tree/master/run/reports -- Best Regards, Ahmed ___ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
Re: current status of the java binding, and GSoC
On Sun, Jun 8, 2014 at 10:46 PM, Hin-Tak Leung
ht...@users.sourceforge.net wrote:
Others: I got the impression that the current java binding is unmaintained
and unmaintainable - please correct me if I am wrong.
Which facts are the base of this rather harsh impression?
I am rather puzzled by this comment (that you happen to have mixed
with some unrelated student feedback) and your other comments below.
That said, there are
possibly lessons to be learned from what not to do, so I think it would
be useful to open the floor for discussion about the current status
of the java binding, what is good about it, what are the tools/functionalities
available, and what are the unfixable problems, etc.
Again, which facts do you base these comments on?
For one thing did you actually install and used this java library?
What issues did you encounter if any?
Did you happen to report them on this list or as bugs?
I also got the impression that some assume a re-write (or an alternative
implementation) would be better. My sentiments are probably summarised in
somebody else's writing (http://www.jwz.org/doc/cadt.html); or that
something adopted
in GSoC would automatically get done, and get done well by a lot of
experienced people. Neither are the cases.
What is your impression based on? What are you trying to say exactly?
Realistically, we should get 3-months x 2 of work from two smart students,
by the end of the summer, that would be 2 additional language bindings; how
much
that would engage contributions from the non-students, or other parties,
we'll have to see. The best case scenario would be some useable work
to base further work on by the end of the summer. It is unlikely
to replace existing work/usage wholesale after 6-student-man-months, however.
Yes, so what?
Based on past experience, it is unrealistic to expect the student to
continue much beyond the summer - school work, or getting a real job, etc
tend to come in. I have had one student who stated such honestly
('cannot see himself spending much time beyond'), and came back
about 5 years later asking for another GSoC job - some countries have
very long student lives - but that's rare. So 3-month is 3-month,
please don't wishful-think that it will be a life-long dedicated commitment.
It isn't.
Again, so what? has anybody expressed any such wishful-think here ?
Also, the failure rate of GSoC is about 10-15% overall, and quite
similiar in the linux foundation unbrella. About 1 in about 8 projects
does not pass mid-way evaluation, or the final evaluation.
Sometimes it is just no show, student disappearing after
the first payment, sometimes it is just excuses after excuses,
or a lot of grand planning/design mission statements, without
a single line of code to show; sometimes it is getting bog
down to other things - e.g. a fictious scenario where the
student spending a few weeks playing with git server
configurations not essential to the work and/or could be
solved in a few hours just by asking the right
person/mailing-list, etc. To be honest, there are probably
far more unsatisfactory projects than that 10-15%,
mostly because mentors are reluctant to stop a free
student from possibly contributing, even if all the signs
are not good. So we may not necessarily have 2 useable new
bindings by the end of the summer.
Do we have any sign of such issues *here* and not in general? Not that
I know of.
I am rather puzzled by the purpose -if any- of your comments and your
lack of enthusiasm.
I am a long time GSOC veteran mentor and my multiple experiences
seem quite different from your negative ones.
--
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech
Re: [GSOC] Make the Go library go get-able
On 8 Jun 2014, at 10:04 pm, Hin-Tak Leung ht...@users.sourceforge.net wrote: Hmm, maybe my message wasn't clear enough. (1) An empty file called git-daemon-export-ok needs to be created if you want a directory to be exported by the git daemon, (2) anything downloadable (http/ftp/rsyc/scp) is usually git clone'able. git clone even operates over local directories; there are no additional configuration for these. I think there were some confusion about what 'go get' does. it probably does not involve git. “go get path.git” tries to clone a repository located at the given path (without the “.git” ending) by doing the following, I think in this order: - git clone git://path - git clone http://path - git clone https://path The problem I brought up is caused by the removal of the “.git” suffix from the argument of “go get”. It can be solved by either: 1. Make the repository available at http://git.spdx.org/spdx-tools-go (without the .git ending) 2. Use another feature of go get and add a meta tag to spdx.org (and /spdx, /tag, /rdf) which directs the go get command to the correct repository. From my command line: $ git clone http://git.spdx.org/spdx-tools-go Cloning into 'spdx-tools-go'... fatal: repository 'http://git.spdx.org/spdx-tools-go/' not found $ git clone http://git.spdx.org/spdx-tools-go.git Cloning into 'spdx-tools-go'... remote: Counting objects: 140, done. remote: Compressing objects: 100% (136/136), done. remote: Total 140 (delta 71), reused 0 (delta 0) Receiving objects: 100% (140/140), 33.68 KiB | 0 bytes/s, done. Resolving deltas: 100% (71/71), done. Checking connectivity... done. On Sun, 8/6/14, Gary O'Neall g...@sourceauditor.com wrote: Subject: RE: [GSOC] Make the Go library go get-able To: ht...@users.sourceforge.net, 'Vlad Velici' vlad.vel...@gmail.com, spdx-tech@lists.spdx.org, 'Jack''Manbeck' j-manbe...@ti.com Date: Sunday, 8 June, 2014, 20:57 Just to clarify - I only have access to the gitolite config file to configure git access. I do not have access to the server itself. I do admit I am not a git expert, so any advice or pointers is appreciated. If there is a configuration option to solve Vlad's problem, please be specific on the configuration changes. If there is something that Vlad can do in accessing the repository differently, please be specific on what steps can be taken. Thanks, Gary -Original Message- From: Hin-Tak Leung [mailto:ht...@users.sourceforge.net] Sent: Sunday, June 8, 2014 12:49 PM To: 'Vlad Velici'; spdx-tech@lists.spdx.org; Jack''Manbeck; Gary O'Neall Subject: RE: [GSOC] Make the Go library go get-able On Sun, 8/6/14, Gary O'Neall g...@sourceauditor.com wrote: I was not able to find an easy way to make the git repo cloneable without the .git. We are using gitolite to configure the repositories, so if there are any git experts on the mailing list with a solution, pls. let me know. That sounds rubbish. Although git has its own protocol (git://, over port 9418), it can operate over ftp, http, rsync, etc and a dozen of other network protocols also also. A non-exhaustive list is at the bottom of man git-clone. Though, it is not often documented that a directory needs to have an empty file git-daemon-export-ok to be acted on by the git server daemon. Please just read up on that. ___ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
RE: current status of the java binding, and GSoC
-Original Message- From: spdx-tech-boun...@lists.spdx.org [mailto:spdx-tech- boun...@lists.spdx.org] On Behalf Of Hin-Tak Leung Sent: Sunday, June 8, 2014 1:46 PM To: ahi Cc: spdx-tech@lists.spdx.org; Nuno Brito; Philippe Ombredanne Subject: current status of the java binding, and GSoC ... Others: I got the impression that the current java binding is unmaintained and unmaintainable - please correct me if I am wrong. That said, there are possibly lessons to be learned from what not to do, so I think it would be useful to open the floor for discussion about the current status of the java binding, what is good about it, what are the tools/functionalities available, and what are the unfixable problems, etc. The Java code spdx-tools at git.spdx.org is being maintained. The last checkin was 6 weeks ago. There are a couple active projects including updating the code to the SPDX 2.0 specification. It is in use in 3 commercial products which I am aware of and the tools have been downloaded and used by several end users. I am not aware of any unfixable problems. We welcome any feedback on the code as well as any contributions which improve the codebase. We are actively looking for someone to maintain the tag/value parser code. If there is interest in that area, please speak up. From my own perspective, there are several parts of the code I'd like to refactor - some of the suffers from changes in the spec since the code was originally written. Much of the improvement ideas are documented in the bugs database. As far as I know, the bug database is pretty up to date on issues found in the Java libraries. Like Philippe, I would like to understand where you got the impression that the code was not maintained or maintainable and if you have any constructive suggestions on how to improve the code base if you do see problems. Gary ___ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
