On 17/02/14 18:03, Michael Blumenkrantz wrote: > 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.
What I'm essentially saying is: open source software is not created perfect and then released, it's created, and worked on, step by step, itch by itch. Tiling2 is at a state that's better than Tiling1 in every single way. It's an improvement over the current code base, that code base being e. My change to Tiling1 (i.e Tiling2) is like any change you make in e. A good comparison would be a component you've recently rewritten, twice, the compositor. It's severely misbehaving and has been for a while, and yet, it's in. That's fine, that's software development. You find a way to improve things, and you took whatever path you saw necessary. Tiling2 is a bit different than the compositor rewrites because the change is more surgical, and is an obvious stability improvement over the former version, not just usability and API (which is what the compositor changes bring to the table). I have reviewed all of the tickets you've opened on Phab, there were a bunch of them. A few were issues in E (not tiling), two of them I fixed, some were invalid, and some I couldn't reproduce. In any way, all of them were issues that exist in Tiling1, and thus are not regressions and therefore are in no way blockers for inclusion. > >> >> 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. To summarize what I've said above: 1. Compositor rewrite is known to have a lot of bugs and affects everyone, and yet it's in. 2. Tiling2 has no known *new* (compared to tiling1 that it's replacing) bugs. -- Tom. ------------------------------------------------------------------------------ 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
