incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <>
Subject Re: Official ASF process for re-writing code?
Date Wed, 01 Aug 2012 00:57:28 GMT
+1 (non-binding and certainly not official) for taking the opportunity to
rewrite code as a chance to make things better, vs least efforts.

Code written more than several months prior can often be written better
anyway (one hopes their skills age well :P).  Particularly, unit tests are
a welcome great improvement whenever there's code to be "rewritten".  I'd
go so far as to say code without unit tests are often time bombs that
should be rewritten anyway.


On Tue, Jul 31, 2012 at 5:46 PM, Brett Porter <> wrote:

> On 01/08/2012, at 6:52 AM, Chip Childers <>
> wrote:
> > Does anyone know the official ASF stance on what it means to
> > "re-write" a section of code?
> There's no general answer to this - each case needs to be considered
> separately. This was the closest I could find in the archives:
> >
> > Specifically, I was looking at the F5 code [1] that was found during
> > license header changes (and is considered a release blocker bug [2]).
> > The code is actually quite trivial in nature, and I'm wondering what
> > it would take to correctly write a replacement class file.  My
> > assumption is that simply re-naming variables wouldn't work (and even
> > if that was enough, there are only a handful of them in the file).
> I agree, renaming variables is definitely not right.
> In this case it is trivial (I googled and found a half-dozen examples
> doing the same thing), so I'd say remove it and have someone reimplement
> it. It may be better in these cases if they haven't seen the original code,
> but not strictly necessary. It is probably a good opportunity to refactor
> calling code too, if needed.
> In other cases, an option available is to ask the copyright holder if
> they'd consider contributing/granting a license to a piece of code to
> include here.
> Ultimately, we want to make sure we do the right thing by the authors and
> that code here is intentionally contributed.
> HTH,
> Brett
> --
> Brett Porter

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