On Mon, 27 Jun 2016, Jafar Al-Gharaibeh wrote:
I was hoping you were singled out Lou! so that the wider community
feels better that they are not the target audience! ;)
Well, you've drawn the fire now. ;)
We keep rinsing and repeating, we should move to the drying phase. ;)
Well, we were forward-caught-up and keeping up with that process by
November last year or so. So...
I don't quite see how then not doing any integration work - beyond
minimal bug-fixes - and patches again left at the side, is an
improvement.
The whole point of having document/documents to describe the current
situation is to avoid having to spent a lot of time looking through the list
to piece together an incomplete picture of the current situation.
What is unclear - for a contributor - at the moment? E.g.:
http://git.savannah.gnu.org/cgit/quagga.git/tree/HACKING.md
PATCH SUBMISSION {#sec:patch-submission}
================
- For complex changes, contributors are strongly encouraged to first
start a design discussion on the quagga-dev list *before* starting
any coding.
- Send a clean diff against the ’master’ branch of the quagga.git
repository, in unified diff format, preferably with the ’-p’
argument to show C function affected by any chunk, and with the -w
and -b arguments to minimise changes. E.g:
git diff -up mybranch..remotes/quagga.net/master
<etc>
Also, there are sections on commit mesages and what not. It's not
explicitly spelled out that "send" means "to the quagga-dev" list, but
perhaps that's obvious. The devel page on the website is explicit
though:
http://www.nongnu.org/quagga/devel.html
"Bug fixes, features and patches in general are most welcome. Please
send them to the Quagga development list (note you probably will need to
subscribe first). <etc>" (with a hyper-link to the mailman page).
Could HACKING be cleaned up. Sure. Maybe even split into 1 for
contributors and 1 for administrative stuff.
Does writing a document from scratch, and not even bothering to look at
existing stuff, help much? Does it help to produce a new document that
as a result, in a number of areas, is "same but different"? I'm not
sure...
It certainly does send a message to those who put time into writing the
prior stuff though.
> > - Contributors can game (consciously or not) things by simply ignoring
> > comments for nearly 2 years, then rally others to vote in their
> > changes en bloc with talk about how the development process is
> > broken,
> > _failing to mention_ how they helped break it.
> I agree this is wrong.
That's what's annoying me the most.
That is wrong.
I'm glad Lou and you agree with me on that.
But I claim that this is not easy to do. I count on the sensibility of
other contributors and the larger community to stop such actions.
Except, this is exactly what is happening.
This is what the Maintainers document is about.
Brilliant. I look forward to the diffs to HACKING.md.
I also don't like the "Quexit" path! I don't appreciate this whole
"exit" wave! ...., I think we cab build a better inclusive, successful
and vibrant Quagga together... but that is just an opinion.
Hey, my vote was and is for "Remain".
regards,
--
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
"Don't tell me I'm burning the candle at both ends -- tell me where to
get more wax!!"
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
