[Cuis] Once central repo for Cuis and Packages? Or just a central list?

[H. Hirzel]

On 12/30/12, Angel Java Lopez <ajlopez2000 at gmail.com> wrote:
> Hi people!
>
> Yes, you usually work on master (it could be called the "developer
> branch"), and when you are ready, tag it. Ummm.. you tag your local repo,
> and then push the tags to Github. AFAIK, you could move the tag to other
> commit, for example, if there are a minor fix in documentation or something
> alike.
>
> Having packages out of the central repo, is more agile.

+1




>
> Maybe a "solution at the middle": some "blessed" (easy to test, to load
> from core in central repo, many used, important for community, etc...)
> packages are at central repo, and the other packages are listed in a page

I think a 'scripts' and a doc subdirectory in the main repo are fine
at the moments.
I.e.
https://gist.github.com/4387924
should be moved to a directory there and maintained by the community
through pull requests.

People need to

a) find the loadable packages
b) know about their status
c) have a means to load them automatically (not through a GUI)

for example



"To install Cypress, assuming the package files are in 'cuis-cypress-master'
in a subdirectory of the working directory"

#(
 'cuis-cypress-master\Cypress-Definitions.pck'
 'cuis-cypress-master\Cypress-Structure.pck'
 'cuis-cypress-master\Cypress-Mocks.pck'
 'cuis-cypress-master\Cypress-Tests.pck'
)
   do:
    [ :fileName | CodeFileBrowser installPackage:
                      (FileStream concreteStream readOnlyFileNamed: fileName)
    ]


However preferably directly through web access to github without
having to download the pck files first.

--Hannes

> Angel "Java" Lopez
> @ajlopez
>
> On Sun, Dec 30, 2012 at 9:01 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>
>> Hi Angel,
>>
>> I really like the idea of having a single and consistent git commit of a
>> Cuis version and all the packages that work on it. It would make much
>> easier to go back to some date, and grab stuff that works well together.
>> One downside is a bit more work for repo admin. A bigger one is that it
>> makes things a slower for package maintainers. But the consistency might
>> outweigh them.
>>
>> Below, I extracted Angel's comments on this. Folks, please comment. Add
>> steps or ideas to complete or enhance Angel's suggestion. Or if you don't
>> like it, please say why. This is a rather important decision, and I'd
>> like
>> we to make a good choice.
>>
>> One quick question for Angel (I'm a beginner with github): Can we tag a
>> commit after it was done? That way, we could work together on Cuis and
>> Packages for several days (involving many commits) and only when we are
>> all
>> happy, we can tag the last one as "v4.1 with packages" or something like
>> that.
>>
>> Cheers,
>> Juan Vuletich
>>
>> Angel Java Lopez wrote:
>>
>>> ...
>>>
>>> But having the central repo with the package (not a link), has an
>>> advantage: central repo could have tags. So, the packages at tag
>>> "v0.1.0"
>>> are all compatible with that tag, and every improvement at tag "v0.2.0"
>>> should be committed to that tag. The "master" tag is the development
>>> tag.
>>>
>>> So, I could download the v0.2.0 with all the optional packages of that
>>> version, without struggling going to each package author repo, and
>>> trying
>>> to guess what package/tag is compatible with Cuis v0.2.0
>>>
>>> Cons: it put more responsability to central repo author(s).
>>>
>>>
>>>
>>>     2012/12/27 Angel Java Lopez <ajlopez2000 at gmail.com
>>>     <mailto:ajlopez2000 at gmail.com>**>
>>>
>>>         Until you have a package manager, first idea:
>>>
>>>         Use the cuis repo at GitHub.
>>>
>>>         Every contributor make a fork.
>>>         He/she add the code to his/her fork.
>>>         Make a pull request to central repo
>>>
>>>         Maybe, a guide to have folders per package/topic.
>>>         ...
>>>
>>>         Angel "MyLifeIsGitHub" Lopez ;-)
>>>         github:ajlopez
>>>
>>>
>>
>> ______________________________**_________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>
>