todo list (was: Re: [PROPOSAL] lifecycle release)

up front, thanks for writing this.

Peter Donald wrote:
> On Sun, 16 Mar 2003 10:57, Leo Simons wrote:
>>>* released components have backwards compat broken haphazardly
>>
>>just in cvs, and they get fixed, too. Having CVS means some experiments are
>>possible!
> 
> Still no one has fixed the backwards incompatible changes to thread. It has 
> been a couple of weeks now, a -1 and ... nothing.

I was under the impression Berin had reverted this (he said so on-list). 
I'll have a look. In the meantime you should feel free to make the 
revert yourself IMO.

>>>* licenses on 90% of files is invalid
>>
>>could you please elaborate on this one? One of the things on my TTD is
>>figuring out the last bits of any license issues.
> 
> majority of licenses are unenforcable because they include the incorrect years 
> or they contain things like @year@ as the year.

I'll run a grep for those this weekend; I thought we'd got them all out. 
Should be pretty easy to run a one-off filter for @year@.

> So if it was created in 2000 and edited in all years since it would be 
> 2000-2003, if it was edited in 2000 and again this year it would be 2000,2003 
> or various other combinations (ie 2000-2001,2003).

We talked about this on the PMC list recently (or was it here?). The 
resolution was that it is not terribly important from a legal POV to 
update this copyright information very exactly. If something is marked 
as copyrighted in 2000, it will remain copyrighted for the next 50 years 
or so (forgot the exact number); not renewing the copyright claim simply 
means that after that time the copyright becomes non-enforcable.

In short, yes, we should update this, but the license is not invalid if 
the copyright date is a bit "stale".

>>If not, when did that happen, how,
>>and what can we do to prevent it from happening in the future? Do you think
>>the work currently being done by some of us (ie slimming avalon down,
>>"unified coordinated releases", replacing cocoon with forrest, forrestbot,
>>jira tracker, using a wiki) is going in the right direction?
> 
>  one point at a time.

sure :D I actually didn't want to list lots of points; just threw out a few.

> * "slimming avalon down" - unfortunate that it has to occur but probably for 
> the best

+1

> * "unified coordinated releases" - really bad idea.

you seem to have a different idea of what that means than I...see below.

> Components should be 
> releases when they are stable and supported.

+1

> They should be released by the 
> people who are willing to support them after they are released.

+1

> The only 
> reason why coordinated releases could make sense is if there is high coupling 
> between components - in which case I would argue that the components should 
> not be released.

hmm. Even when there is no tight coupling it makes sense to do extra 
testing (besides the continuous integration gump affords, and our nearly 
nonexistent unit tests) on some snapshots. Especially since our gump 
setup has been broken so long: changes might have crept into the 
packages which might've broken somewhere else. With the huge size of the 
avalon codebase, the broken integration, and the limited unit tests, I 
simply cannot be sure no incompatible changes have been made. Can you?

Sure, we should fix the actual problems rather than work around them, 
but in the meantime the world should keep on spinning, too.

> I would have thought that this was learned from the last big 
> ball of mud release.

yep. I would like to think that our releases get better every time. As 
long as there is an improvement from release to release things don't 
need to be perfect in one go.

> * "replacing cocoon with forrest" - good for framework. Not necessary for 
> phoenix atm but I would like to keep it because it may be in the future. For 
> the rest the complexity is not justified so axe it.

hmm. I totally agree forrest is too complex for simple doc projects (the 
forrest peeps agree, too!). IIUC it should be easily doable to write a 
plugin for maven which can generate docs from the forrest doc format. 
When/if we move to maven we can tackle that too.

In the meantime, forrest is better than plain cocoon.

> * "forrestbot, jira tracker, using a wiki" are just tools and are as useful as 
> they are used.

+1

