Development

Development.Development History

Hide minor edits - Show changes to markup

May 14, 2013, at 01:00 PM by 109.99.235.212 -
Changed line 1 from:

Development -> Development

to:
Development -> Development
Restore
January 18, 2013, at 02:42 PM by bogdan -
Added line 22:
Restore
January 18, 2013, at 02:42 PM by bogdan -
Changed lines 10-52 from:

Release cycles

The release cycles is mainly time driven : a release each 5-7 months. depending on the required volume of work for the respective release

Smaller steps in releases will be more friendly to users as there are no big gaps between releases, easier and more appealing to upgrade. Also, shorter release cycles will make new features available in stable versions much faster.

Next Release Planning

On a new cycle, we will start with a brainstorming on what the next release should contain (or focus on). This will open up the development and roadmap of the project to the entire community ( see 1.9 example )

We will maintain a web page with the TODO features that will be updated (this process is to be continuous); also the items that where address to be documented and listed as new available features.

As the release is time driven, the next release will contain only the features (from TODO list, based on priorities) that can be done in that time frame; the remaining list will be inherited by the next release.

Steps inside a Cycle

  • brainstorming on TODO list
  • estimating the release time (T) based on the volume of work

(between 5-7 months)

  • actual work on implementing the items on TODO list ; it is

critical important to have a better description / documentation / examples on the newly added feature,as this will help people to understand and use them from day 0 (an undocumented super feature is an inexistent feature)

  • SVN freeze (no more new stuff) at T - 1 months ; at this point

the SVN trunk code is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate (or beta release)

  • this will make the trunk free and available for new work in the mean while (we overlap the testing on release N with the start of release N+1)
  • testing, debugging - 1 month -> at T we have the GA release (full stable release)

Version Management

We will have two types of supported OpenSIPS stable releases :

  • long term releases - will be supported for 2 years after it's release
  • standard releases - will be supported for 1 year after it's release

Such a model should maintain a decent balance between getting features out the door and support. People wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases.

to:
  • Release interval
    • the release cycles is mainly time driven : a release each 5-7 months. Inside that intervals, what date will be is feature driven, depending on the required volume of work.
  • Release Planning
    • open brainstorming on what the next release should contain.
    • compile a TODO list for the next release to fit the time frame; list may be dynamically updated.
    • estimating the release time (T) based on the volume of work (between 5-7 months)
    • actual work on implementing the items on TODO list ; docs must be realtime updated to reflect code changes
    • SVN freeze (no more additions) at T - 1 month ; SVN trunk code is copied in a new separate SVN branch
    • Release Candidate (or beta release)
    • testing, debugging during 1 month (or how long it takes) -> at T we have the General Available (GA) release (full stable release)

Version Management

From maintenances point of, there are two types of releases.

  • long term releases - will be supported for 2 years after it's release
  • standard releases - will be supported up to the next release

The only difference is just for how long they are supported. The releasing process, stability and everything else is the same for all.

This model aims to maintain a decent balance between getting features out the door and supporting the existing release. People wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases.

Changed line 38 from:

New (2.0) design

to:

OpenSIPS 2.0 version releases

Restore
January 18, 2013, at 02:07 PM by bogdan -
Changed lines 8-9 from:

OpenSIPS release policy is designed in such a way to be he open (everyone is involved), predictable and reliable (know what to expect) and transparent (to the whole community).

to:

OpenSIPS release policy is designed in such a way to be open (everyone is involved), predictable and reliable (know what to expect) and transparent (to the whole community).

Changed lines 12-14 from:

Instead of a feature driven release cycle, we will have a time driven release cycle,because it is more predictable and being feature driven may actually escalate the time to the next release.

There will be a 5-7 months release cycle, depending on the required volume of work for the respective release

to:

The release cycles is mainly time driven : a release each 5-7 months. depending on the required volume of work for the respective release

Restore
January 18, 2013, at 01:59 PM by bogdan -
Changed lines 8-11 from:

Following the 1.9 OpenSIPS release, the release policy has changed, in order to target making the release process :

  • more open - anyone from community (and not only developers) should be able to contribute to the roadmap of the next release
  • more predictable - everyone should know when and how the next release will be available, so they can rely and sync their own private schedules
  • more transparent - the entire releasing process to be generally known in details, so we can achieve a better collaboration and interfacing between community and developer
to:

