hipl-core team mailing list archive

[René Hummen <question123357@xxxxxxxxxxxxxxxxxxxxx>]

New question #123357 on HIPL:
https://answers.launchpad.net/hipl/+question/123357

Recently, there has been some discussion on which extensions should be kept in the HIPL codebase and which shall be doomed. Therefore, I would like to clarify my thoughts and ask for discussion on the topic.

What is an extension?
- Any functionality that is not stated as mandatory in RFC5201.

Which properties should extensions fulfill in order to be allowed to stay in the HIPL codebase?
(1) active maintenance (i.e. there's at least one developer who will look into continuous testing, bugs, etc) and
(2) possibility to disable its functionality cleanly (i.e. at least at daemon start-up or preferably even at compile-time by means of modules).

Which extensions should make it into trunk?
(1) code quality should suffice our new standards,
(2) code needs to be reviewed first (check code cleanness and maturity),
(3) it should preferably be documented as a draft or RFC at the IETF and
(4) the properties mentioned in the question above

However, this does not mean that nobody should write extensions and add new features. It merely implies that new functionality should be maintained in individual feature branches. Once mature and documented, we can merge them into trunk.


Do we agree that these are good guidelines for the inclusion of extensions? Do you think they are to strict or are we missing something?

-- 
You received this question notification because you are a member of HIPL
core team, which is an answer contact for HIPL.