HIPL

Guidelines for the inclusion of extensions

Asked by René Hummen

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?

Question information

Language:
English Edit question
Status:
Expired
For:
HIPL Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Miika Komu (miika-iki) said : 		#1

Nice text, Rene. Overall ok, but few clarifications.

At the moment, the definition of an extension is probably closer to:

- Any functionality that is not stated as mandatory in RFC5201, RFC5203 or RFC5204.

(As tinyhip modularization didn't cover registration and RVS)

I agree on the properties. I agree also on the extensions that should can go into the trunk, but I would add one thing. Internal extensions, such as a GUI or support for platform XYZ, that do not affect interoperability should be ok as long as they meet the other criteria you stated.

Revision history for this message
René Hummen (rene-hummen) said : 		#2

You are right about UI functionality and platform support regarding (3), but the other items should still be valid nonetheless.

Furthermore, RFC5203 and RFC5204 functionality still being part of the code should not lead to a re-definition of what _should_ be included as an extension. Instead, we need to get some work done on these extensions to make them fulfill the properties mentioned above.

Revision history for this message
Launchpad Janitor (janitor) said : 		#3

This question was expired because it remained in the 'Open' state without activity for the last 15 days.