OpenSIPS release policy is designed in such a way to be he open (everyone is involved), predictable and reliable (know what to expect) and transparent (to the whole community).

Restore
January 17, 2013, at 04:21 PM by vlad_paiu -
Added lines 61-62:
Restore
January 17, 2013, at 04:02 PM by vlad_paiu -
Changed line 64 from:
to:
  • First code release of OpenSIPS 2.0 is available for public. Take a look at the new design overview and also see the stage1 available features and how to download it.
Restore
January 17, 2013, at 04:01 PM by vlad_paiu -
Changed lines 53-56 from:
  • long term releases -
  • short term releases - at any moment, officially we will support only the last 2 stable

release

to:
  • long term releases - will be supported for 2 years after it's release
  • standard releases - will be supported for 1 year after it's release

Such a model should maintain a decent balance between getting features out the door and support. People wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases.

Changed lines 60-61 from:

Once an OpenSIPS releases moves to unsupported status, it will not get any new bug fixes, any packaging or new tarballs.

to:

Once an OpenSIPS release moves to unsupported status, it will not get any new bug fixes, any packaging or new tarballs.

Changed lines 63-68 from:
  • a complete new repository entry (probably GIT based) will be created for the new version (we need to keep the current trunk as testing ground for the 1.6 branch)
  • the code already takes shape - once it will have a basic functionality (able to start, stop, create threads, cfg read, etc), we will upload the code on public repository.
  • the first release of the 2.0 version is estimated to be done around beginning of 2011. Could be sooner or later, depending on challenges and support (man power) we will have.
to:
Restore
January 17, 2013, at 03:48 PM by vlad_paiu -
Changed lines 50-62 from:

Version Management ================== 

     - at any moment, officially we will support only the last 2 stable

release (by support I mean 

         troubleshooting, fixing bugs, backporting, etc)
     - whatever is older than 2 stable release (like older than 1.7 now)

is unsupported (no fixing, 

         no packing, no new tarballs)
     - when a new release gets to a full stable state, the window of 2

supported versions is shifted 

         (like when 1.9 will become stable, 1.7 will become obsolete and

unsupported).

to:

Version Management

We will have two types of supported OpenSIPS stable releases :

  • long term releases -
  • short term releases - at any moment, officially we will support only the last 2 stable

release

By supporting a version, we understand troubleshooting, fixing bugs, and backporting various new fixes from more recent OpenSIPS versions. Also, we will take care maintaining packages and tarballs for the supported releases.

Once an OpenSIPS releases moves to unsupported status, it will not get any new bug fixes, any packaging or new tarballs.

Restore
January 17, 2013, at 03:42 PM by vlad_paiu -
Changed lines 47-49 from:
  • this will make the trunk free and available

for new work in the mean while (we overlap the testing on release N with the start of release N+1)

to:
  • this will make the trunk free and available for new work in the mean while (we overlap the testing on release N with the start of release N+1)
Restore
January 17, 2013, at 03:42 PM by vlad_paiu -
Changed lines 35-38 from:

Steps inside a Cycle ==================== 

     - brainstorming on TODO list
     - estimating the release time (T) based on the volume of work
to:

Steps inside a Cycle

  • brainstorming on TODO list
  • estimating the release time (T) based on the volume of work
Changed lines 40-53 from:
     - actual work on implementing the items on TODO list ; it is

critical important to have a 

         better description / documentation / examples on the newly

added feature -> it will help 

         people to understand and use them from day 0 (an undocumented

super feature is an 

         inexistent feature)
     - SVN freeze (no more new stuff) at T - 1 months ; at this point

the SVN trunk code 

         is moved in a new separate SVN branch (dedicated to that

release)-> Release Candidate 

         (or beta release) ; this will make the trunk free and available

