On Sunday 13 December 2009 14:40:51 SF Markus Elfring wrote: > > As I said, it should be obvious. 11 out 11 hunks fail, and I can > > visually in less than 1 minute find two syntax errors. > > Can informations from the article "How to create and apply a patch with > Git" help to resolve any open issues? > http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ > > Would you like to give it another try with the appended file format? > > Regards, > Markus
Hello Markus, Thanks for your patch. Yes, indeed it is a bit of an improvement since you sent it to us in format-patch format, which is our preferred format as documented in the Developer's guide on the bacula.org web site. I also note that you are persistent, which is a good quality. What is inconvenient is that it is compressed, which adds an extra step, though it is really no big deal. 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). 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. 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. 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. Simply take the configure file generated by your version of configure.in and try running it in a fully updated master, and you will certainly see a lot of errors -- it may even totally fail. What I suggest is to consider to start with something really small -- no more than 10 or 20 lines of changes *maximum* so that it is something that we can easily determine what the consequences will be. 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. Best regards, Kern ------------------------------------------------------------------------------ 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
