Hello Paul
Le 27/04/2016 15:33, Paul Jakma a écrit :
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.
I also used bugzilla or equivalent (we used internally the Tuleap forge
which provide bug tracker system). What is mandatory is to configure
bugzilla to automatically put the quagga mailing list in Cc of all
exchange in order to let everybody in touch with the evolution of the patch.
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..
Why not simply used the bug / patch tracker provided by savannah as
Quagga is hosted on it ? I look briefly to other projects hosted by
savannah that used but and patch tracker. It seems that the tracker
system answer to your requirement. In addition, activate it is only 2 or
3 mouse clicks ;-)
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.
Well, I reformulate. I used git commit -s to produce the patch with git
format-patch. Agree that SOB is not sufficient. What I mean is, in case
of large patch, in how many piece-it must be cut out ? i.e. what is the
maximum size of a patch (in term of numbers of modification, files,
lines ...) ?
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.
From what I already see in the header of Quagga files, there is
copyright mention. In conformity to our internal policy, I also add our
copyright on the different files I created or where largely modified.
This clearly indicate from where the contribution come from.
In addition, updating the documentation accordingly to the proposal
modification should be also the rules.
regards,
Regards,
Olivier
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
