On Fri, 18 Jan 2019 at 07:43, zyx <z...@gmx.us> wrote: > this is what I dislike on patch series the most. Even when one does > patch review in "correct order", he/she can find issues and report > them, then realize it had been fixed in the next patch. That's a plain > waste of time and, which is worst, it introduces unneeded broken state > of the repository (ideally, repository at any commit should be > buildable and without known bugs).
xyx, let me point that I actually also sent the merged patch series in the cover letter but Dominik is still holding it because larger of 40kb. It's frustrating to me, because I was excepting such objections from you. I solicited Dominik to unlock the message. Actually, I send patch series because when I add X and I touch Y which is loosely related to X, then change to Y makes sense to be on separate commit while developing. Doing this I actually expose more than I would like, but it lets objections to emerge quickly, if there are. It's worth mention to say that patch series works well when they are online in the message body, because people read the code and comment them right away. In open source projects when they highly rely on this, patch series are just accepted as a whole or dumped, and the next iteration is a corrected patch series. Of course they don't apply patches manually, that's another story. So, how do I continue? Should I send updated merged patch 1-5? Patch would be > 40kb, so we should either wait Dominik approval of my messages or I can open ticket on sf.net. But seriously, if I have to rely on ticketing for open source project contribution, why the project doesn't just migrate to something more pull request friendly? >The difference between overlooked > bugs and known bugs is that all the changes in the proposal add new > code, thus it should provide consistent code, not intentionally > partially broken. > > I'm not breaking my code intentional, that patch was sent separately few weeks ago because I knew I would have based new code on it so I actually tested it intensively, unfortunately not noticing the leak. Following patches in the series don't fix the leak. _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
