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

[Deny Dias]

Hi there,

I'm just a powerless, yet happy, pass user. I'm glad to see this matter getting some attention and that's why I feel the need to reply on this thread.

We're in 2015 A.D. We have DVCS and people feeling the need to get involved with things they like|use. I see no point on relying in such an old, hard to scale process like sending patches to a mailing list.

I say that being one tied to traditions myself: I'm a Slackware user.

Best wishes,

Deny Dias.

Em qui 23 abr 2015, às 09:37:20, Mike Charlton escreveu:
> 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
> >