Wide consensus (was: Re: How to name things with URIs)

[Tommaso Teofili <to...@gmail.com>]

Guys,

I think we do need to have wider consensus before making any important
change (like this naming of graphs); I admit I failed to look after all the
messages, commits, issues sent/opened regarding this naming task and it's
probably my fault on that but what I'd like to share with you is my feeling
that we sometimes go too much quickly on committing changes.
We shouldn't commit anything that is still being discussed in order to make
the best approaches and choices happen or we'd end up -1ing or even
reverting things too much often.
I don't mean we should vote every change but at least, for important changes
(API, architecture, design), consider someone could've built products/other
projects on Clerezza and, most important, that another dev/committer could
come with a better approach than mine we, at least, should discuss.
So, in the end, I don't want to blame anyone, just let you know my point of
view and feeling about the latest issues.
My 2 cents,
Tommaso


2011/5/13 Reto Bachmann-Gmuer <re...@trialox.org>

> Use tha mialing lits for questions you encourage a broad discussiuon,
> post a question-issue if you just would like to have an answer. I
> appreciate brain-storming issues, but here its about changes in the
> code. You're recent renaming of graphs caused some problems (e.g. my
> wall application no longer worked), so I wanted to try to get a
> consuns on the name to choose. Now I have you -1 but no alternative
> proposal.
>
> Reto
>
>
>
> On Fri, May 13, 2011 at 2:37 PM, Henry Story <he...@bblfish.net>
> wrote:
> > Why are you having this debate on the mailing list? There are a number of
> > bug reports where
> > this issue has already been discussed?
> > For example:
> > https://issues.apache.org/jira/browse/CLEREZZA-489
> > And there were a number of other bugs that are duplicates of it:
> > CLEREZZA-470 and  CLEREZZA-463.
> > I just want to know when we are meant to use the mailing list and when
> the
> > issue
> > database.
> >
> >
> >
> > On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote:
> >
> > ----- Original message -----
> >>
> >> On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
> >>
> >> >
> >> > For cached graphs I suggest to have uirs like:
> >> >
> >> > urn:x-localinstance:/cache/<remote-uri>
> >>
> >> -1
> >>
> >> Should each user who makes a request not get a different remote graph?
> >
> > No, this would increase complexity too much. What is in the cache depens
> > solely on the platform instance. If a user want to retrieve something
> with
> > her identity she cannot use webproxy.
> >
> >
> >
> >
> >> Because what if a remote instance returns different graphs to different
> >> users for the same resource?
> >>
> >> Btw, I also opened this discussion in CLEREZZA-489 [1]
> >>
> >> My guess is that the graph management should hide all of this from the
> >> user.
> >>
> >> The user should ask for relative graphs if he wants local ones.
> > Which is a direct access to the cache graph, which is consitent with my
> > proposal above.
> >
> >>
> >> Then if he wants remote graphs he should use the name of the remote
> >> graph he wishes to get. How that remote graph is named interally is not
> >> really important.
> > Which somehow contrasts your -1 above.
> >
> >> If the fetch is done over TCP without cookies or
> >> headers, then presumably all users of the server can view that graph
> >> equally. If fetching the remote graph requires authentication, then the
> >> graph will be in part determined by who fetched it.
> >>
> >> In the end these graphs should probably just be blank nodes, with
> >> descriptors of how they were fetched.
> > Yes, i a perfect world we have bracketing rdf stores so that graphs can
> be
> > anonymously within others. But till then we need a key (name) for our
> named
> > graph store.
> >
> > If you want to stick to your -1, could you popose an alternative?
> >
> > I really want to do some tidying in the proxy code.
> >
> > Cheers,
> > reto
> >>
> >> Henry
> >>
> >> [1] https://issues.apache.org/jira/browse/
> >>
> >> Social Web Architect
> >> http://bblfish.net/
> >>
> >
> >
> > Social Web Architect
> > http://bblfish.net/
> >
>

