Re: Is it time to drop ChangeLogs?

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:
> Starting a PR system in the current conditions is just going to
> _increase_ the workload of the few overloaded people.  E.g., I don't
> want to push changes for anyone else, ever: it takes too much of the
> little time I have to work on Emacs. I want this burden off-loaded to
> someone else.  Guess what? patches that I said were okay can rot for
> many days without anyone with write access doing anything.  I can only
> conclude they all are as busy as I am or busier.  As long as this is
> the situation, how could a PR system help, when it requires me to do
> _more_ than I have to now?

I think in two ways. 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.

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".


>> Perhaps, as a half way house, we could use the resources that we have.
>> PRs could go to the bug reporting system. This will, at least, keep all
>> the conversations in one place. If we can tag these with "has patch"
>> here as well, it will give an queue also.
>
> We already try doing that, as much as we can.  Fortunately, a few
> people lately started actively reviewing bug reports, both old and
> new, and post analyzes, tag them, propose patches, etc.  That's great,
> but we need more of them, and we need to wait for them to gain enough
> knowledge and experience to be able to overlook larger portions of
> Emacs (including the parts written in C, btw).  This should be the
> main vector of our process improvement, at least for some time to
> come.  Because nothing more substantial can happen until we have a
> critical mass of active maintainers.

I look at this the other way around. I think we are likely to get more
developers, if it is easier to contribute. A project where you can send
in a patch, and have some one give you feedback on it, will end up with
more developers.


>> 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.

Phil