I have tested the two cases you describe (Find in Files and inserting a blank line).
Both work for me on Padre 0.88 release tarball. On 11 August 2011 05:58, Sebastian Willing <sebastian.will...@web.de> wrote: > This release is really bad for Padre. > > The old branch was stable besides one crash bug which was covered at the > same day the branch was frozen. Adding this fix would have been a great > release. > > The last 200 commits introduced a number of critical bugs breaking > important features of Padre (like find in files, entering one blank line > into the editor) - but noone cared. > > The bugs were reported as "blocker" state tickets - but noone cared. > > Padre was released containing with noone caring that it was really > unusable for productional work at this time. > > Today, the new blocker bugs were fixed and it turned out that all of > them plus another one from #105 had been typos, logic errors and simple > things like this. > > I'm aware that not everybody could run the unit tests before each commit > - including me (with 30 to 45 minutes for a full test run on my > hardware), but all these bugs (which burned about two or three hours of > Padre development time) were really easy detectable by running "dev" and > trying out the chanced feature. > > The newline issue wasn't easy to try out, because it was unexpected, but > it caught me within 30 seconds after downloading the bug using "svn up", > it must have been the same for the guy committing the bug. Why was it > not fixed? > > Anyway, we got a release out there which is heavily broken and the > release notes doesn't even flag this release as "unstable/testing", so > we're going to annoy many users and maybe loose some of them. > > I suggest two new global Padre development rules: > > 1. Before committing anything, run your local Padre trunk copy and do a > quick test of what you changed. > It's ok to commit broken things and maybe even syntax errors if it's > written down in the commit notice and either fixed within a very short > time (commit to switch from work to home PC) or a "blocker" state ticket > is being opened/the ticket dealing with it changed to "blocker" state. > > 2. No release is being done as long as there is any "blocker" ticket open. > The release manager has to walk though all open blockers and either > downgrade them to a lower priority or clearly ensure that the bug was > introduced after branching and hasn't been merged to branch. Of cause, > he may also call for checking blockers like calling for translators, I'm > pretty sure bowtie, zenog and others will jump in and take care of the > blockers. > > #1268 is no longer blocker, this should have been downgraded shortly > after upgrading it. > > #1270 is an enhancement, I doubt it could be a blocker. Should be > downgraded to a real value. > > Your comments, please. > > Sorry for being that aggressive, I don't like wasting dev time :-( > > Sebastian > _______________________________________________ > Padre-dev mailing list > Padre-dev@perlide.org > http://mail.perlide.org/mailman/listinfo/padre-dev > _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
