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 08:30:27 GMT

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.


> What do you think?
> Cheers,
> Reto

Social Web Architect

View raw message