On Thu, 24 Oct 2019 15:33:04 +0200 Dmitry Vyukov <dvyu...@google.com> wrote:
> On Thu, Oct 24, 2019 at 3:15 PM Steven Rostedt <rost...@goodmis.org> wrote: > > > > On Mon, 21 Oct 2019 18:39:18 +0300 > > Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > > Purely theoretically let's consider that the changes do not improve > _your_ efficiency, but they significantly improve overall project > efficiency by positively affecting people who did not develop a > workflow over the past decades (maybe there were not around 2 decades > ago) and positively affecting various tooling that _you_ may be > directly interested in, but otherwise they are important for the > project overall. So for you it's no change in efficiency except that > you now need to do things differently. What do you think about such > changes? Are you ready to force yourself? :) > I think it's quite cornerstone question here. All (?) major figures in > the kernel (who are ~~98% of decision making, but ~~2% of kernel > developers overall) have developed workflows over the past decades > that work reasonably well for them. If they veto all proposed changes > based on the criteria you described, every new contributor will need > decades to develop own workflows to become an efficient contributor > and lots of tooling will be painfully hard to do. > The above sound like a one size fits all approach, which I would caste a veto to. I would like a solution that works for multiple workflows. One where mine and others still work too. Please, lets work on a infrastructure that is robust and flexible, that is split into back and front ends. That way, we have a single "back end" and multiple front ends that suite everyone's needs. -- Steve _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
