Re: Is it time to drop ChangeLogs?

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: address@hidden,  address@hidden
> Date: Thu, 07 Jul 2016 18:24:10 +0100
> 
> First, we do not have a system for managing PRs/patches in the
> queue. So, it's possible that people with outstanding patches are
> not busier than you, they just missed things.

I just read the bug list and manage my email queue.  How hard can that
be?

> Secondly, in terms of pushing patches for someone else, this doesn't
> need to be harder than reviewing the patch and signaling that you are
> happy. Many PR management systems will do the merge after "LGTM".

Problem is, I don't find the subtle fine points that need addressing
until I actually apply the patch: compiler warnings, code not
according to our conventions, sometimes patch won't apply, etc.

> I look at this the other way around. I think we are likely to get more
> developers, if it is easier to contribute.

I think we've already done a lot in that direction, and I don't see
how can we be expected to do more.  All the other projects I
participate in make it harder, and yet no one complains or thinks they
are hard on contributors.

> A project where you can send in a patch, and have some one give you
> feedback on it, will end up with more developers.

Which is exactly what I said, and you objected.  So now I'm confused
what we are arguing about.

> >> We would still need to do something about the Emacs git, in terms of
> >> squashability; in practice, this would probably require something
> >> like gitolite as allowing non-FF pushes on all branches would be a
> >> bad thing.
> >
> > I don't really see a problem.  Why doesn't a feature branch or a
> > scratch branch solve all of this nicely and easily?
> 
> I think I have discussed this with you before. You have to create
> multiple feature branches, or do strange things, rather than just
> rebase, force push.

What's the problem with multiple branches?  It's a very easy
technique, and also very safe.