On 21/02/13 18:41, Rob Vesse wrote:
I have added a page to the website on this - see
http://jena.apache.org/getting_involved/reviewing_contributions.html
Cool - maybe
(not on a machine setup for on the site ... "semi" connected currently)
"developers will be looking for when reviewing contributions."
==>
"comitters will be looking for when reviewing contributions."
Typo: "Is is contributed to Apache?"
==>
"Is it contributed to Apache?"
I have tried to get this included in the sidebar navigation but I can't
figure out how that works, anyone able to fix this?
Were you changing ia.txt? Isn't that just documentation about the site
structure, not the content? Good to keep that up to date.
The site is driven from templates/ IIRC, is it sidenav.mdtext?
I'm not sure though - try out on staging first!
Andy
Rob
On 2/8/13 12:46 AM, "Andy Seaborne" <[email protected]> wrote:
One follow-up:
There are two TLA that float around
CTR - commit then review
RTC - review then commit
for two styles of operation of a project
CTR is commit (to the main codebase) and have people check it afterwards
- a sort of passive agreement process. Jena is more this style. It
works for small projects when enough people can have an overview of the
whole thing; it's lighter weight, the level of analysis is typically
less but eyeballing changes is possible. Having a test suite is
essential, creating a off trunk version to check is not. It does not
work so well for large additions. It is short-timescale.
RTC is review (on JIRA or git pull requests), agree then integrate into
the main code base. Used on large projects (e.g. the Hadoops of this
world) where many areas can be active at once. It is higher overhead
but necessary when the complexity of the code base means things need to
be checked in detail, often by building and running e.g. performance.
It has a lot longer cycle time.
As a small project (and in the scheme of things, Jena is small) we can
choose lighter weight processes and also vary the process to suit on
each item. Small patches can be just do it, things that change
functionality can be brought to dev@. Your judgement.
Rob's excellent list applies.
We ought to be fairly systematic on asking for tests both for bug
reports and contributions. We seem to get waves of "it does not work
messages" and it takes inspired guesswork (well, random guesswork) to
see what might be going wrong.
Andy
