incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <>
Subject Re: Release despite code from unclosed issues?
Date Mon, 20 Jun 2011 10:20:53 GMT

On 20 Jun 2011, at 11:24, Reto Bachmann-Gmuer wrote:

> On Mon, Jun 20, 2011 at 10:30 AM, Henry Story <>wrote:
>> On 20 Jun 2011, at 10:17, Reto Bachmann-Gmuer wrote:
>>> I'm really looking forward to having a first clerezza release. I think it
>> is
>>> important to have a version against which tutorials can be written and
>> that
>>> its important for us to have the experience of going through the release
>>> process.
>>> As only closed issues indicate that both developer and (after a 72h
>> delay)
>>> the rest of our community are satisfied with the solution I think that
>>> technically a release should not contain any code from an unclosed issue.
>> I
>>> wrote last week on how to address the issues for which code has been
>>> committed but that are not yet closed.
>>> I believe the conditions that led as to the current situation with many
>>> interdependent issues with quite massive changes to trunk without the
>> issues
>>> being closable were quite unfortunate and that we should take great care
>>> that this wont happen again. However I'm not sure on what we best should
>> do
>>> now:
>>> - (vote on) release a specified trunk version even though this contains
>> code
>>> that is not at satisfaction of its developer and the community
>>> - revert all code committed for issues that cannot be closed
>>> - wait till the issues can be closed
>> just remove it. I am working on a seperate branch on github. Most of the
>> code in the control panel can easily be reversed in the control panel, even
>> back to the ssp stage.
>> I will work on the EasyGraph class in the next few days to see how I can
>> integrate it better. But my feeling is that unless you do it yourself you
>> won't be satisfied. For example thinking about EasyGraph your point was that
>> read and write graphs should be the same things. But even that is not so
>> clear, since in a pure functional programming paradigm those are very
>> different things. (see all the scala classes with mutable and non mutable
>> state)
>> In any case I think it is best if I work in github. I'll point to
>> functionality I have built there from time to time, when it is ready, and
>> then people on the main branch can pull it in and rewrite it to your
>> preferences. Or take it as is. I'll do the same the other way around.
> Hi Henry
> This sounds quite saddening. For example I really like many of the features
> of EasyGraph and I'm happy to contribute to it. I'm convinced that by
> working together we can find solutions that satisfies both of us and the
> community as a whole.
> But to work together we need to understand what the other has done. I did
> try to do this for EasyGraph. For this I tried to make unit tests from the
> example usages in the comments. Unfortunately not everything compiled. As
> you understand the easygraph best I think that its easiest if you write down
> some testgraph in the various EasyGraph-Syntaxes in the form of Unit-Tests.
> This would allow me to understand the code better and be able to make
> refactoring while having regression tests to ensure that the functionality
> you like to have is there.
> I see that git has several advantages compared with svn. But I think if we
> would like to move to git this should happen at apache and we should discuss
> this with infra. In the meantime I don't see any process that cannot also be
> implemented with issue branches and spike branches.
> EasyGraph is an example of something that would have best been started in an
> issue graph. Several people could have contributed to that issue branch and
> I could have been closed quickly as we like it and want it. Now we have it
> in trunk and it is used in several places an I think its best to work from
> there is we can act quickly. The skeleton tests I added are an attempt to be
> as helpful as possible while not trying to do what you can do much more
> efficiently than me. I think this is a starting point for working together
> productively on code.
> I would find it very regrettable if you prefer not to work together with
> frequent code centred interactions and a process oriented to frequent code
> approval by the community. Before you start a fork I would appreciate you
> telling us what you think should have been different with process and
> community for the results to be more fortunate.
> Cheers,
> Reto

Well there are of course good reasons not to fork. I'd rather not, because we can only
work more slowly if we work alone. 

But git integration with svn is not that difficult I found out. You can checkout code
directly from and load it up on github - it's not that large. Then apparently
it is possible to make that git branch tie into svn by following the procedure here
(I have not tried this yet, but will let you know soon)

I am just about to check in (github) some code for the WebID IDP (adapted from what is running, 
because the certificate there has expired and I'd like to remove the cost of 70 euros a month
of that
cloud service I am using, and move it all to With Clerezza this will be a much
more p2p setup
so that anyone who runs that module can become an idp for someone else. It is mostly done.

(btw, services like this are another reason why I don't want every person to automatically
get an account
on my system)

I'll look at EasyGraph, remove some methods, and some test cases then and clean it up. 
I have a feeling it would best be done as a Trait, so there could be an EasyGraphWrite Trait
and an EasyGraphRead Trait, or if you want a RichGraphNodeRead Trait and a RichGraphNodeWrite

But I have not written any traits yet, so add the bit of time it takes to integrate that concept

Thanks for putting the test case framework together. That will help me.
The cool test case framework I mentioned in the issue report are

Seeing things like that one really has to admit that Scala rules. It is just such a good idea.
It builds on junit but  is just so much more powerful. Perhaps this won't be applicable to
the EasyGraph case though.

Anyway, I'll reduce my involvement on the linked open data mailing list and move my attention
back here. But it is true that there won't be a way to get the person browser and the ping
back mechanism done and finished in time for your release. So I don't think it's a problem
if you just remove the code from the trunk. Or you could just create a 
release1 branch and remove all the pieces that are not working well enough from there. The
EasyGraph won't be a problem then because I think it is only used in the code in the account
control panel and the foaf+ssl code. So it all depends in how much of a hurry you are.


>> Henry
>>> What do you think?
>>> Cheers,
>>> Reto
>> Social Web Architect

Social Web Architect

View raw message