16 Jun
2012
16 Jun
'12
9:59 p.m.
On Sat, Jun 16, 2012 at 11:51 PM, Pablo Neira Ayuso <pablo(a)gnumonks.org> wrote:
On Sat, Jun 16, 2012 at 10:25:41AM +0200, Holger Hans
Peter Freyther wrote:
Yes, I think it's too much overhead in our case. But thank you for the
link anyway - the tool looks interesting.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
On Sat, Jun 16, 2012 at 11:33:54AM +0400,
Alexander Chemeris wrote:
Don't know if this is exactly what you need, I've been using
"patchwork" for some time:
http://ozlabs.org/~jk/projects/patchwork/
It's relatively easy to deploy and it provides a list of pending
patches.
It's being used by several FOSS projects regarding Linux:
http://patchwork.ozlabs.org/
In general, I think it's a good practise to send patches first to the
mailing list for review before committing them in projects. If nobody
complains, apply it. It also forces you to produce good patchsets, ie.
contributions splitted into logical pieces with good changelog
descriptions that people can track.
This can probably be too much overhead if the amount of people
contributing to this is relatively small and the amount of contributed
changes is relatively. Hi Harald,
Hi,
Could we setup a commit mailing list to know when someone commits?
And is an ability to make commit reviews, like in Google Code or github?
so far the amount of external patches were always so low that reviewing
them on the mailinglist were okay. I would propose we do the same for the
PCU. In case this doesn't scale we can introduce a Gerrit.
does it make sense?