On Wed, 22 Jun 2016, Paul Jakma wrote:
On Wed, 22 Jun 2016, Jafar Al-Gharaibeh wrote:
For example, assume I want to push the new feature that I have been
working on: MTR-OSPF (RFC4915). Having that in the CE (thing ;) ) for a
few cycles might help us understand its impact on users or whether it is
worthy to be added to the main release or not. I really think there is a
value there.
Oh, there might well be value in having staging areas for experimental
features.
Oh, in general though, this is a costly path to go down. It's much
better to just get it reviewed and decided on. I.e. get it down the
human review parts of the integration process:
Contribution
|
V
High level review---->push back
|
V
Arch review---------->push back
|
V
Implementation------>push back
review
|
V
master
High-level review being 'does this feature make sense in the abstract',
and often being part and parcel of architectural review. Arch. review
looking at how it should fit in with the existing code.
For features that will involve a lot of work, I *STRONGLY* suggest
people come to the list *first* with a proposal and getting those
reviewed and agreed to _before_ substantive coding work! Otherwise, do
the implementation work _knowing_ that you may have to throw it away.
Not involving the community in design decisions, and just proceeding to
implementation _does not_ give one a pass on community architectural
review.
In general, stuff should just go through that process ASAP.
Stabilisation is something that should happen _after_ the above.
(Testing / CI steps not shown above, but before imp. review presumably).
Course, people have to be willing to deal with review comments.
regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
All newspaper editorial writers ever do is come down from the hills after
the battle is over and shoot the wounded.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