Re: Wide consensus (was: Re: How to name things with URIs)

[Henry Story <he...@bblfish.net>]

On 13 May 2011, at 15:24, Reto Bachmann-Gmuer wrote:

> I agree, but I would replace "committing changes" with "committing
> changes to trunk" in your text.
> 
> I'm now having a process issue with the WebProxy, locally did some
> changes added documentation to public methods and other first steps of
> a renicing. opened an issue (CLEREZZA-525)

cool. you opened this today

> for this but now noticed
> the original issue CLEREZZA-463 isn't closed yet.

It was closed  two days ago, and should probably have been closed a lot
longer ago. It is difficult to know when to close issues like this
as that was a completely new component I added.

> So I guess rather
> than refactoring with an own issue I should reopen CLEREZZA-463.

Ah so it is closed :-)

No don't open re-open it. That issue was too broad. It could not really
ever be closed. 

Mind you your issue CLEREZZA-525 is pretty unspecific too
It says only
"The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes."
 

> But
> judging from all the places in the code I had to adapt to the API
> changes there are many undeclared dependencies on ZZ-463. This shows
> the problem of issues being in resolved state for a long time.

A component like WebProxy cannot be finished. An initial version was added
to clerezza. It works, but there is a lot of room for improvement. The point
of adding it was so that people could try to use it and then send feedback
so that it could be improved. 

> I think as an incentive to actually get issues closed[1] we might
> introduce the rule that nothing gets into trunk that depends on an
> issue that isn't closed yet. I.e. you may still commit directly to
> trunk while resolving an issue, but you must close all other issues
> your code depends on - or commit your code to an issue branch.

Well as an informal rule, why not. Ask people to close their issues is a good 
idea. Helping people out is also cool. And feedback is appreciated.



