incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <>
Subject Re: CLEREZZA-473 and 516: splitting issues / move changes to branch
Date Sun, 22 May 2011 08:29:46 GMT
+1, I totally agree with Reto

2011/5/22 Reto Bachmann-Gmuer <>

> I commented on CLEREZZA-473 that the issue is far to broad and asked
> it to be split up, now clerezza 516 seems even broader.
> Both issue I think might be used as umbrella issues but are not
> suitable for actually doing commits against them. Many recent commits
> seems very hard to be reviewed.
> Just an example:
> I noted this code in a file called
> val typ: Resource = (agent/RDF.`type`).!
>          return typ match {
>                        case FOAF.Person => personHtml(agent)
>                        case FOAF.Group => groupHtml(agent)
>                        case FOAF.Agent => agentHtml(agent)
>                        case _ => emptyText
>          }
> To me this code clearly stinks, we should just call render(agent,
> "somemode") and have different renderlets for the different type of
> agents. I wanted to see where this was introduced. I see the file has
> 4 commits, two of them are not associated to an issue and the other
> are associated with the very vague and broad and both still open
> issues 473 and 516.
> I think for changes in trunk we should really proceed by very small
> issues and avoid having the same file be affected by multiple open
> issues.
> If this is to be a spike then it can be broader and more explorative
> but then it should clearly not be in trunk.
> What do we do with the existing situation, around the
> accountcontrolpanel we had a lot of commits mots of them have not been
> reviewed, and because of how issues and commits were made they seem
> very hard to actually be reviewed.
> I think the easiest might be to move stuff to a branch and review it
> as a whole when it is to be merged into trunk.
> Reto

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message