incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <reto.bachm...@trialox.org>
Subject Re: Wide consensus (was: Re: How to name things with URIs)
Date Fri, 13 May 2011 13:24:08 GMT
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
<tommaso.teofili@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 <reto.bachmann@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 <henry.story@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/
>> >
>>
>

Mime
View raw message