>>If not, what
>>should we be doing? Are there other things we should be doing?
> 
> Two main things. 
> 
> 1. Empower those who are doing the work 
> 2. stop putting fingers in the holes and start fixing the leaks.
> 
> For (1) stop vetoes for non-technical reasons and by those who aren't willing 
> to actually put in work to solve the problem.

I think we've pretty much done that; when/if you feel a veto was thrown 
for a non-technical reason please do not hesistate to say so, or contact 
the PMC, so that matters can be resolved. Anything else that would lead 
to even more empowerment?

> For (2) there is a lot to do. 
> 
> * Drop ant as build system for excalibur and replace with maven (I volunteer 
> to do this if no one will -1 it).

my idea was to wait for beta 0.9 based on recommendations from jason, 
before getting started on any migration. Still, there is already 
consensus (see archives) that we should be setting up maven next to the 
ant system, at least to try things out. We don't want to go halfway with 
maven and end up with a broken maven setup and a broken ant setup.

Wit that in mind, please feel more than free to set this up, but please 
don't throw ant out just yet. Perhaps it would also be a good idea to 
get the things with an actually half-working rather than just a real 
annoying build system over to maven first.

> * Delete junk docs (ie docs that don't say anything but are just 
> placeholders). (I will also do this if no one -1s it)

+1, provided you make some noise about the specific docs that you think 
are just placeholders first, so people (like me or you) might have a 
chance to replace placeholders with something that is not a placeholder, 
and so we are sure we all agree on which docs are just placeholders :D

> * Delete docs from apps and all references from website - not maintained 
> anyways (I will axe)

Paul just updated this I believe, so I'm not sure how dead this is. 
Still, stuff like phyre has been getting gump failures for a long time, 
so if no-one steps up to do maintainance, yes, those things should 
definately go.

> * Delete any other non-maintained code or docs

if it is not released, and no-one has plans to start maintaining things 
again, +1. Again, please do ask&confirm before acting :D

> * Drop Forrest dependency except where needed

as long as our site stays up and running, docs can be created and 
maintained in a neat and intuitive xml format, and transformed as part 
of the build process, I don't care what tool we use. Forrest works for 
me, even if it is a bit heavy.

> * Stop insanity of uploading all the docs to site module and use site:deploy 
> from maven

you aware of the talks about this on the infrastructure list? I believe 
there's a couple of people looking at doing this for various projects. 
Options mentioned include maven, forrestbot, and webdav/svn. I dunno how 
site:deploy works, but if it is an improvement then its a good idea :D

> * stop the pointless moving around of code. It can be deprecated in place if 
> need be

I think it was a good idea to remove some of the cruft from excalibur. I 
agree that it didn't make too much sense to set up the excalibur compat/ 
thing, but it makes even less sense to move things back now :D

> * remove all one-man codebases without prejudice
---
http://dictionary.reference.com/search?q=prejudice

prej·u·dice   n.

    1.
          1. An adverse judgment or opinion formed beforehand or without 
knowledge or examination of the facts.
          2. A preconceived preference or idea.
    2. The act or state of holding unreasonable preconceived judgments 
or convictions. See Synonyms at predilection.
    3. Irrational suspicion or hatred of a particular group, race, or 
religion.
    4. Detriment or injury caused to a person by the preconceived, 
unfavorable conviction of another or others.
---

sure thing. We need to do this in an evolutionary way imo, not just 
throw lots of stuff out happy-snappy.

>>>I have explained the same things in the past. It is annoying to have to
>>>repeat
>>>things when I know you will only ignore things again this time.
>>
>>what on earth makes you believe I'm ignoring you? When have I ignored you
>>in the past?
> 
> You ask the same things over and over. If you were asking for clarification 
> that would be different.

so call me a slow learner or a bad listener, but I do act on your 
suggestions as well (if I agree with 'em)! Even when I or others don't, 
surely you are "empowered" to do things yourself (as long as there's 
consensus of course). Still, lacking a tracker tool setup, this e-mail 
has been printed and taped to the wall :D

cheers,

- Leo