Quoting Jani Nikula (2018-06-15 12:08:23) > On Thu, 14 Jun 2018, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> wrote: > > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: > >> On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> wrote: > >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > >> >> > >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > >> >> > On 12/06/2018 10:19, Jani Nikula wrote: > >> >> >> Semi-RFC. Do we want to do this? Here's a batch of conversions that shouldn't > >> >> >> conflict much with in-flight patches. > >> >> >> > >> >> >> The trouble with mixed use is that it's inconsistent, and any remaining C99 > >> >> >> types will encourage their use. We could at least do the low hanging fruit? > >> >> > > >> >> > Ack from me. Doesn't seem so big to cause much pain. > >> >> > > >> >> > When you say low-hanging fruit, that implies you only dealt with a > >> >> > particular class of occurrences? > >> >> > >> >> I meant the files which don't have massive amounts of C99 types and > >> >> aren't under active development right now. I just wanted to avoid > >> >> trouble for starters. ;) > >> > > >> > If using kernel types is where we want to go (which I agree with), > >> > maybe it would be better to have a single conversion rather than > >> > several small ones as we are doing with dev_priv -> i915? This allows > >> > in-flight-but-not-yet-sent patches to easily keep up with the changes > >> > rather than conflicting every other rebase. > >> > >> I'm thinking we can do a lot of changes without conflicting anything or > >> very little. At least for starters before the sudden ripping off the > >> band-aid. > > > > I'm with Lucas. I'd prefer one single massive move than many small ones. > > Easier for the internal maintenance. We fix it only once and not one per > > day for months and months like dev_priv/i915 case. > > For everything else, I believe smaller patches are easier. For example, > who is going to review the massive change? Halt everything until it's > reviewed and merged? For merge conflicts I think git can do a better job > of managing the rerere with piecemeal changes. Internal is not the only > consideration. I'm somewhere in the middle, but I have to agree changing everything with one patch would be bit too overwhelming for review. Regards, Joonas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
