[Gt-eos] gtk source repo location

[Baptiste Grenier]

Le 20/10/17 à 13:57, Mischa Salle téléscripta :
>Hi Baptiste, others,

Hi,

>I think that whatever acronym we use, there probably is already a
>library with that name around. It's mostly important to prevent clashes
>with similar tools I think. I was wondering whether the term gsi is
>perhaps a good option instead of globus? So gsi-toolkit? It's known, not
>copyrighted or trademarked as far as I know, and I think most of our use
>of the globus-toolkit that we need has somewhere todo with GSI.

I personally think that gsi and gsi-toolkit are nice names as gsi will 
indeed mean something for a lot of people. There is already a GSI 
organisation so for the organisation name part we need something else.

To see it "visually":

- globalgc/gsi-toolkit
- grid-community-forum/gsi-toolkit
- gridcf/gsi-toolkit
- gridcommunity/gsi-toolkit
- gridsc/gsi-toolkit
- gridsf/gsi-toolkit
- gsitoolkit/gsi-toolkit or gsi-toolkit/gsi-toolkit (too restricted?)
- opengt/gsi-toolkit

Not possible:
- gridtools/gsi-toolkit (in fact GridTools already exists)
- opengsi/gsi-toolkit could have been nice but opengsi is already taken

Organisation name + project name might also be important/interesting for 
SEO/ease of discovery.
Should it contain grid or not?

>There is by the way another important issue with not being able to use
>the word globus: it's in almost every library name in the toolkit. So if
>we want to/must remove it from there too, we need a rebuild of each
>globus-depending software product... It also could mean having all the
>products needing re-adoption into Fedora/EPEL and Debian.

Is it something that can be avoided?
As the "upstream" will change one could find appropriate to have 
different names/packages.
At a package level usage of some provide/conflict instructions in the 
spec/debian control files could help a bit to ease the transition.
In theory having to rebuild all the products depending on the toolkit 
could be acceptable as it is quite a big/important change, but yes it 
would require more work from the product teams and it would take some 
time to get everything updated. It would also somewhat force them to 
acknowledge/validate the change.

Once the building scripts/files/infra will be working it shouldn't be 
that hard to get the packages accepted in debian and EPEL. We could also 
find a temporary solution to publish dedicated repositories (and/or to 
provide early access to the packages).

> Best wishes,
> Mischa

Best regards,
Baptiste


>On Fri, Oct 20, 2017 at 01:10:49PM +0200, Baptiste Grenier wrote:
>> Hi all,

>> I answered the poll, and added some custom propositions, if possible I find
>> appreciable to not have an acronym that would perhaps look cryptic:
>> - for the organisation: gridtools or gridcommunity (we could try to add  a
>> dash in the name as it makes it look nicer, but it might cause  problems
>> with some github-related tools that are a bit buggy)
>> - for the project: open-grid-toolkit or maybe opengt if we want to hide  the
>> grid word as pointed out by Mischa.

>> The fact is that grid is also present in most of the propositions for the
>> organisation name...

>> Best,
>> Baptiste

>> --
>> Baptiste Grenier
>> EGI Foundation - Operations Officer
>> Phone:              +31 627 860 852
>> Skype:         baptiste.grenier.egi



>> _______________________________________________
>> Gt-eos mailing list
>> Gt-eos at mailman.egi.eu
>> http://mailman.egi.eu/mailman/listinfo/gt-eos
-- 
Baptiste Grenier
EGI Foundation - Operations Officer
Phone:              +31 627 860 852
Skype:         baptiste.grenier.egi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1867 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/gt-eos/attachments/20171020/0794cb5a/attachment-0001.p7s>