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 @[EMAIL PROTECTED]
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
