Thank you for your reply! > I'm the one who should do the thanking: I'm using your distro.
I guess it's a two way thing; you're contributing, too! :) Let me give you an example of why I ask the question. Let's say that in Ubuntu, we take your patch. Upstream later decide to achieve the same thing, but in a different way, so the tree looks different. In the future, will behaviour on Ubuntu then differ from upstream behaviour, such that we won't be able to switch Ubuntu to upstream's behaviour without regressing somebody who is depending on Ubuntu's tree structure for krb5.conf? The risk is that we end up with an indefinite maintenance burden on Ubuntu because we accidentally forked upstream. For this reason, sending the patch upstream is better for us in general. But if there's some particular reason that we should make a change in Ubuntu ahead of upstream, then it can be considered, just with careful thought to the risk I have tried to explain above. A better way would be to cherry-pick patches from upstream's VCS - preferably after an upstream release. Then we know that upstream intend to support the change in terms of backwards compatibility. Does that make sense? For this reason I think submitting this upstream would be better in this case, where users will see a behavioural change that they may depend on, and that we don't want to be forced to regress in the future. ** Tags added: needs-upstream-report ** Changed in: augeas (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to augeas in Ubuntu. https://bugs.launchpad.net/bugs/1302638 Title: augeas-tools fails to parse krb5.conf (solution provided) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
