The name of GitHub repository

[Ivan Denisov]

In general, a VCS (version control system) is intended to be used for maintaining the sources of a project,
not the downloadable executable or zip file. In the case of BlackBox this includes the module sources,
the resources and the documentation files. The object files, symbol files, and and exe file
are not to be kept under version control. This would blow up the repository and introduce a lot
of changed files whenever you recompile.

The VCS strategy with binaries is also worthwhile in BlackBox case. SVN can blow up repository, Git can do this with much less probability. It works very fine with binaries. We can vote, what to load into the repository. I am sure, that we need to load full BlackBox there, because there are no well side compiler to compile this sources and ~34 mb is not big problem for modern PC.

A download page must be maintained (in addition to the Git repository) as it has been done before
by ominc or CPC. The download page should also have a history of older downloads and
a description of changes for every new version. This is what the regular user of BlackBox sees.

The regular download page exists and should evolved soon: http://blackboxframework.org/

[Josef Templ]

This is a big mistake and it is probably the most common mistake beginners make
when switching to a VCS. It makes everything much more complicated, not only bigger.
When you look for example at the changes introduced by a single COMMIT you get a list of
files that were affected by that commit. This list should only contain the source code changes,
which in our case also includes the resources and the documentation.
It should not list the compiled output resulting from these changes. It will also produce
merge conflicts, etc.
So one of the first lessons I learned when switching to a VCS was that you should never
mix up source code management with distribution. This is also the standard
recommendation you find in any document regarding the usage of a VCS.
The point that Git is fine with binaries is an advantage for us because we need it for the source code,
the resources, and the documentation files, but not for the object and symbol files.

There is no need to download a running BlackBox from the repository.
A running BlackBox with sources from the repository can easily be set up by applying
the /use command line option when starting BlackBox.

- Josef

[Ivan Denisov]

Josef, so to compile the whole BlackBox from sources we need to make some build file and make small instruction how to use the repository. I agree that it is possible alternative. Lets ask other members, and decide by the voting.

1. Only sources.
+ Small repository.
- More difficult to deploy development process. You need to download last stable release, use some technique for run one BlackBox over the sources.
+ Always recompiling checking the full ability to compile.

2. Full BlackBox
+ Easy deploy of development process
- Bigger repository

[cfbsoftware]

You need to download last stable release, use some technique for run one BlackBox over the sources.

I would see this as being essential anyway. This is somewhat different to other source code projects in that the tool being developed is actually the development tool. I certainly wouldn't want to download the binaries of an experimental version of the compiler which had been compiled by itself. Only when all the bugs had been ironed out and a full regression test performed would I want a new stable binary distribution.

[Josef Templ]

Josef, so to compile the whole BlackBox from sources we need to make some build file and make small instruction how to use the repository. I agree that it is possible alternative. Lets ask other members, and decide by the voting.

Normally you employ a build machine for that purpose.
(You can do it also manually as long as we don't have a build machine set up.)
This is the standard way how software development works nowadays, in particular for
open source projects but also for closed source projects that are of a relevant size
and that involve a distributed development team or a continuous build process.

- put the sources in a VCS such as Git.
- take the source changes and perform a build, e.g. nightly build or whatever policy you like
- optionally, perform some regression tests
- create a distribution package
- make the distribution package available on a download server

A standard build machine is Jenkins, for example.
It can be configured to connect to a Git repository and get the changes.
It can be configured to run a command-line tool for the build step.
It can be configured to run regression tests.
It can be configured to run a command-line tool for the packaging, etc.
It produces build logs, test reports, and statistics.

The Jenkins server would be on our Edis host.
There may be alternatives to Jenkins, but with Jenkins I know that it works
and it is used by many projects. I have used Jenkins under Windows but it is
a Java tool that runs also under Linux.

While it requires some initial setup steps it makes the development and
distribution much easier for the future. It also keeps normal users away from the
repository. Even the most recent changes can be made available from the download page
without any repeated manual work.

So what you get, and I think what all of us want to get even if some are not aware of that,
is a continuous build process very much in the style of apache or other mainstream projects.

- Josef

[Ivan Denisov]

To use Jenkins is great idea. Will you install and set up it or that should be done by me? Should we vote for this or that automatically goes with using of Git?

[Josef Templ]

Unless there are any strong objections from other members, in order to move
things forward I would suggest to install Jenkins on our Edis host and set it up
and see if it works and what kind of detail problems arise.
(Ivan, you are the right person for doing that. Please keep a log about the
installation steps, accounts, passwords, etc.)
There are certainly some details that need to be figured out.
We also need to install Wine for running BlackBox under Linux
and wee need to get the CP compiler running as a command line tool or at least
behave like one. This is the technical challenge, the rest is configuration.

Then there should be a vote about using it.
I mean, if there are technical problems, it gives no sense to vote about using it
and only after we have installed and tested it we can be sure that it works and
that it gives sense to vote about it.

In any case, the decision to use a particular build machine should be
easily correctable if later on there arise more severe problems.
It is an internal tool not seen by the normal users and in no way
influences the contents, i.e. the source code changes agreed on by the center.

- Josef

[ReneK]

It seems, we really are not ready to decide the repository question right now. We need to get a better feeling for this, and no, Ivan, there#s probably nothing you can do now.

(IMHO, if we had a decent repository client in BB, most of our problems with usage would go away. And writing a client is by far easier than writing a whole repository server from scratch)

On the other hand, if we are not ready for this now, what are our options to continue (or start!) the work until we are ready?

I think the first need the BB Center version 0 up (rename the link on www.blackboxframework.org from "Blackbox Framework 1.6" to "Download current version" or something like that, and have everything in BBF renamed to "Center Version 0", plus an explanatory text in the BBF, how "Center Version 0"="Omi Version 1.6 final").

Then, as long as we do not have a repository, we can discuss the changes between "Center 0" and "Zinn 1.7", and incorporate them, where we agree. I do not think that for this process we need a repository, as long as there is a download.

"Center 1" should be "omi 1.6" + all changes from "Zinn 1.7" we want to use.

While the repository decision is important, it should not put a stop to all other work! So, while we try to make up our mind, we can still work on the "Center 1.0" version, IMHO!

[Ivan Denisov]

I am totally disagree with Rene position about repository. Because we did not have the tools we do nothing for one year. Now members voted and we have Center decision about GitHub, Redmine and 1.6 as start point. Now we can start working discussing changes. We have tools for discussion and fixations. Nobody will develop repository tool for BlackBox, because it is a time waste to do this, when there are a lot of free tools.

[DGDanforth]

Nobody will develop repository tool for BlackBox, because it is a time waste to do this, when there are a lot of free tools.

Actually I am in the process of doing that. Mostly for my own teaching (edification). It forces me to address the needed issues in source code control. I can also use the tool for keeping track of my own projects.

I suspect that the resulting tool (BBGit?) will be tiny compared to git. It will not have all the bells and whistles (features) of git but should be sufficient.

-Doug