Board.KolibriOS.org

CleverMouse
It is not a problem to share an FTP folder - just ask Mike.dld to create one, and share its password with a person you trust.
However, it will give no guarantee against accidental damage, indeed.

Why can't we split our efforts and distribute the binaries management between the active developers who is familiar with the sources?

With such an approach,

1) all the responsible persons shall monitor their projects,
2) test the latest versions and
3) present the binaries at his/her FTP.
4) The nightbuild/distro builder makes the final assembly that binds all the application into the single image.

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh, this looks like resolving one problem in method with many problems instead of using another method. I pointed to other disadvantages of FTP. Moreover, I consider not only binaries, but also configs including a list of programs in the night build. I personally do not want to take responsibility for maintaining this list. I think that the decentralized scheme when every developer can directly modify such configs without contacting and convincing a maintainer is better for our project - or, at least, more robust, given the history.

_________________
Сделаем мир лучше!

Another problem we need to address is that almost everything can be compiled in russian or english, they should be consistent..
There are also a lot of programs wich are not on the floppy distribution.

It is not so easy as it first seemed to me indeed..

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

That's why I put forward the idea of "distributed personal responsibility" - every program has its own Publisher (the expert who is familiar with the code, its recent modifications, libraries/dependencies, texts/controls etc.) and shall be stored/managed separately and included to the next nightbuild jointly.

art_zh, "included to the next nightbuild" - included by whom?

by the night-builder, surely

an option: by the one who's on duty tonight

art_zh, the existence of dedicated "night-builder" means centralized variant, which, as the history shows, sometimes breaks - it seems that currently there are no good candidates for this post. The same applies to the dedicated "Publisher" - what if he is ill or has abandoned the project? The second option is the choice that I defend, and it requires that many persons have the write access to configs - and if this is implemented for night-build configs, why we need another scheme for binaries?

_________________
Сделаем мир лучше!

Because the joint access (= equal responsibility) is only one side of the bigger problem.


One needs to be very familiar with particular souces/codes/data to monitor all the changes related and keep the binaries up-to-date.

One person cannot be an expert in everything, that's why it might make sence to subdivide the work to several sectors, and ask every active developer to manage his/her sector solely (= distributed personal responsibility). If he/she is ill, too busy or whatever unable to manage his/her part of work, than we all can re-distribute the load eventually.


In the way I've proposed, the Night-Builder will not play such an important and critical role as he did before.
Ideally, even a robot can do it if all the binaries are managed properly.
In a real world we all could carry this duty in monthly shifts/rotations (worst option: elections).

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh, the joint access does not imply the equal responsibility. Any developer can commit to any place of svn://kolibrios.org, but there are individual developers who are responsible for some parts of the repository.

Probably I formulated what I want not enough clear. For now, we have a stable working technical base - svn repository - for managing source codes, but no technical base at all for managing binaries and build scripts - in this topic "build script" means "script for building final working image", not something like build_all.bat. Given technical base which is flexible enough, one can further discuss or make a model of development, but every model has to be based on something technical, and here I want to construct the technical base.
FTP as underlying technology seems to force centralized model, which has some disadvantages - in fact, just now it is broken. Also FTP has technical disadvantages, I wrote about them. Another svn repository and another folder in the current repository as underlying technology have not these restrictions; yes, based on them, one can construct a chaotic development model when everyone does everything and no one is responsible, but this certainly isn't an unique model - centralized model also can be built on this base. I do not want to discuss a development model - if you want to hear my opinion, I agree with you that distributed personal responsibility is good - but I want a working technical base.

Seems that the final solution will be selected by mike.dld, and seems that he already started to celebrate the new year because he says nothing here.

_________________
Сделаем мир лучше!

Every svn-account holder can make any change he wants being 100%-responsible for everything he does. That is what I call "equal responsibility". If Mike creates a joint FTP-account, the result will be the same: anarchy and irresponsibility.

Maestro diamond (shine on him!) was a very good expert in many applications and the only Night Builder for quite a long time. He managed all the builds by his own keeping all the intermediate workcodes somewhere out of the main svn-repository, and collecting all thanks and blames after. That was a sort of "personal responsibility" indeed.

None of us is able to do the work as good as diamond did, nor wants to do it by a similar manner. But we can cook our smaller pies of the cake as I said before (see "distributed personal responsibility").

Note that every such a pie may be presented in one's personal FTP (and mirrored somewhere else!) and bound later to a nightbuild by a robot or a Night_Builder-on-duty.

SVN is not a good place of doing the work, i.m.h.o.
It is for development only, not for publishing!
Also, we don't need most of SVN features to keep binaries up-to-date.

What we really need is a personal manager for each program.

CleverMouse, art_zh
I'm not that active in a project lately as you might have noticed. That's why I don't think I have any need or rights to answer here, since you may decide such things without me. Moreover, I never felt like project leader or something, so it's up to you guys to make a plan and tell what you want me to do to make you happy.

As for my point of view regarding nightly builds integration process, separate directory inside the same repo would be fine. Those who don't want to check it out could just play with svn --depth flag. For the convenience I'd make some kind of description file for each program/library we need to build (not a makefile or build.bat but something like rpm spec file, deb control file or ebuild; yeah, with meta info on project name, version, author etc.). And use one of common cross-platform scripting languages (Ruby, Python, Perl, PHP) to analyze 'em and build the whole stuff.

And yes, kolibrios.org is running on Linux.

_________________
in code we trust

So... what's it going to be guys?

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

I don't expect any serious discussion before the Old New Year (14th of January)

http://en.wikipedia.org/wiki/Julian_cal ... odox_usage

Right, I should have remembered that from the years before

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

art_zh, you still did not give any arguments why we should use FTP - with all disadvantages listed in viewtopic.php?p=30928#p30928 - instead of SVN. I cannot count words "we don't need most of SVN features to keep binaries up-to-date" as an argument, and "i.m.h.o." is definitely not one. If you insist that the scheme "only one person can change any given file" must be technically enforced - well, this is easy implementable via SVN pre-commit hook rejecting all authors except one, and a hook is more flexible allowing e.g. two coauthors and still rejecting all others.