Hi Olivier,
On Mon, 25 Apr 2016, Olivier Dugeon wrote:
As propose before, Gerrit could be a good candidate. You could send
easily your patch to gerrit for contributors, and for reviewers easily
review the code.
With Gerrit many maintainers / reviewers could check the patch and add
a '+1' to the request. You could add easily simple 'code reviewer'
people who don't need to take also a maintainer role that could afraid
some of them.
Yes agree. Again, as with Gerrit you could amend a patch, the process
will be easier avoiding to rebuild entirely the patch.
So, Gerrit is something that provides the type of "meta-patch-tracking"
functionality that we desperately need. It would be very useful to have
a tool which:
- Provided a canonical ID for a contribution, that allowed the
contribution to still be updated (git IDs change as the content
changes)
- Allowed comments to be made and tracked
- Allowed status to be tracked
I interact with Gerrit sometimes on another project. It is a bit
over-powering though. You have to fit into its work-flow. Also, the
web-UI is a bit annoying at times. E.g., it is hard to follow comments
sometimes.
In an ideal world, I'd find something better. Ideally, something not as
tightly coupled to the git workflow, so that we'd still have flexibility
there.
One possibility is good old bugzilla. There are tools out there now to
make it easy to apply/send/update patches in bugzilla bugs from the
commandline in a git repo.
Sometimes I wonder if there wouldn't be a way to make git do the job
somehow. Keep bug state in the git repo, in distinct namespace and heads
from the code. Somehow..
Yes agree. Perhaps some rules could be added in the Hacking.txt. For
example, maximum modified lines/files per patch ... to help
contributor to split their patch
Updates to HACKING.md always useful. There is a section there on COMMIT
MESSAGES.
People seem to hate writing them, but:
- A good commit message helps answer reviewers' questions before they
even have to ask. Which can smooth the path of a patch.
- A good commit message helps to 'sell' the patch, and make others
/want/ to apply to it. I.e. it answers the question "Why should I care
about this, and not just dismiss it as churn?"
(i.e. how many 'git commit -s' are necessary).
For me, 0. As discussed before, it seems to be overloaded and not
meaningful. It certainly has no meaning to me - indeed, in some cases
SOB lines can make me /suspicious/ of a patch. And I am sure that how
others have used it with Quagga has rendered it meaningless here.
Hence:
http://patchwork.quagga.net/patch/1801/
If you think there is some useful information that a "SOB" gives that
you want others to perceive, then just write it in _plain english_.
If there were stuff we really _needed_ people to indicate their
agreement with, then that would need to be done in a clear, meaningful
way (or it would be worthless). E.g., perhaps by having a document in
git and requiring contributors submit a patch to add their name/mark/id
in some way.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Automobile, n.:
A four-wheeled vehicle that runs up hills and down pedestrians.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
