The name of GitHub repository

[Ivan Denisov]

9 of 11 members voted, most of members have opinion, and most from that part are for GitHub synced with our tuned Redmine. The first part is more easy and can be done fast. Who we ask to do this?

We need to register organization on GitHub. However "blackboxframework" is already busy.

What about https://github.com/blackboxfw ? Do you like it?

[DGDanforth]

9 of 11 members voted, most of members have opinion, and most from that part are for GitHub synced with our tuned Redmine. The first part is more easy and can be done fast. Who we ask to do this?

We need to register organization. However "blackboxframework" is already busy.

What about https://github.com/blackboxfw ? Do you like it?

How about
https://github.com/BlackBoxComponentPascal

[Ivan Denisov]

How about
https://github.com/BlackBoxComponentPascal

IMHO, it is a little bit too long.

The shortest can be:
https://github.com/bbfw

[cfbsoftware]

Isn't this premature? The decision to use GitHub needs to be confirmed yet. There were more abstentions than votes which indicates a lack of information / knowledge about what is involved and could mean it would not be generally usable by centre members.

Assuming however that it is we need to determine what *really" matters for a name before deciding what it should be. Too short / too long is totally subjective.

What is the minimum / maximum / optimum number of characters?

Why is that the optimum number of characters? Does the name have to be typed in regularly or would it just be linked from somewhere else? If it can be added as a browser favourite does it matter how long it is (without being ridiculous)

More relevant:

Should the name and any acronyms used be instantly recognisable? By existing BlackBox users? By the general public?

Does it need to be easily remembered / recalled?

etc. etc.

[Ivan Denisov]

More people vote than abstain!

I do not know how to help people who abstain. They need to read about repositories and try smth. The main reason for their decision is that they does not use version control systems for their work. That is not bad, however I am sure that we need repository for team work.

For been recognised I we can use: https://github.com/BlackBoxComponentBuilder ?

[DGDanforth]

I would like to see a detailed breakdown of what the minimum functionality needs to be.
What do we need?
Who provides that minimum?
What is necessary to actually program that system (GUI, line input, language)?
Who of us would be able to make changes given that system?
....
How are multiple changes by different people merged?
What constitutes a release?
How is that release decided?

I have just been reading the Git basics and have put together a Git/Docu/Introduction.odc file which is a cut down version of the beginning of that documentation. Now, if I knew how to attach the encoded version of that file to this message I would do it, but how?

[DGDanforth]

By the way. I am in the process of installing Git (for the second time) on my Windows machine
since it got almost all the way through and then failed when it could not interpret \Program Files\...
which I assume Linux can't handle because of the space in the directory name. So I am now
doing it again to C:\Dgd\Git and hope that works.

The size of the download after almost completion of installation was 500+ MB. That is NOT a small
system.

I bet we (as a community) could build an equivalent, far smaller, system using BlackBox without all the
bells and whistles.

-Doug

[DGDanforth]

Got git up and running.

Forget it! There is no way that I can use Git with all of its Unix mind set.
The git gui does not even have a 'new' setting for a new project and seems to
put one into the middle of the 'git master' project. That is NOT what I want
for a source code development system I would expect to start clean with no reference
to any other project for git code. I would expect to simply point to files that I wish to
include in a new project. That is, use the Windows selection technique for browsing
to a file. But since git is developed for Unix and the author of the gui version has minimized
its dependency on Window the browse aspect is missing from the gui. No way am I going to
enter long directory names and files manually.

This all seems wrong headed to me. Created by Unix hackers thinking this is the 'cats meow' (good).
The simple idea of a 'repository' that keeps one copy of each file belonging to a project with
pointers to that repository file for each revision seems like a good idea. But the implementation
of that simple idea is wanting, greatly.

Surely we can do better than this?

-Doug

[cfbsoftware]

But since git is developed for Unix and the author of the gui version has minimized
its dependency on Window the browse aspect is missing from the gui. No way am I going to
enter long directory names and files manually.

If what you say is true then I totally agree. Unix is a brilliant system - or at least that was what I thought in the 1980's! While it was fun all those years ago the world has now moved on. The more I can do with the mouse the better (as long as there is an escape for bulk operations). I have no desire to go back to the dark ages ...

We should consider whether BlackBox is primarily for use by engineers / scientists (which I believe is its niche) or for computer geeks who get their rewards from a challenging process than the usefulness of the end result. From what I see systems like GitHub are more suitable for the latter. I don't advocate implementing a source code control system in BlackBox but I believe that any tools that we promote should have similar operational look and feel - not just be a command-line tool with a little bit of window dressing.

[DGDanforth]

Helmut seems to operate just fine with his Dos and dif capabilities to produce his BB1.7
Why not adopt his technique (and generalize if necessary)?