On Thu, Jul 2, 2015 at 12:09 PM, Neil M <[email protected]> wrote: > > > On 2015-07-02 11:33, Anthony Bryan wrote: >> >> On Thu, Jul 2, 2015 at 11:02 AM, Neil M <[email protected]> wrote: >>> >>> >>> >>> On 2015-07-01 23:46, Anthony Bryan wrote: >>>> >>>> >>>> On Wed, Jul 1, 2015 at 6:53 PM, Neil M. <[email protected]> wrote: >>>>> >>>>> >>>>> I don't have a github account. I've generally steered clear of git due >>>>> to >>>>> ugly Windows support compared to subversion. But it looks like github >>>>> has >>>>> branched out to support subversion now too and that is still how we >>>>> access >>>> >>>> >>>> >>>> I'm not sure? I assumed the others were just imported. but maybe? >>>> perhaps the Windows support is better now too >>>> >>>>> it? That sounds fine to me. I've been migrating some of my other >>>>> things >>>>> away from sourceforge, in particular the downloads due to the installer >>>>> tricks they have been pulling. And I can add metalinks that way too. >>>>> :-) >>>> >>>> >>>> >>>> yeh, nasty tricks! >>>> >>>>> A few other things: >>>>> >>>>> 1) Do we have a way to distribute binaries? It looks like github can >>>>> do >>>>> this, I guess I just haven't seen it. I don't know if this is one of >>>>> the >>>>> pay-for upgrades or we have a quota limit or what. >>>> >>>> >>>> >>>> yes, gh can do binaries. I'm not sure if TT pays for it, but >>>> libmetalink has them >>>> >>>> https://github.com/metalink-dev/libmetalink/releases >>>> >>>>> 2) One of the issues with github is that there is a lot of code just >>>>> thrown >>>>> up there without license information. With SF you could set a general >>>>> license in the project page. I think we are OK with our stuff but need >>>>> to >>>>> keep that in mind if merging other projects in and adding new stuff. >>>> >>>> >>>> >>>> it might be good to explicitly sort out the licensing anyways? >>> >>> >>> >>> I think we are pretty good on having markings in the code files >>> themselves >>> and full licenses in the directories. What we should probably have is a >>> page describing how new contributions should be handled. For example you >>> should use a OSI approved license, include that in code headers, etc. We >>> could make specific license recommendations like LGPL for libraries, GPL >>> for >>> software, just as an example, but I don't think we have to. >> >> >> we could have a README.rst which seems to be displayed beyond the code >> like how libmetalink does it >> https://github.com/metalink-dev/libmetalink >> >> does it make sense to have all the separate directories be different >> repositories under https://github.com/metalink-dev or keep them the >> way they are? > > > Yeah I guess while we are moving things around that makes a lot of sense to > split them up. We can keep issues separate that way too.
separate issues & downloads/binaries too, altho checking at SF, it looks like only Metalink checker, command line, & Editor really had releases. I dunno what makes the other directories/smaller projects more visible/discoverable, all being in one repo or having separate ones? or maybe have the major ones & another misc/extra-tools for the other things that aren't touched much? -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads -- You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/metalink-discussion. For more options, visit https://groups.google.com/d/optout.
