[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

[Antoni Mylka]

Roberto Guido pisze:
> 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.

Every decision making process involving more than one person is better
than done by a single one.

> 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.

In my case change is not 'equivalent' to an API break, it IS an API
break. I generate classes from an ontology, so if something is removed -
 a field disappears from a class. If the domain or range of a property
is changed, suddenly the RDF I create doesn't validate anymore and I get
test failures.

I know that we need change if we want to move forward, I just think that
we should make it really clear what changes are made and when.

> 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?)

Oscaf trac already has a timeline RSS feed that contains the "ticket
created" and "ticket closed" events. It can be filtered. If you want a
feed only with "ticket opened/closed" events, than the url is:

https://sourceforge.net/apps/trac/oscaf/timeline?ticket=on&max=50&daysback=90&format=rss

And +1 for the mandatory patch. This is going to make many discussions
much easier.

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

there is hardly any third 'alternative' option to (accepted || refused)
:). I think the alternative is between

- no commit until accepted - wait indefinitely until someone else
bothers to have a look (IMHO the better option), at least two pairs of
eyes for each change. Something like the policy in the Kernel source,
that every patch is signed off by more than one person. That would be
overkill for us, in general an "OK" from someone who is not me should be
a minimum.
- if no objections made within a week - accept and commit - potentially
faster but less dangerous, I'd rather not do it.

> 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.

That's nice. I think that adding some actual duties to the 'maintainer'
post might not be a bad idea.

Antoni Mylka
antoni.mylka at gmail.com