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.

------------------------------------------------------------------------------
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

Reply via email to