> 
> Cheers,
> Reto
> 
> 1. Currently there's a negative incentive to close other people's
> issues, because if then there's a -1 the person closing the issue is
> responsible for the changes being reverted.
> 
> On Fri, May 13, 2011 at 3:09 PM, Tommaso Teofili
> <to...@gmail.com> wrote:
>> Guys,
>> 
>> I think we do need to have wider consensus before making any important
>> change (like this naming of graphs); I admit I failed to look after all the
>> messages, commits, issues sent/opened regarding this naming task and it's
>> probably my fault on that but what I'd like to share with you is my feeling
>> that we sometimes go too much quickly on committing changes.
>> We shouldn't commit anything that is still being discussed in order to make
>> the best approaches and choices happen or we'd end up -1ing or even
>> reverting things too much often.
>> I don't mean we should vote every change but at least, for important changes
>> (API, architecture, design), consider someone could've built products/other
>> projects on Clerezza and, most important, that another dev/committer could
>> come with a better approach than mine we, at least, should discuss.
>> So, in the end, I don't want to blame anyone, just let you know my point of
>> view and feeling about the latest issues.
>> My 2 cents,
>> Tommaso
>> 
>> 
>> 2011/5/13 Reto Bachmann-Gmuer <re...@trialox.org>
>> 
>>> Use tha mialing lits for questions you encourage a broad discussiuon,
>>> post a question-issue if you just would like to have an answer. I
>>> appreciate brain-storming issues, but here its about changes in the
>>> code. You're recent renaming of graphs caused some problems (e.g. my
>>> wall application no longer worked), so I wanted to try to get a
>>> consuns on the name to choose. Now I have you -1 but no alternative
>>> proposal.
>>> 
>>> Reto
>>> 
>>> 
>>> 
>>> On Fri, May 13, 2011 at 2:37 PM, Henry Story <he...@bblfish.net>
>>> wrote:
>>>> Why are you having this debate on the mailing list? There are a number of
>>>> bug reports where
>>>> this issue has already been discussed?
>>>> For example:
>>>> https://issues.apache.org/jira/browse/CLEREZZA-489
>>>> And there were a number of other bugs that are duplicates of it:
>>>> CLEREZZA-470 and  CLEREZZA-463.
>>>> I just want to know when we are meant to use the mailing list and when
>>> the
>>>> issue
>>>> database.
>>>> 
>>>> 
>>>> 
>>>> On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote:
>>>> 
>>>> ----- Original message -----
>>>>> 
>>>>> On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
>>>>> 
>>>>>> 
>>>>>> For cached graphs I suggest to have uirs like:
>>>>>> 
>>>>>> urn:x-localinstance:/cache/<remote-uri>
>>>>> 
>>>>> -1
>>>>> 
>>>>> Should each user who makes a request not get a different remote graph?
>>>> 
>>>> No, this would increase complexity too much. What is in the cache depens
>>>> solely on the platform instance. If a user want to retrieve something
>>> with
>>>> her identity she cannot use webproxy.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Because what if a remote instance returns different graphs to different
>>>>> users for the same resource?
>>>>> 
>>>>> Btw, I also opened this discussion in CLEREZZA-489 [1]
>>>>> 
>>>>> My guess is that the graph management should hide all of this from the
>>>>> user.
>>>>> 
>>>>> The user should ask for relative graphs if he wants local ones.
>>>> Which is a direct access to the cache graph, which is consitent with my
>>>> proposal above.
>>>> 
>>>>> 
>>>>> Then if he wants remote graphs he should use the name of the remote
>>>>> graph he wishes to get. How that remote graph is named interally is not
>>>>> really important.
>>>> Which somehow contrasts your -1 above.
>>>> 
>>>>> If the fetch is done over TCP without cookies or
>>>>> headers, then presumably all users of the server can view that graph
>>>>> equally. If fetching the remote graph requires authentication, then the
>>>>> graph will be in part determined by who fetched it.
>>>>> 
>>>>> In the end these graphs should probably just be blank nodes, with
>>>>> descriptors of how they were fetched.
>>>> Yes, i a perfect world we have bracketing rdf stores so that graphs can
>>> be
>>>> anonymously within others. But till then we need a key (name) for our
>>> named
>>>> graph store.
>>>> 
>>>> If you want to stick to your -1, could you popose an alternative?
>>>> 
>>>> I really want to do some tidying in the proxy code.
>>>> 
>>>> Cheers,
>>>> reto
>>>>> 
>>>>> Henry
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/
>>>>> 
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>> 
>>>> 
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>> 
>> 

Social Web Architect
http://bblfish.net/

Re: Wide consensus (was: Re: How to name things with URIs)

[Reto Bachmann-Gmuer <re...@trialox.org>]

I agree, but I would replace "committing changes" with "committing
changes to trunk" in your text.

I'm now having a process issue with the WebProxy, locally did some
changes added documentation to public methods and other first steps of
a renicing. opened an issue (CLEREZZA-525) for this but now noticed
the original issue CLEREZZA-463 isn't closed yet. So I guess rather
than refactoring with an own issue I should reopen CLEREZZA-463. But
judging from all the places in the code I had to adapt to the API
changes there are many undeclared dependencies on ZZ-463. This shows
the problem of issues being in resolved state for a long time.

I think as an incentive to actually get issues closed[1] we might
introduce the rule that nothing gets into trunk that depends on an
issue that isn't closed yet. I.e. you may still commit directly to
trunk while resolving an issue, but you must close all other issues
your code depends on - or commit your code to an issue branch.

Cheers,
Reto

1. Currently there's a negative incentive to close other people's
issues, because if then there's a -1 the person closing the issue is
responsible for the changes being reverted.

