[pass] Finding a way to accept patches (Re: Patch: Do not depend on verbose flags in Makefile)

Mike Charlton mikekchar at gmail.com
Thu Apr 23 02:37:20 CEST 2015


Sorry for the slow response.  I was hoping some more people would chip in
;-)  Possibly they didn't notice the discussion due to the unrelated
subject line.  I have fixed that now :-)

I can understand that it is kind of an embarrassing situation.  How many
patches are still waiting to be reviewed?  It is kind of unfortunate that
the patch request mechanism is this list since it makes it difficult to
find all the patches.   Mailman seems to lack a frontend for searching the
entire archive (I was sure I saw one one time, but I can't seem to figure
it out at the moment).

Anyway, pass is an important project for me.  Although I'm not planning to
do any development on it in the near future, I'm worried that the lack of a
place for people to submit patches will ultimately drive people away.

I have noticed that Jason has some activity on Github in the recent past,
so he is not without access to the internet.  If anyone personally knows
him, I wonder if they wouldn't mind pinging him to see if he has any
objection to delegating some authority for accepting patches, at least into
a separate branch.  Failing that, I noticed that you, Lenz, have merged
code before so I assume you have the ability to create a new branch and
merge into it.  The "checked by 3 people" seems like a reasonably high
level to aspire to.  I promise, for my part, to review any patches that are
sent in.

On 18 April 2015 at 16:03, Lenz Weber <mail at lenzw.de> wrote:

> Yes, I've been thinking about something like that for a while now, too.
>
> Problem is, while it would be easy to add smaller patches & fixes (and
> it would prove a very valuable tool for that), decisions that would add
> code refactorings would have to be controlled thoroughly, if added at
> all - the same for patches that add real new functionality (new command
> line switches), or that changes the behaviour of pass.
>
> Something like that would need a "checked thoroughly by three people on
> the mailing list and deemed as useful"-approach or something..?
>
> On 18.04.2015 04:51, Mike Charlton wrote:
> > On 17 April 2015 at 15:55, Dahlberg, David
> > <david.dahlberg at fkie.fraunhofer.de
> > <mailto:david.dahlberg at fkie.fraunhofer.de>> wrote:
> >
> >     I'd pretty much like to get some comments (or better a commit) about
> >     this patch that I posted onto the list a while ago, so that I could
> >     proceed with the rest that is already waiting.
> >
> >
> > This seems to be a bit of a common pattern (with some people waiting the
> > better part of a year to get a patch in).  While I can understand that
> > life can take you away from a project (I haven't updated some of the
> > projects I maintain in a couple of years) I worry that people will walk
> > away from this gem of a project.
> >
> > Can I suggest adding a branch to the git repository (maybe called
> > staging or something) where people can submit changes without having to
> > wait for the maintainer's approval.  The active members of the list can
> > review the code and make suggestions so that work isn't stalled unduly.
> > Then when the maintainer feels like he has the capacity to review what
> > has happened he can cherry pick from staging at will.
> >
> > The upside of this scheme is that those of us who wish to use the
> > features that are coming as patches will be able to do so easily by
> > simply using the staging branch.  The downside is that if the maintainer
> > doesn't come back, it could possibly lead to a fork (although if people
> > get too annoyed they might just fork anyway).
> >
> > Just a thought...
> >
> >
> > _______________________________________________
> > Password-Store mailing list
> > Password-Store at lists.zx2c4.com
> > http://lists.zx2c4.com/mailman/listinfo/password-store
> >
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20150423/b80121ef/attachment.html>


More information about the Password-Store mailing list