[This followup was posted to gmane.comp.db.sapdb.general and a copy was sent to the cited author.]
Seems nobdy wants to comment on this one first. OK, so I've been known to be foolish before, let me try: > during the last days we had a discussion on the SAP DB mailing list about SAP's >intention with SAP DB and Open Source. Our position is as follows: It is very much appreciate that you take time to follow the discussion of the SAP DB user community. It is even more appreciated that you are willing to state your intentions. > * SAP DB is an Open Source Project because we offer sources and development >environment to work on product and platform enhancements. Well, when CVS starts working, maybe we can call it a start of the development environment. I currently see only mailing list. While help the members of SAP junta are providing is very much appreciated, and essential for success of community development process, and therefore constitute component of the development environment, it is not enough. We need a CVS. Then, we need a bug/task/feature request tracker/management application. > o We will check all incoming patch proposals and will integrate >them as far as they do not endanger the stability and compatibility of the system. We >will do this as fast as possible in terms of our SAP quality assurance process (see >one-system policy below) We need a way to contribute (get our changes to SAP managed CVS) in orderly and predictable fashion. Hopefully, proposed OpenSAPDB project will partially resolve that on our side, if you can please publish a document that would describe rules of this game: in short, what to do to get our changes accepted by you. So far only one rule is known, as you state above. What else? Why not institute formal Request For Comment (RFC) mechanism: developers who want to get there changes in code, first publish a RFC. RFC is announced, and opinions collected from both the community and SAP junta. Then, SAP AG officially accepts or declines RFC, within a preset period of time (say, one month from RFC announcement). When task is approved in principal, developers do the coding, testing, and submit a patch to SAP AG. If the code is of acceptable quality, developers can rest assured patch will be accepted, since at this point only ground for refusal are that RFC is not implemented as proposed. And what is the _procedure_ ? Who to ask, and what needs to be provided, and in what form? Also, it would help us a lot if we would know what SAP developers are working on, and on what schedule - we really don't want to dupicate the effort, and it is really good to know which parts of the code we better stay out for some period of time. Avoids frustration. This can also be done trough bug/task/feature request tracker/management application. > > o The community should feel encouraged to manage own >implementation projects and we offer to be involved into discussions around these >projects. This would help to assist those projects so that they can be more easily >integrated back into the official version. Appreciated. Do we have an official permissionn to use name "OpenSAPDB" ? Maybe it would be good to set up a mailing list for this interfacing, on sapdb.org, where developers from OpenSAPDB project and SAP junta would be subscribed? > o We are permanently working on improving the access paths to >and from the database code - during the next days a CVS server will become active. Fantastic! Thanks! > o The 'vmake' environment offers a very comfortable chance to >keep and maintain own versions of SAP DB. A valid reason to keep vmake. It requires a steeper learning path, but it pays off, at least in this respect. > > * SAP DB is a ready-to-run Open Source Product because we provide the binaries >for various platform. > > o Those binaries have passed the complete quality assurance for >SAP software products because they are the same that run with SAP's applications. >There exists no separate (licensed) database product for that purpose! > > o This 'one-system'- policy requires a very careful process in >taking over patch proposals and thus we will keep the final control for the SAP DB >code. Somebody has to, and I guess you guys have a lot of experience in doing this. Again, thanks J�rg for this post. Should one assume you are official contact for interfacing with SAP AG on issues of OpenSource development? Kind regards, -- Yours, Andrej Falout, http://www.falout.com/disclaimer.html Visit the OpenSource alternative, Aubit 4gl: http://aubit4gl.sourceforge.net PLEASE NOTE: All HTML email sent to me WILL BE DELETED AUTOMATICALLY WITHOUT READING. _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