On Fri, May 13, 2011 at 3:09 PM, Tommaso Teofili
<to...@gmail.com> wrote:
> Guys,
>
> I think we do need to have wider consensus before making any important
> change (like this naming of graphs); I admit I failed to look after all the
> messages, commits, issues sent/opened regarding this naming task and it's
> probably my fault on that but what I'd like to share with you is my feeling
> that we sometimes go too much quickly on committing changes.
> We shouldn't commit anything that is still being discussed in order to make
> the best approaches and choices happen or we'd end up -1ing or even
> reverting things too much often.
> I don't mean we should vote every change but at least, for important changes
> (API, architecture, design), consider someone could've built products/other
> projects on Clerezza and, most important, that another dev/committer could
> come with a better approach than mine we, at least, should discuss.
> So, in the end, I don't want to blame anyone, just let you know my point of
> view and feeling about the latest issues.
> My 2 cents,
> Tommaso
>
>
> 2011/5/13 Reto Bachmann-Gmuer <re...@trialox.org>
>
>> Use tha mialing lits for questions you encourage a broad discussiuon,
>> post a question-issue if you just would like to have an answer. I
>> appreciate brain-storming issues, but here its about changes in the
>> code. You're recent renaming of graphs caused some problems (e.g. my
>> wall application no longer worked), so I wanted to try to get a
>> consuns on the name to choose. Now I have you -1 but no alternative
>> proposal.
>>
>> Reto
>>
>>
>>
>> On Fri, May 13, 2011 at 2:37 PM, Henry Story <he...@bblfish.net>
>> wrote:
>> > Why are you having this debate on the mailing list? There are a number of
>> > bug reports where
>> > this issue has already been discussed?
>> > For example:
>> > https://issues.apache.org/jira/browse/CLEREZZA-489
>> > And there were a number of other bugs that are duplicates of it:
>> > CLEREZZA-470 and  CLEREZZA-463.
>> > I just want to know when we are meant to use the mailing list and when
>> the
>> > issue
>> > database.
>> >
>> >
>> >
>> > On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote:
>> >
>> > ----- Original message -----
>> >>
>> >> On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
>> >>
>> >> >
>> >> > For cached graphs I suggest to have uirs like:
>> >> >
>> >> > urn:x-localinstance:/cache/<remote-uri>
>> >>
>> >> -1
>> >>
>> >> Should each user who makes a request not get a different remote graph?
>> >
>> > No, this would increase complexity too much. What is in the cache depens
>> > solely on the platform instance. If a user want to retrieve something
>> with
>> > her identity she cannot use webproxy.
>> >
>> >
>> >
>> >
>> >> Because what if a remote instance returns different graphs to different
>> >> users for the same resource?
>> >>
>> >> Btw, I also opened this discussion in CLEREZZA-489 [1]
>> >>
>> >> My guess is that the graph management should hide all of this from the
>> >> user.
>> >>
>> >> The user should ask for relative graphs if he wants local ones.
>> > Which is a direct access to the cache graph, which is consitent with my
>> > proposal above.
>> >
>> >>
>> >> Then if he wants remote graphs he should use the name of the remote
>> >> graph he wishes to get. How that remote graph is named interally is not
>> >> really important.
>> > Which somehow contrasts your -1 above.
>> >
>> >> If the fetch is done over TCP without cookies or
>> >> headers, then presumably all users of the server can view that graph
>> >> equally. If fetching the remote graph requires authentication, then the
>> >> graph will be in part determined by who fetched it.
>> >>
>> >> In the end these graphs should probably just be blank nodes, with
>> >> descriptors of how they were fetched.
>> > Yes, i a perfect world we have bracketing rdf stores so that graphs can
>> be
>> > anonymously within others. But till then we need a key (name) for our
>> named
>> > graph store.
>> >
>> > If you want to stick to your -1, could you popose an alternative?
>> >
>> > I really want to do some tidying in the proxy code.
>> >
>> > Cheers,
>> > reto
>> >>
>> >> Henry
>> >>
>> >> [1] https://issues.apache.org/jira/browse/
>> >>
>> >> Social Web Architect
>> >> http://bblfish.net/
>> >>
>> >
>> >
>> > Social Web Architect
>> > http://bblfish.net/
>> >
>>
>