[BLACKBOX] Aw: Re: [BLACKBOX] Re: [BLACKBOX] [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support

From: Rene A. Krywult <"Rene>
Date: Wed, 21 Aug 2013 10:33:36 +0200

----boundary-LibPST-iamunique-683337405_-_- Content-type: text/plain 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 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) ). 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 ----boundary-LibPST-iamunique-683337405_-_- Content-type: text/html
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.xyAn: BLACKBOX{([at]})nowhere.xyBetreff: 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
 
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)). 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 Received on Wed Aug 21 2013 - 10:33:36 UTC

This archive was generated by hypermail 2.3.0 : Thu Sep 26 2013 - 06:29:50 UTC