how about pv module, can that be moved to from modules_k to modules? i tried and at least it compiles as is in modules.
-- juha
20 okt 2009 kl. 21.02 skrev Juha Heinanen:
Juha Heinanen writes:
how about pv module, can that be moved to from modules_k to modules? i tried and at least it compiles as is in modules.
same for k regex and htable modules.
So the question is really about code freeze policys.
Personally I would encorage making these changes.
/O
On Oct 20, 2009 at 21:44, Juha Heinanen jh@tutpro.com wrote:
how about pv module, can that be moved to from modules_k to modules? i tried and at least it compiles as is in modules.
We are in freeze and this would complicate merges from master to sr_3.0 a little (unless we want to propagate the change in sr_3.0 which I don't think it's a good idea at this point).
Apart from that IMHO k developer should decide if pv is ready/should be moved.
Andrei
Andrei Pelinescu-Onciul writes:
We are in freeze and this would complicate merges from master to sr_3.0 a little (unless we want to propagate the change in sr_3.0 which I don't think it's a good idea at this point).
i meant that the move is done in sr_3.0, not in master and then propagated from sr_3.0 to master.
Apart from that IMHO k developer should decide if pv is ready/should be moved.
yes, if developer is still around.
-- juha
On Oct 20, 2009 at 22:10, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
We are in freeze and this would complicate merges from master to sr_3.0 a little (unless we want to propagate the change in sr_3.0 which I don't think it's a good idea at this point).
i meant that the move is done in sr_3.0, not in master and then propagated from sr_3.0 to master.
Well, it might break packaging scripts and who knows what else. I personally have nothing against moving it, but everybody working on sr_3.0 or k3.0 should agree (it won't be nice to break packaging on k3.0 the next time it is merged from sr_3.0).
Apart from that IMHO k developer should decide if pv is ready/should be moved.
yes, if developer is still around.
Andrei
Andrei Pelinescu-Onciul writes:
Well, it might break packaging scripts and who knows what else. I personally have nothing against moving it, but everybody working on sr_3.0 or k3.0 should agree (it won't be nice to break packaging on k3.0 the next time it is merged from sr_3.0).
i haven't seen k3.0 packaging scripts (for example for debian), but if those exist and work, then yes, we should postpone the moves. if they don't exist, we could make the moves now.
-- juha
On 20.10.2009 21:48 Uhr, Andrei Pelinescu-Onciul wrote:
On Oct 20, 2009 at 22:10, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
We are in freeze and this would complicate merges from master to sr_3.0 a little (unless we want to propagate the change in sr_3.0 which I don't think it's a good idea at this point).
i meant that the move is done in sr_3.0, not in master and then propagated from sr_3.0 to master.
Well, it might break packaging scripts and who knows what else. I personally have nothing against moving it, but everybody working on sr_3.0 or k3.0 should agree (it won't be nice to break packaging on k3.0 the next time it is merged from sr_3.0).
I think will complicate the life right now for something that does not bring a major benefit, considering we are in freeze state. It is a long debate to start right now. Next release that should be a better integrated one, hopefully with some modules merged (sl, rr, and some other like them) will take care of having unique modules moved.
Therefore I prefer that sr_3.0 and k_3.0 stay in this state.
Cheers, Daniel
Apart from that IMHO k developer should decide if pv is ready/should be moved.
yes, if developer is still around.
Andrei
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Olle E. Johansson