Hi jkl, Am 09.10.2018 um 21:16 schrieb James K. Lowden: > On Sun, 7 Oct 2018 21:45:59 +0200 > Simon Sobisch <simonsobisch@xxxxxx> wrote: > >> Reasonable. I'm not 100% sure if this is up-to-date and would always >> go to its home in the GnuCOBOL contributions: >> >> https://sourceforge.net/p/open-cobol/contrib/HEAD/tree/trunk/esql/ > > Hey, Simon, that's an interesting URL. How do I get there from the > main SF page? If I go to > > https://sourceforge.net/projects/open-cobol/ > > and click the "code" button, I come to > > https://sourceforge.net/p/open-cobol/code/HEAD/tree/ > > with "branches" and "trunk". contrib would be "up a level" from there, > but I don't see any way to navigate to it. Don't click on "Code" on the main page top navigation but on "Contributions" (was up-front earlier, seems to be hidden below the ellipsis on the right now...). > (I think it would be better if "contrib" were part of the regular > source tree, just like libcob and cobc. There's no rule that > everything in a repository has to have one owner or one license.) There's no fixed rule for this but it is still reasonable :-) "code" has copyrights FSF and GPL/LGP while "contrib" has only "any free license". "contrib" contains code that also works with other COBOL dialects (samples/tuturials/tools). Most of it doesn't has a minimal dependency for GnuCOBOL version N. The main reasons to split both repositories were: * different rights (anyone with "code" access can write to "contrib", but not vice versa) * different steps to get rights ("code" has copyright assignment, "contrib" has "just present your contribution in the discussion boards") * backup / restore considerations, considerations to move "code" to a different hoster and/or VCS (most likely git @ gitlab; you may want to comment/vote on [1] ;-) > --jkl [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/45007 Simon