On Mon, 17 Feb 2014 17:56:02 +0000 Tom Hacohen <tom.haco...@samsung.com> wrote:
> On 17/02/14 17:44, Michael Blumenkrantz wrote: > > On Mon, 17 Feb 2014 17:31:24 +0000 > > Tom Hacohen <tom.haco...@samsung.com> wrote: > > > >> On 17/02/14 17:09, Michael Blumenkrantz wrote: > >>> On Mon, 17 Feb 2014 15:48:27 +0000 > >>> Tom Hacohen <tom.haco...@samsung.com> wrote: > >>> > >>>> Hey guys, > >>>> > >>>> It's time to include Tiling2 into core. > >>>> If you are not familiar with Tiling2, it's an improvement of the Tiling > >>>> module I've been working on with help from billiob, cippp and > >>>> discomfitor. > >>>> > >>>> Main features: > >>>> * Very stable, especially compared to Tiling1. > >>>> * Tiling is done in a tree, so you can essentially tile however you'd > >>>> like. > >>>> * Good support of floating windows. > >>>> > >>>> For more info: https://phab.enlightenment.org/w/emodules/tiling2/ > >>>> > >>>> I've been using it full time for a month now, and it seems to be stable > >>>> (many thanks to discomfitor for fixing many related E bugs). It has been > >>>> an external modules and has been tested by others, and there are no > >>>> known issues. > >>>> > >>>> For all I can see, it's better than Tiling1 and introduces no > >>>> regressions. I've talked to the Tiling1 maintainer (billiob), and he > >>>> agrees that we should upgrade to Tiling2 in core, replacing Tiling1. > >>>> Since it's based on the Tiling1 code-base (though a lot has been > >>>> modified), and it serves the same purpose, I'll also rename it to > >>>> Tiling, and not include it as Tiling2. > >>>> > >>>> For all I know, the only remaining concern about Tiling2 is something > >>>> I'm not sure I'd like to fix (as I prefer the "broken" behaviour better > >>>> than the solutions), and is not a regression, as it also occurs in > >>>> Tiling1. It's an issue with not respecting windows' hints for min/max > >>>> sizes, which are, as the name implies "hints". > >>>> > >>>> So, if there are no objections, I'll probably merge this into core > >>>> Enlightenment 19 by the end of this week. > >>>> > >>>> Thanks for reading. > >>>> > >>>> -- > >>>> Tom. > >>>> > >>> > >>> Hi, > >>> > >>> I appreciate the work that you've done to improve the tiling experience > >>> under E and the time that you've spent to make these improvements. > >>> > >>> At present, however, I cannot yet support this merge due to the high > >>> number of remaining bugs. In very early preliminary testing, I've already > >>> found several serious issues. Let's revisit this topic for E19 after a > >>> bit more testing and fixing. > >> > >> High number of remaining bugs? There was one "issue" that you reported, > >> that I disagree with and already mentioned in my original post. Other > >> than that, you haven't mentioned anything, phab is a proof of that. > >> Everything works fine for me, and I haven't heard anyone else complain. > >> You have the maintainer of tiling1 siding with this change, what are you > >> talking about? > >> > >> Anyhow, while I appreciate your input for all things e, it's not your > >> call to make. If you'd like to prevent this from going in on Friday, > >> please provide some valid points. > >> > >> Also, if you have valid points to make, please make sure that they are > >> relative to Tiling1, and not absolute. I.e if something is not a > >> regression compared to Tiling1, it's not a blocker. Remember: this is > >> not introducing a new module, this is updating/fixing/improving code, > >> and replacing something that is broken for many people. > >> > >> -- > >> Tom. > >> > >> -- > >> Tom. > >> > > > > > > While I can appreciate your point of view regarding relative vs absolute > > bugs, this is not how E development is going to operate going forward. > > Getting something merged into E, regardless of whether it's a rewrite, > > should not be a process of "it's good enough to get in, I'll fix the rest > > of the things after I merge it". Merges should occur once there are no > > remaining significant issues; a great example of this is the PackageKit > > module from Davide Andreoli. After the merge, there have been almost no > > commits to the module because it was already very well polished. > > > > Regardless of whether this is or is not "updating/fixing/improving code" > > which already exists, it SHOULD fix the issues present in previous code; > > otherwise, I don't see the point in merging it at all. > > > > You seem to be continually missing my key point: I am not opposed to the > > merge in principle, I am simply opposed to it at this time. > > > > Don't twist my words. I'm not saying "It's good enough to get in, I'll > fix issues sometimes in the future". All I'm saying is, I have code that > fixes many issues, and improves on many of the faults, it should go in. > > No it should not. When you commit code to E, do you fix all the bugs in > e in one go? Of course not, it fixes some (many) of the issues, and > improves in others while introducing no regressions. E is over 280,000 lines of code, excluding the theme (another 25000). Of course I don't fix all the bugs in one go, that's clearly impossible for a team of people, let alone a single person. Comparing something of this size and variety to a tiny, specialized module with less than 3000 lines of code is not sane or reasonable under any circumstances. > > You seem to be continually missing my key point: you are wrong. I > completely disagree with you on every point you've made regarding this > issue. That's why it's up here for public discussion. If the public discussion finds that everyone is fine with ignoring my sole point, which has been that I don't want to accept merges of code with lots of known bugs, then I'm very disappointed in the community as a whole. > > By the way, I've reviewed the tickets. Thanks for reporting. Some are > recent regressions and valid, some are invalid, and all of them can (and > will be) fixed tomorrow, as I have to go now. > > -- > Tom. > > > Good. I have several more which are in the process of being submitted. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
