Dear Rene and OberonComunity
This message includes a lot of criticism, but should not be considered as aggressive or anger. I agree with Rene that now is the stage of trial, maybe not because of the cultural difference but the age difference you looks at my "trial" as a final decision. For young is more interesting to trial work then trial talk, because that give a chance to learn more. Also, if nothing to do and show, there are nothing to discuss. I respect everybody for the professionalism and work you are doing. This is dialog you ask for and it will try to explain why I think we should take a look more on a technological part of Community Future Communication.
Certainly the expert work is important, but the "center" without hands and ideas will be a mouldering stump. If somebody take roles called by Rene it is not sufficiently to be the center. As Rene right mention, community should "accept the services and role". I think that the key word here is "services". Oberoncore provide the best service for forum and documentation of bugs. Applause! But the other sides not allowing them to be such "center" them will be touched bellow.
The next scenario suggested by Rene is simply "community", and agree with OberonCore that it is the most probable scenario. But do not agree that BlackBox Component Builder 2.0 should not see the light some time in the future. The community also can make decisions and maintain the versions.
The community of BlackBox can unite three things: 1. Style (minimalism, goes from the N.Wirth & A.Einstein slogan). 2. Technological goal (already wilted and does not bloom yet) 3. The platform (the place to solve your working problems).
The minimalism for work today possible but becoming dangerous and not every user of blackbox enjoy this. That is why the first role for community holding should play the platform. In includes development and distribution part. There was two centers for that stuff before: 1. the H. Zinn collection of components and 2. OberonCore collection. All other stuff was decentralized. As a user and developer I was not suttisfied from both. Their editorial systems makes me fill fear. Also the usage without bug tracking, users comment, ratings automated version control systems was not efficient and I am sure it had decelerated the improvement of components blocking dialog of developer and user.
Today for the development we need Issues tracking system and modern code version system friendly with Component Pascal.
Today for the distribution we need the same automated platform for components as Lunchpad for Ubuntu developers, for Apple Store for Apple developers, for PlayMarket for Android developers.
That two services can make community unite and grow. That is why as a patriot of Oberon language family I do that I do make this services works. All other is conversation "who will be the mouldering stump?". I do not want any "center" decide is my documentation written good or bad, or is my component good to distribute enough. Let the users decide, mark me, give a feedback. That is my idea. Make it modern BUT SIMPLE. Not Mailing list or words blowing forum BUT GIT+REDMINE+CHAT, not static web-sites BUT Kindly Automated Component Store. Not a conference once 4 years but weekly!!! Oberon Google Hangouts.
Technical and organization solutions for this challenges are not on a plate and need to be checked from existent and some are developed from the scratch. The Redmine was one of such check suggested on forum.obeoncore.ru for the development and this check I done and invite you to test it well.
Everything revolves. Robert C. had already gave a feedback of using "git clone" and the issue about zipped archive with BlackBox. Ilya Ermakov had already gave an solution how to fix this server slow start Issue. Oleg N. Cher and Roman Miro have been started pushing Bug Issues and fixing them. I have merged OberonCore, H.Zinn, Maliya, Louwe, M.Frei fixes to master branch. Peter Kushnir working on how to integrate odcTOutf8 converter to Mercurial for have choice between developing system. Helmut Zinn integrates all known fixes to maintain his experted version, we includes all of them in redmine for sure. Boris Rumshin and Eugeny Temirgaleev make great work on forum to make it more friendly for non Russian language users, and I am sure they will maintain new version of their assembly too.
We do know what are doing in Oberon Microsystems AG. Is there is a hope that our activity not make them change their opinion about FreeBSD license? :)
Regards Ivan
2013/8/21 Rene A. Krywult <rene.krywult{([at]})nowhere.xy
Great! I agree. Technical issues, both concerning hosting platform and future development need to wait until there is a "center".
I propose the basic functions I believe the "center" should have:
1) Publication of a stable version of BB Framework
This includes adaptions to future versions of the OS, bug gathering and fixing, testing, documentation, making sure that all changes are "by the book". This does not mean that only the "center" may provide bug fixes, but only the "center" decides, which bug fixes actually make it into the next stable version.
2) Planning and coordination of internationalization
3) Planning and coordination of ports to other OS/platforms
4) Web Marketing of BB
5) Communication between members of the "center"
6) Communication between the "center" and the BB community as a whole
7) Facilitating a central and international communication platform for the community
8) Assignment of Package names
10) Providing a centralized and unified repository of packages (this includes: making sure that those packages are in accordance with guidelines concerning documentation and programming guidelines)
Are we all agreed on these functions? Should any be dropped? Should any be added? After agreeing on the functions, we probably want to document this in a whitepaper.
I propose that after we are agreed on the functions, BB developers need to decide if they want to be part of the center or merely part of the community. And those who want to be "center" need to detail, what skills they have to futher those functions. After that, a charter (what is our vision, our mission, our methods, our rules) of the "center" (and a better name!) should be defined.
Since everybody who is currently BB community would be able to decide if he wants to be part of the "center" or rather simply stay "community", this would be a defacto vote - assuming that those who do not want to be "center" accept the services and role of the "center".
After this process, it would also be prudent to have Omi aid the "center" in making official that the "center" is now the elected successor. Thus, we would be both assigned by Omi AND elected by the community, giving us the best head start to be a joined community service.
Of course, this is just a starting basis for discussion, not a proposal or declaration. Feel free to add, discard or throw it away ;-).
Rene
Gesendet: Mittwoch, 21. August 2013 um 10:06 Uhr
Von: OberonCore <oberoncore{([at]})nowhere.xy
An: BLACKBOX{([at]})nowhere.xy
Betreff: Re: [BLACKBOX] Aw: Re: [BLACKBOX] [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support
Dear Rene,
We agree what "single center of responsibility for BB would have the right to create a version in the future that is not fully downward compatible to 1.6, if that would be necessary." and so on, if it is defined as mentioned above: "Such centre may be assigned as the successor of BlackBox Support Oberon microsystems AG by acknowledgment. Or shall be elected by Community."
But again, there is no point to discuss these technical details while the center is hypothetical.
Best regards,
OberonCore team.
19.08.2013, 00:25, "Rene A. Krywult" <rene.krywult{([at]})nowhere.xy
Dear OberonCore team,
OK, I do not know when you started reading the BB mailing list. But one of my first posts to this topic was about a single center of responsibility, and some on this list have shown their support for this idea. So, on your point 1 we seem to agree.
Concerning your second question, I guess this is a problem in translation only. If a framework is ported, it is, of course, not just a reuse of a name, but a real port. The idea, IMHO, would be that you take a package from BB-Win7 and then recompile it on BB-Linux and BB-Apple OS and BB-JVM without any changes necessary. Would downward compatibility to BB1.6-rc6 be maintained? Surely for HBBF1.7, but for HBBF2.0? Who knows! As you will well remember, BB1.6 is not downward compatible to BB1.2! Omi made the decision that the planned changes were more important than full downward compatibility, and it was well in Omi's rights to do so. Likewise, the Hypothetical single center of responsibility for BB would have the right to create a version in the future that is not fully downward compatible to 1.6, if that would be necessary.
I think it is great that you do a Russian documentation for 1.6, and you probably already have a Russian UI for 1.6. Obviously, a German version, an Italian or French version are not in your scope. The single center of responsibility needs to supervise this task for all languages we have team members for. Also, this could mean that CpcLanguage - or something like it! - becomes part of the HBBF, because without (something like) it, localization could not be easily done in one version.
So, basically I'm saying that the new BB development team needs to call the shots. We need that body, and we need it soon.
Rene
Gesendet: Sonntag, 18. August 2013 um 21:47 Uhr
Von: OberonCore <oberoncore{([at]})nowhere.xy
An: BLACKBOX{([at]})nowhere.xy
Betreff: Re: [BLACKBOX] Aw: [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support
Dear Rene,
> if I understand your official position correctly, you do not concern yourselves with
> *) internalization of the basic BB framework
> *) adaption of the basic BB framework to newer versions of Windows
> *) porting of the basic BB framework to other platforms, like Linux, Apple OS and JVM
> *) adaption of the basic BB framework to better fit the state of the art
> In short, OberonCore does not see a need for a unified and central BB Framework 1.7.
> Is this correct?
1) United centre of responsibility for "unified and central BB Framework" is a precondition. There is no point in discussion about "unified and central BB Framework" without it.
Such centre may be assigned as the successor of BlackBox Support Oberon microsystems AG by acknowledgment. Or shall be elected by Community.
2) We are open to any development and it's our main activity (for example: support of BlackBox Russian documentation for BB 1.6 (
http://oberoncore.ru/projects/bb-docu-ru); BB1.6-rc6 Linux Console (
http://oberoncore.ru/projects/bb16lin-console) <
http://oberoncore.ru/projects/bb16lin-console> ). Hypothetic "basic BB framework" (HBBBF) ported to newer Windows versions, Linux, Apple OS & so on
Is HBBBF compatible with standard BB? Or it inherit it's name only? Who can answer this question now?
There is the concrete public assembly OberonCore BlackBox assembly on the other side. It's based on BlackBox Component Builder 1.6-rc6 (for Windows (XP, 32bit,
)) for now. And it's main development rule is "Primum non nocere".
Best regards,
OberonCore team.
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Wed Aug 21 2013 - 14:26:59 UTC