OpenPETRA Architecture Team: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
(Added Logging, Class naming, Directory structure)
Line 42: Line 42:
* [[Business Layer]]: No priority
* [[Business Layer]]: No priority
* [[GUI Generator: Simulator for Previewing of GUI (No Dev.Env. necessary?)]]: No priority
* [[GUI Generator: Simulator for Previewing of GUI (No Dev.Env. necessary?)]]: No priority
* Data base normalization - For example the name of an account is stored in several tables and furthermore is used to link table entries and to define table relations. So it is difficult to change the names.
* [[Data base normalization]] - For example the name of an account is stored in several tables and furthermore is used to link table entries and to define table relations. So it is difficult to change the names. Comment: Each dataset should have an internal id and should be linked by the internal id [[User:Thiasg|Thiasg]] 08:42, 24 January 2011 (UTC)
 
* [[Logging]] - Use a fast, configurable logging mechanism instead of TLogging
* [[Class naming]] - Should all classes start with "T"?
* [[Directory structure]] - The directory structure does not fit together with architecture. Difficult for new people to find, what they are allowed to use and where to find classes.


==Decisions Taken==
==Decisions Taken==

Revision as of 08:42, 24 January 2011

What is the Architecture Team?

A group of people within the openPETRA development team that looks at and improves architectural issues of various kinds.

Team Members

The openPETRA Architecture Team currently consists of christiank and MathiasG. They were nominated to that job by the the other openPETRA core developers at an openPETRA meeting in Carlisle (Nov.30th - Dec.2nd, 2010).

The members of the Architecture Team do not work full-time on architectural issues; rather they are 'normal' openPETRA developers who can be contacted about architectural issues and who are pro-actively looking for architectural issues as they go about their development work. They might work full-time on issues for a certain time as the need arises.


Purpose of the Architecture Team

The Architecture Team...

  • proactively identifies issues in the architecture or development process of openPETRA and highlights them to the development team.
  • investigates issues of the architecture or development process of openPETRA as identified by other development team members.

and...

  • comes up with proposals on how to improve identified issues.
  • implements changes to resolve or improve the identified issues themselves, or delegates the implementation of changes to another member of the development team, depending on whatever is seen as best and who/if somebody is available for that.
  • creates and maintains documentation on the topics of
    • openPETRA architecture
    • development process of openPETRA


Discussions

Current Discussions

The list below contains discussions on current topics.

These are discussions only and might result in one or the other decisions!

Proposals for Potential Topics for Further Discussions

The list below contains proposals for discussions on topics that we might want to look at. There is no particular order.

These are discussions only and might result in one or the other decisions!

  • Logging - Use a fast, configurable logging mechanism instead of TLogging
  • Class naming - Should all classes start with "T"?
  • Directory structure - The directory structure does not fit together with architecture. Difficult for new people to find, what they are allowed to use and where to find classes.

Decisions Taken

  • Other Source Code Versioning System than git: Moving to Bazaar after evaluation (Dec. 7th, 2010, architecture team meeting).
    • Move to a Bazaar Repository completed on Dec. 14th, 2010, after two days of intensive evaluation.


Meeting Notes