[Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless

[Evgeny Egorochkin]

В сообщении от Среда 18 ноября 2009 00:12:03 автор Roberto Guido написал:
> On Tue, 2009-11-17 at 20:57 +0100, Leo Sauermann wrote:
> > I don't have to remind you that this is how open source patching
> > works,
> > and that patches have the great property that there can be a "yes/no"
> > vote on accepting them,
> > and moving on with life.
> 
> I agree the requirement of a mandatory patch attached to each ticket,
> but not the decision making process.
> 
> Code patches are in most situations easily evaluable: it works / it
> doesn't works. Patches to an abstract model (the ontology) has same
> probability to be good or bad depending on who evaluate it, and who is
> involved in discussion.
> A change is equivalent to an API break: it is easy to strip a function
> from the code, but may have dramatic conseguences on existing
> implementations which use that.

Form my experience, it's almost impossible to come up with a working patch 
when suggesting something significant and especially when requesting a feature.

There are often lots of possible ways to implement something and without the 
initial discussion, you get a 95% useless patch, especially if you aren't a 
core developer.

For more comments read my reply to Leo.

> My alternative:
> - mandatory patch
> - notification of all people designed for maintainance and those who
> have interest about the Nepomuk effort (is it possible to populate an
> RSS or send a mail to a list when a new ticket is added in the tracker?)

Having a mailing list with some notifications is a good idea indeed.

> - if no comments arrive within a week the patch is accepted/refused,
> otherwise... Well, I have no alternative for this.

This works only for trivial patches which require fast resolution. We have a 
milestone: good idea for later for a reason.

> Perhaps some constraint about timing may help in discard excessively
> slow procedures ("the maintainer must take a decision when no one add
> comments for at least one week, evaluating the modification and all
> clearly expressed positions"), but I'm not sure about this.

The current policy is:

"Ontology maintainers are responsible for ensuring that decisions meet 
consensus criteria. This means either: 
* Waiting long enough for all parties involved to either comment or ignore the 
issue(considered an abstention). 
* Contacting all affected parties to obtain either their comment, confirm their 
abstention or to set a deadline for them to express their opinion. As a 
consequence of being responsible, commits to the repository need a maintainer 
approval."

The only obvious  fix would be to clarify "waiting long enough". At this moment 
this vague phrase probably means a couple of months.

The implications of the fix would probably be: milestones and priorities 
influence what maintainers do first; maintainers can politely "demand" affected 
parties to cooperate on the current issues.

-- Evgeny