On Thu, Oct 24, 2019 at 3:15 PM Steven Rostedt wrote:
>
> On Mon, 21 Oct 2019 18:39:18 +0300
> Laurent Pinchart wrote:
>
> > > I plan on continuing to develop mostly in email (I still send my patch
> > > series via quilt!). But I'm not going to enforce everyone to continue
> > > to use email if we can come up with a better way. I also want to make
> > > sure that whatever we do come up with will still support email.
> >
> > Hypothetically speaking, if there was a service that allowed sending a
> > patch series through a git push with a tag containing a cover letter in
> > its message, and that service would send out e-mails to mailing lists
> > (with the option to self-host it if you want), would you consider using
> > it ?
>
> Only if I was forced to ;-)
>
> Seriously, it's hard to teach an old dog new tricks. I wont change
> until it becomes necessary to do so. As the old saying goes: "Don't fix
> what ain't broke!"
>
> I've developed a workflow over the past decade or so, that I've
> optimized to fit my needs. Why would I want to change that? Unless
> there's something that changes that can make an impact on my
> efficiency.
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.
>I've created a bunch of scripts that do exactly what I
> expect them to. To change, I'm going back into the world of the unknown,
> and will need to take up time (which I'm struggling to come up with),
> to learn something new that may or may not make it better for me.
>
> The tool I would like is simply something where all the patches I
> receive are stored in a nice formatted database that I can process
> offline somewhere (like when I'm flying to Europe).
>
> Right now I hacked an old version of patchwork (when I upgraded,
> everything broke, and I had to revert it), along with procmail, that
> creates a local patchwork queue I can access locally. Unfortunately,
> this doesn't work when I'm away from home without an internet
> connection.
>
> I would love to be able to take this database with me and process the
> patches while traveling without connectivity.
>
> -- Steve
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
