On Mon, Jun 20, 2011 at 10:30 AM, Henry Story <[email protected]>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 > Henry > > > > > > What do you think? > > > > Cheers, > > Reto > > Social Web Architect > http://bblfish.net/ > >
