kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Jean-Pierre and others who commit:


I think its becoming essential that we improve our patch management
procedures, and until we start using the merge request manager, I think
these procedures are even more important while we work with them on the
mailing list.  After we start using the merge request manager, then we
can evolve to another hopefully less elaborate usage of the mailing
list.  Until then we need to make better use of the mailing list than we
are.

The goal here is to save developer time and to give the submitter better
feedback.


1)))))))))))

For starters, can we agree to reply to the mailing list when a patch is
committed?  This saves time of somebody else that might be spending time
getting ready to commit that same patch. 


The commit message should look something like this one, and tells the
others that they should not waste valuable time.

Example:

    https://lists.launchpad.net/kicad-developers/msg04977.html


This *may* not be necessary once we start using the merge request
manager/queue, but at least until then it is very important.

In fact, I'd even ask that we go back a week and do this retroactively
for patches that were committed so I know where not to spend time. 


2)))))))))))

Can we object to a patch in clear language so that some other would be
committer knows not to commit until some objection is resolved.  "Hold
on committing until...".  Or "Do not commit", or "Should never commit..
because", or "Willing to commit if nobody else objects..."


)))))))))))))


I have been willing to do some of this work, and have left patches on
the list for others to comment on before committing them for a couple of
days.  But this can only work if we are communicating optimally and
better than we are.

We are seeing where using only a mailing list for this is causing us
more work, but let's do the work please.


Thanks,

Dick