Ooh, I'm against splitting up. I think that with the little amount of
change the project has, we should keep everything in one place to keep
it more lively.

What I was trying to talk about was making a TODO list. Like:
- Create release tags
- Add the SF releases to the release tag
- Move trac information into a new wiki structure on github
etc.

Maybe it's best to start a single github issue "the move from SF" and
add comments about what needs to be done there?

On Thu, Jul 2, 2015 at 7:13 PM, Anthony Bryan <[email protected]> wrote:
> 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.

-- 
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.

Reply via email to