for new work in the 

         mean while (we overlap the testing on release N with the start
to:
  • actual work on implementing the items on TODO list ; it is

critical important to have a better description / documentation / examples on the newly added feature,as this will help people to understand and use them from day 0 (an undocumented super feature is an inexistent feature)

  • SVN freeze (no more new stuff) at T - 1 months ; at this point

the SVN trunk code is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate (or beta release)

  • this will make the trunk free and available

for new work in the mean while (we overlap the testing on release N with the start

Changed lines 50-51 from:
     - testing, debugging - 1 month -> at T we have the GA release (full

stable release)

to:
  • testing, debugging - 1 month -> at T we have the GA release (full stable release)
Restore
January 17, 2013, at 03:40 PM by vlad_paiu -
Changed line 25 from:

development and roadmap of the project to the entire community ( see Main.Ver190? )

to:

development and roadmap of the project to the entire community ( see 1.9 example )

Restore
January 17, 2013, at 03:39 PM by vlad_paiu -
Changed lines 25-26 from:

development and roadmap of the project to the entire community ( see http://www.opensips.org/Main/Ver190#toc15? )

to:

development and roadmap of the project to the entire community ( see Main.Ver190? )

Changed lines 29-31 from:

be documented and listed as new available features (see http://www.opensips.org/Main/Ver190?)

to:

be documented and listed as new available features.

Restore
January 17, 2013, at 03:37 PM by vlad_paiu -
Changed lines 25-27 from:

development and roadmap of the project to the entire community ( see [ 1.9 example | http://www.opensips.org/Main/Ver190#toc15 ] ) 

 maintain a web page with the TODO features that will be updated
to:

development and roadmap of the project to the entire community ( see http://www.opensips.org/Main/Ver190#toc15? )

We will maintain a web page with the TODO features that will be updated

Changed lines 30-31 from:

http://www.opensips.org/Main/Ver190) 

     - as the release is time driven, the next release will contain only
to:

http://www.opensips.org/Main/Ver190?)

As the release is time driven, the next release will contain only

Restore
January 17, 2013, at 03:35 PM by vlad_paiu -
Changed lines 21-23 from:

Next Release TODO ================== 

     - on a new cycle, we should start with a brainstorming on what the
to:

Next Release Planning

On a new cycle, we will start with a brainstorming on what the

Changed lines 25-26 from:

development and roadmap of the project to the entire community. 

     - maintain a web page with the TODO features that will be updated
to:

development and roadmap of the project to the entire community ( see [ 1.9 example | http://www.opensips.org/Main/Ver190#toc15 ] ) 

 maintain a web page with the TODO features that will be updated
Restore
January 17, 2013, at 03:34 PM by vlad_paiu -
Added lines 12-69:

Release cycles

Instead of a feature driven release cycle, we will have a time driven release cycle,because it is more predictable and being feature driven may actually escalate the time to the next release.

There will be a 5-7 months release cycle, depending on the required volume of work for the respective release

Smaller steps in releases will be more friendly to users as there are no big gaps between releases, easier and more appealing to upgrade. Also, shorter release cycles will make new features available in stable versions much faster.

Next Release TODO ================== 

     - on a new cycle, we should start with a brainstorming on what the

next release should contain (or focus on). This will open up the development and roadmap of the project to the entire community. 

     - maintain a web page with the TODO features that will be updated

(this process is to be continuous); also the items that where address to be documented and listed as new available features (see http://www.opensips.org/Main/Ver190) 

     - as the release is time driven, the next release will contain only

the features (from TODO list, based on priorities) that can be done in that time frame; the remaining list will be inherited by the next release.

Steps inside a Cycle ==================== 

     - brainstorming on TODO list
     - estimating the release time (T) based on the volume of work

(between 5-7 months) 

     - actual work on implementing the items on TODO list ; it is

critical important to have a 

         better description / documentation / examples on the newly

added feature -> it will help 

         people to understand and use them from day 0 (an undocumented

super feature is an 

         inexistent feature)
     - SVN freeze (no more new stuff) at T - 1 months ; at this point

the SVN trunk code 

         is moved in a new separate SVN branch (dedicated to that

release)-> Release Candidate 

         (or beta release) ; this will make the trunk free and available

for new work in the 

         mean while (we overlap the testing on release N with the start

of release N+1) 

     - testing, debugging - 1 month -> at T we have the GA release (full

stable release)

Version Management ================== 

     - at any moment, officially we will support only the last 2 stable

release (by support I mean 

         troubleshooting, fixing bugs, backporting, etc)
     - whatever is older than 2 stable release (like older than 1.7 now)

is unsupported (no fixing, 

         no packing, no new tarballs)
     - when a new release gets to a full stable state, the window of 2

supported versions is shifted 

         (like when 1.9 will become stable, 1.7 will become obsolete and

unsupported).

Restore
January 17, 2013, at 03:01 PM by vlad_paiu -
Changed lines 10-11 from:
  • more predictable - everyone should know when and how the next release will be available
  • more transparent - the entire releasing process to be generally known in details
to:
  • more predictable - everyone should know when and how the next release will be available, so they can rely and sync their own private schedules
  • more transparent - the entire releasing process to be generally known in details, so we can achieve a better collaboration and interfacing between community and developer
Restore
January 17, 2013, at 03:00 PM by vlad_paiu -
Changed lines 8-11 from:

Following the start of the work for OpenSIPS 2.0, the priorities and policies on releases changed.

Right now, most of development effort is invested in the version 2.0 code. What this means:

to:

Following the 1.9 OpenSIPS release, the release policy has changed, in order to target making the release process :

  • more open - anyone from community (and not only developers) should be able to contribute to the roadmap of the next release
  • more predictable - everyone should know when and how the next release will be available
  • more transparent - the entire releasing process to be generally known in details
Restore
January 17, 2013, at 02:50 PM by vlad_paiu -
Changed line 13 from:

New (2.0) design

to:

New (2.0) design

Restore
January 17, 2013, at 02:50 PM by vlad_paiu -
Changed lines 13-23 from:

Old (existing) design

  • there will be no more major release for this design - that's it, 1.6 is end of line
  • bug fixes will be carried on as usual
  • minor / essential improvements / adds-on will still be done on 1.6 branch
  • minor releases on 1.6 branch will contain not only bug fixings, but also the improvements and adds-on ; actually 1.6 branch and trunk will contain the same code - trunk will be for coding and testing, 1.6 will be the stable - after a change/add-on is tested on trunk, it will be backported to 1.6 to be part of the next minor release.
New (2.0) design
to:

New (2.0) design

Restore
January 17, 2013, at 02:49 PM by vlad_paiu -
Changed line 43 from:

Module maintainers

to:

Module maintainers

Restore
January 17, 2013, at 02:49 PM by vlad_paiu -
Added lines 3-4:

(:toc-float Table of Content:)

Changed lines 6-7 from:

Release policy

to:

Release policy

Changed lines 13-14 from:
Old (existing) design
to:

Old (existing) design

Changed line 32 from:

Developers hierarchy

to:

Developers hierarchy

Restore
June 11, 2010, at 06:58 PM by bogdan -
Changed line 105 from:
  1. presence_xcapdiff - Lucian Stanescu
to:
  1. presence_xcapdiff - Saúl Ibarra Corretgé
Restore
March 04, 2010, at 06:16 PM by 81.180.102.217 -
Added lines 2-27:

Release policy

Following the start of the work for OpenSIPS 2.0, the priorities and policies on releases changed.

Right now, most of development effort is invested in the version 2.0 code. What this means:

Old (existing) design
  • there will be no more major release for this design - that's it, 1.6 is end of line
  • bug fixes will be carried on as usual
  • minor / essential improvements / adds-on will still be done on 1.6 branch
  • minor releases on 1.6 branch will contain not only bug fixings, but also the improvements and adds-on ; actually 1.6 branch and trunk will contain the same code - trunk will be for coding and testing, 1.6 will be the stable - after a change/add-on is tested on trunk, it will be backported to 1.6 to be part of the next minor release.
New (2.0) design
  • a complete new repository entry (probably GIT based) will be created for the new version (we need to keep the current trunk as testing ground for the 1.6 branch)
  • the code already takes shape - once it will have a basic functionality (able to start, stop, create threads, cfg read, etc), we will upload the code on public repository.
  • the first release of the 2.0 version is estimated to be done around beginning of 2011. Could be sooner or later, depending on challenges and support (man power) we will have.
Restore
June 10, 2009, at 06:41 PM by adigeo -
Changed line 79 from:
  1. presence_xcapdiff - Denis Bilenko
to:
  1. presence_xcapdiff - Lucian Stanescu
Restore
April 23, 2009, at 11:09 AM by bogdan -
Added line 79:
  1. presence_xcapdiff - Denis Bilenko
Restore
April 23, 2009, at 11:02 AM by bogdan -
Added line 93:
  1. signaling - Anca Vamanu
Restore
April 23, 2009, at 11:01 AM by bogdan -
Added line 63:
  1. mmgeoip - Kobi Eshun
Added line 77:
  1. presence_dialoginfo - Anca Vamanu
Added line 82:
  1. pua_dialoginfo - Anca Vamanu
Added line 86:
  1. qos - Ovidiu Sas
Added line 88:
  1. regex - Iñaki Baz Castillo
Restore
April 23, 2009, at 10:57 AM by bogdan -
Added lines 55-56:
  1. load_balancer - Bogdan-Andrei Iancu
  2. localcache - Anca Vamanu
Restore
April 23, 2009, at 10:57 AM by bogdan -
Added line 50:
  1. identity - Bogdan-Andrei Iancu
Restore
April 23, 2009, at 10:56 AM by bogdan -
Added line 28:
  1. closeddial - Sergio Gutierrez
Restore
April 23, 2009, at 10:55 AM by bogdan -
Added line 42:
  1. drouting - Bogdan-Andrei Iancu
Restore
April 23, 2009, at 10:54 AM by bogdan -
Added line 25:
  1. call_control - Dan Pascu
Restore
October 28, 2008, at 04:43 PM by 81.180.102.217 -
Changed line 95 from:
  1. uri_db - commonly maintained
to:
  1. uri_db - Sergio Gutierrez
Restore
August 09, 2008, at 11:55 PM by 92.80.104.234 -
Changed line 61 from:
  1. osp - Di-Shi Sun
to:
  1. osp - Di-Shi Sun, Dmitry Isakbayev
Restore
August 09, 2008, at 05:04 PM by 92.80.104.234 -
Changed line 26 from:
  1. cfgutils - Carsten Bock
to:
  1. cfgutils - commonly maintained
Restore
August 09, 2008, at 05:04 PM by 92.80.104.234 -
Changed line 17 from:
  1. alias_db - Bogdan-Andrei Iancu
to:
  1. alias_db - commonly maintained
Changed line 26 from:
  1. cfgutils - commonly maintained
to:
  1. cfgutils - Carsten Bock
Restore
August 09, 2008, at 05:00 PM by 92.80.104.234 -
Changed lines 20-21 from:
  1. auth_diameter -
  2. auth_radius -
to:
  1. auth_diameter - unmaintained
  2. auth_radius - commonly maintained
Changed lines 23-26 from:
  1. avp_radius -
  2. benchmark -
  3. carrierroute -
  4. cfgutils -
to:
  1. avp_radius - commonly maintained
  2. benchmark - Bastian Friedrich
  3. carrierroute - commonly maintained
  4. cfgutils - commonly maintained
Changed lines 28-41 from:
  1. db_berkeley -
  2. db_flatstore -
  3. db_mysql -
  4. db_oracle -
  5. db_postgres -
  6. db_text -
  7. db_unixodbc -
  8. dialog - Bogdan-Andrei Iancu
  9. dialplan -
  10. dispatcher -
  11. diversion -
  12. domain -
  13. domainpolicy -
  14. enum -
to:
  1. db_berkeley - Will Quan
  2. db_flatstore - commonly maintained
  3. db_mysql - commonly maintained
  4. db_oracle - commonly maintained
  5. db_postgres - Greg Fausak
  6. db_text - commonly maintained
  7. db_unixodbc - commonly maintained
  8. dialog - Bogdan-Andrei Iancu , Ovidiu Sas
  9. dialplan - Anca Vamanu
  10. dispatcher - commonly maintained
  11. diversion - commonly maintained
  12. domain - commonly maintained
  13. domainpolicy - commonly maintained
  14. enum - commonly maintained
Changed lines 45-46 from:
  1. group_radius -
  2. h350 -
to:
  1. group_radius - commonly maintained
  2. h350 - Christian Schlatter
Changed lines 49-51 from:
  1. lcr -
  2. ldap -
  3. mangler -
to:
  1. lcr - commonly maintained
  2. ldap - Christian Schlatter
  3. mangler - unmaintained
Changed line 53 from:
  1. mediaproxy -
to:
  1. mediaproxy - Dan Pascu
Changed lines 57-67 from:
  1. msilo -
  2. nathelper - Bogdan-Andrei Iancu
  3. nat_traversal -
  4. options -
  5. osp -
  6. path -
  7. pdt -
  8. peering -
  9. perl -
  10. perlvdb -
  11. permissions -
to:
  1. msilo - commonly maintained
  2. nathelper - Bogdan-Andrei Iancu , Maxim Sobolev
  3. nat_traversal - Dan Pascu
  4. options - commonly maintained
  5. osp - Di-Shi Sun
  6. path - commonly maintained
  7. pdt - commonly maintained
  8. peering - commonly maintained
  9. perl - Bastian Friedrich
  10. perlvdb - Bastian Friedrich
  11. permissions - commonly maintained
Changed line 77 from:
  1. ratelimit -
to:
  1. ratelimit - Ovidiu Sas
Changed line 79 from:
  1. rls -
to:
  1. rls - Anca Vamanu
Changed lines 81-82 from:
  1. seas -
  2. siptrace -
to:
  1. seas - Andrei Pisau
  2. siptrace - Bogdan-Andrei Iancu
Changed lines 85-87 from:
  1. snmpstats -
  2. speeddial -
  3. sst -
to:
  1. snmpstats - Jeffrey Magder
  2. speeddial - commonly maintained
  3. sst - Ron Winacott
Changed lines 89-90 from:
  1. textops -
  2. tlsops -
to:
  1. textops - commonly maintained
  2. tlsops - commonly maintained
Changed lines 94-97 from:
  1. uri -
  2. uri_db -
  3. uri_radius -
  4. userblacklist -
to:
  1. uri - commonly maintained
  2. uri_db - commonly maintained
  3. uri_radius - commonly maintained
  4. userblacklist - commonly maintained
Changed lines 99-100 from:
  1. xcap_client -
  2. xlog -
to:
  1. xcap_client - Anca Vamanu
  2. xlog - commonly maintained
Restore
August 09, 2008, at 04:48 PM by 92.80.104.234 -
Changed lines 16-19 from:
  1. acc -
  2. alias_db -
  3. auth -
  4. auth_db -
to:
  1. acc - Bogdan-Andrei Iancu
  2. alias_db - Bogdan-Andrei Iancu
  3. auth - Bogdan-Andrei Iancu
  4. auth_db - Bogdan-Andrei Iancu
Changed line 22 from:
  1. avpops -
to:
  1. avpops - Bogdan-Andrei Iancu
Changed line 27 from:
  1. cpl-c -
to:
  1. cpl-c - Bogdan-Andrei Iancu
Changed line 35 from:
  1. dialog -
to:
  1. dialog - Bogdan-Andrei Iancu
Changed lines 42-44 from:
  1. exec -
  2. gflags -
  3. group -
to:
  1. exec - Bogdan-Andrei Iancu
  2. gflags - Bogdan-Andrei Iancu
  3. group - Bogdan-Andrei Iancu
Changed lines 47-48 from:
  1. imc -
  2. jabber -
to:
  1. imc - Anca Vamanu
  2. jabber - Anca Vamanu
Changed line 52 from:
  1. maxfwd -
to:
  1. maxfwd - Bogdan-Andrei Iancu
Changed lines 54-56 from:
  1. mi_datagram -
  2. mi_fifo -
  3. mi_xmlrpc -
to:
  1. mi_datagram - Bogdan-Andrei Iancu
  2. mi_fifo - Bogdan-Andrei Iancu
  3. mi_xmlrpc - Bogdan-Andrei Iancu
Changed line 58 from:
  1. nathelper -
to:
  1. nathelper - Bogdan-Andrei Iancu
Changed lines 68-76 from:
  1. pike -
  2. presence -
  3. presence_mwi -
  4. presence_xml -
  5. pua -
  6. pua_bla -
  7. pua_mi -
  8. pua_usrloc -
  9. pua_xmpp -
to:
  1. pike - Bogdan-Andrei Iancu
  2. presence - Anca Vamanu
  3. presence_mwi - Anca Vamanu
  4. presence_xml - Anca Vamanu
  5. pua - Anca Vamanu
  6. pua_bla - Anca Vamanu
  7. pua_mi - Anca Vamanu
  8. pua_usrloc - Anca Vamanu
  9. pua_xmpp - Anca Vamanu
Changed line 78 from:
  1. registrar -
to:
  1. registrar - Bogdan-Andrei Iancu
Changed line 80 from:
  1. rr -
to:
  1. rr - Bogdan-Andrei Iancu
Changed lines 83-84 from:
  1. sl -
  2. sms -
to:
  1. sl - Bogdan-Andrei Iancu
  2. sms - Bogdan-Andrei Iancu
Changed line 88 from:
  1. statistics -
to:
  1. statistics - Bogdan-Andrei Iancu
Changed lines 91-93 from:
  1. tm -
  2. uac -
  3. uac_redirect -
to:
  1. tm - Bogdan-Andrei Iancu
  2. uac - Bogdan-Andrei Iancu
  3. uac_redirect - Bogdan-Andrei Iancu
Changed line 98 from:
  1. usrloc -
to:
  1. usrloc - Bogdan-Andrei Iancu
Changed line 101 from:
  1. xmpp -
to:
  1. xmpp - Anca Vamanu
Restore
August 09, 2008, at 04:44 PM by 92.80.104.234 -
Changed lines 15-101 from:

Module maintainers

to:

Module maintainers

  1. acc -
  2. alias_db -
  3. auth -
  4. auth_db -
  5. auth_diameter -
  6. auth_radius -
  7. avpops -
  8. avp_radius -
  9. benchmark -
  10. carrierroute -
  11. cfgutils -
  12. cpl-c -
  13. db_berkeley -
  14. db_flatstore -
  15. db_mysql -
  16. db_oracle -
  17. db_postgres -
  18. db_text -
  19. db_unixodbc -
  20. dialog -
  21. dialplan -
  22. dispatcher -
  23. diversion -
  24. domain -
  25. domainpolicy -
  26. enum -
  27. exec -
  28. gflags -
  29. group -
  30. group_radius -
  31. h350 -
  32. imc -
  33. jabber -
  34. lcr -
  35. ldap -
  36. mangler -
  37. maxfwd -
  38. mediaproxy -
  39. mi_datagram -
  40. mi_fifo -
  41. mi_xmlrpc -
  42. msilo -
  43. nathelper -
  44. nat_traversal -
  45. options -
  46. osp -
  47. path -
  48. pdt -
  49. peering -
  50. perl -
  51. perlvdb -
  52. permissions -
  53. pike -
  54. presence -
  55. presence_mwi -
  56. presence_xml -
  57. pua -
  58. pua_bla -
  59. pua_mi -
  60. pua_usrloc -
  61. pua_xmpp -
  62. ratelimit -
  63. registrar -
  64. rls -
  65. rr -
  66. seas -
  67. siptrace -
  68. sl -
  69. sms -
  70. snmpstats -
  71. speeddial -
  72. sst -
  73. statistics -
  74. textops -
  75. tlsops -
  76. tm -
  77. uac -
  78. uac_redirect -
  79. uri -
  80. uri_db -
  81. uri_radius -
  82. userblacklist -
  83. usrloc -
  84. xcap_client -
  85. xlog -
  86. xmpp -
Restore
August 09, 2008, at 04:34 PM by 92.80.104.234 -
Added line 9:
  1. tool maintainers - developers not involved in OpenSIPS core or modules, but in surrounding tools and utilities (control tool, DB scripts, utilities, etc)
Changed lines 11-13 from:
  1. packagers - people taking care of OpenSIPSpackaging (for different OS's) ; they are in-charge with maintaining the specs and preparing packages.
to:
  1. packagers - people taking care of OpenSIPSpackaging (for different OS's) ; they are in-charge with maintaining the specs and preparing packages.
Restore
August 09, 2008, at 04:32 PM by 92.80.104.234 -
Added line 3:
Added line 13:
Restore
August 09, 2008, at 04:31 PM by 92.80.104.234 -
Changed lines 3-7 from:

Development hierarchy (from top to bottom):

  1. core developers
  2. module developers
  3. contributors
  4. packagers
to:

Developers hierarchy

To ensure the quality and technical competence across the project, the development work is governed by developer knowledge.
OpenSIPS project implements several layers of technical competence - the development hierarchy:

  1. core developers - developers taking care of OpenSIPS core, of the overall architecture and design
  2. module developers - developers taking care of a OpenSIPS module (or modules). They are module maintainers. For work expending across their modules they need to address to other module developers (for other modules) or to core developers (for core or global matters)
  3. contributors - developers randomly contributing to OpenSIPS by providing patches (for fixes or new features). For how this works, see Contributing page.
  4. packagers - people taking care of OpenSIPSpackaging (for different OS's) ; they are in-charge with maintaining the specs and preparing packages.

Module maintainers

Restore
August 09, 2008, at 04:17 PM by 92.80.104.234 -
Changed lines 1-7 from:

Development -> Development

to:

Development -> Development

Development hierarchy (from top to bottom):

  1. core developers
  2. module developers
  3. contributors
  4. packagers
Restore
August 09, 2008, at 03:21 PM by 92.80.104.234 -
Added line 1:

Development -> Development

Restore
Edit | History | Print | Recent Changes | Search
Page last modified on May 14, 2013, at 01:00 PM