> However, there are several reasons why we cannot accept the patch: > > 1. It is some 3200 lines of changes and we are essentially in a release > freeze > at this point where no nonessential patches are accepted (new code in > development by developers is being kept in their private branches for > committing after the next release).
The regular freeze is fine. My update suggestion can be enqueued for a future software release. > 2. Your patch completely deletes the current autoconf.in file, which means > that we are not able to see what actual changes were made. Well, we could > apply it then diff ourselves, but it is really not the way we like to work. You can still look at the previous update file. > 3. You have moved configure.in from <bacula>/autoconf to <bacula> and there > is > no reason to do so. It only serves to "pollute" the main directory, which > can confuse users. I have got the experience that the command "autoreconf" is looking for configuration templates in the project directory. > 4. Even if we were ready to accept it, you have sent a patch that you have > not > rebased on our master, which means that it is out of date and because of the > change of directory will introduce errors into the configure. I suggested changes on the base of your repository that I cloned in November. > Rather than making modifications to existing code that works, we would > much rather receive a few bug fixes, then when development is going full steam > (a couple months after the next release) we would be more open to larger > cleanups. I am curious if more configuration script adjustments will happen in the next year. Regards, Markus ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
