Am 05.04.2014 08:09, schrieb Gustavo Niemeyer:
> On Sat, Apr 5, 2014 at 2:32 AM, Gustavo Niemeyer <gus...@niemeyer.net
>> The service assumes that a clean repository name has a matching
>> package name, and "libvirt-go" cannot be a package name. Using
>> "libvirt" for the repository would add the package name hint, for
> I suppose go-foo and foo-go are going to be common for namespacing
> well known names into a Go context, so these will be stripped out now,
> which makes libvirt-go offer the package name hint too.
That was actually the behavior I've expected, hence the confusion. :)
>> Well maybe you don't have to check the whole repository. gopkg already
>> uses a branch/tagging convention, so how about an additional rule, like
>> having a "gopkg" tag? Of course, there might be some downsides with
>> this approach.
> Yeah, that's an alternative to be considered, but it's probably best
> to keep it simple for now.
Coming to think about it, I like the idea of actively subscribing to gopkg
(using tags for example). First of all, you don't get hits for repositories
this way. This might reduce the level of
confusion caused by repos that just happen to use the gopkg versioning
Another advantage would be that you don't have to use a certain naming
scheme you propably don't even like. And since using a naming scheme
that involves the term "go" is already prone to result in much noise (since
"go" isn't very unique), one could further reduce the number of unrelated
And last, you would be able to decide whether to use gopkg or not. You're
not just part of a service you might not even know about. Of course one
could argue that if you don't even know about it, you probably don't care.