Re: [spdx-tech] spdx/tools-go

[Philippe Ombredanne]

Hi Will,

On Fri, Feb 23, 2018 at 1:09 PM, Will Norris via Spdx-tech
 wrote:
> SPDX Tech folks,
>
> I'm curious, does anyone know if the spdx/tools-go repo is being actively
> maintained or developed right now?  Just looking at the commit history, my
> guess is that it's not... it looks like it was originally written by Vlad
> Velici, but that he's no longer working on it?  So then I guess a better
> question is if anyone is really interested in it?  Do you know if anyone is
> actively using it?

It is not super active indeed. And I do not know who is using it.
Vlad made it as part of his GSoC project so it would be great to
further it (and it make even more sense that Google would benefit from
it)

> I'm investigating using it in some work we're doing here at Google (since
> all of our existing compliance tooling is already in Go), and so had two
> questions that related to the above:
>  1. If I send some changes, is there anyone around to merge them?  (Philippe
> looks to have merged the last couple of PRs)

I will review and merge these alright switftly. Though you could very
quickly become the maintainer/co-maintainer on this ;)

>  2. Who might I break if I made major changes?  That is, how important is
> backwards compatibility?  (I haven't looked at the code closely enough to
> know whether I would even propose any breaking changes, but curious to know
> from the outset who would be impacted)

We can tag the repo and break compatibility alright. I would not be
too worried there.
If anything that would make folks that use it and may be broken chime
in and participate.
I am not saying this in an evil way, of course, but in a positive way!

> Also, does anyone have a sense of how widely adopted the various versions of
> SPDX are?  For our initial purposes, we only care about 2.1, since that's
> what scancode-toolkit emits.  1.x and 2.x seem different enough that
> supporting both would be a bit of work, so I'd be tempted to drop 1.x
> support altogether.  (Again, provided that this wouldn't actually break any
> active users)

Dropping 1.x support would make 100% sense. I would not even
contemplate using and supporting 1.x at this stage.
And again that's what version control is used for. So no worries.

And as a side note: great to know that you can have some use for
scancode-toolkit

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] spdx/tools-go

[Kate Stewart]

Hi Will,

On Fri, Feb 23, 2018 at 3:09 PM, Will Norris via Spdx-tech <
spdx-tech@lists.spdx.org> wrote:

> SPDX Tech folks,
>
> I'm curious, does anyone know if the spdx/tools-go
>  repo is being actively maintained or
> developed right now?  Just looking at the commit history, my guess is that
> it's not... it looks like it was originally written by Vlad Velici, but
> that he's no longer working on it?
>
  So then I guess a better question is if anyone is really interested in
> it?  Do you know if anyone is actively using it?
>

Philippe's around and is active, as is Gary.   However I don't have a good
feel for who is using it right now,  perhaps Philippe can comment?


> I'm investigating using it in some work we're doing here at Google (since
> all of our existing compliance tooling is already in Go), and so had two
> questions that related to the above:
>  1. If I send some changes, is there anyone around to merge them?
> (Philippe looks to have merged the last couple of PRs)
>

Philippe's around.Gary's on vacation in China for the next couple of
weeks, but when he's back he can help with merges as well.


>  2. Who might I break if I made major changes?  That is, how important is
> backwards compatibility?  (I haven't looked at the code closely enough to
> know whether I would even propose any breaking changes, but curious to know
> from the outset who would be impacted)
>
> Also, does anyone have a sense of how widely adopted the various versions
> of SPDX are?
>

The Open Source based tools (FOSSology and ScanCode) are both generating
SPDX 2.1 these days.  Some commercial tools may only have 1.2, but they're
not using the go repository as far as I know.


> For our initial purposes, we only care about 2.1, since that's what
> scancode-toolkit emits.
>
1.x and 2.x seem different enough that supporting both would be a bit of
> work, so I'd be tempted to drop 1.x support altogether.  (Again, provided
> that this wouldn't actually break any active users)
>

Give the quiet nature of the repository,  I think that going ahead and
making the changes should be fine.
Agree that the focus should be on 2.x. It would be great to get this
updated and current with the 2.1 spec!

Thanks, Kate
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

[spdx-tech] spdx/tools-go

[Will Norris via Spdx-tech]

SPDX Tech folks,

I'm curious, does anyone know if the spdx/tools-go
 repo is being actively maintained or
developed right now?  Just looking at the commit history, my guess is that
it's not... it looks like it was originally written by Vlad Velici, but
that he's no longer working on it?  So then I guess a better question is if
anyone is really interested in it?  Do you know if anyone is actively using
it?

I'm investigating using it in some work we're doing here at Google (since
all of our existing compliance tooling is already in Go), and so had two
questions that related to the above:
 1. If I send some changes, is there anyone around to merge them?
(Philippe looks to have merged the last couple of PRs)
 2. Who might I break if I made major changes?  That is, how important is
backwards compatibility?  (I haven't looked at the code closely enough to
know whether I would even propose any breaking changes, but curious to know
from the outset who would be impacted)

Also, does anyone have a sense of how widely adopted the various versions
of SPDX are?  For our initial purposes, we only care about 2.1, since
that's what scancode-toolkit emits.  1.x and 2.x seem different enough that
supporting both would be a bit of work, so I'd be tempted to drop 1.x
support altogether.  (Again, provided that this wouldn't actually break any
active users)

Thanks,
Will
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech