Peter Donald wrote:
On Sun, 16 Mar 2003 10:57, Leo Simons wrote:
* released components have backwards compat broken haphazardlyjust 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 saw a response to this from Berin and confirmation that things were working properly.
Can you be specific about the situation your referring to? At least will save Berin some time if indeed the problem isn't resolved.
* licenses on 90% of files is invalidcould 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. Because we attach the full license to each file the files are considered separately licensed. Which means that if a file must have the correct years in copyright years.
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).
Perhaps you have not noticed but the licesences inside sources files have been progressively updated. You welcome to contribute to that process if so inclinded. Perhaps a constuctive action would be to post a list of the packages that need attention. This would assist others who also interesting in bring these things in line.
Have these things always been "screwed"?
some of it has, some hasn't. Several of the things that have got more screwed over time you will actually find me arguing against in the past.
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.
* "slimming avalon down" - unfortunate that it has to occur but probably for the best
* "unified coordinated releases" - really bad idea. Components should be releases when they are stable and supported. They should be released by the people who are willing to support them after they are released. 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. I would have thought that this was learned from the last big ball of mud release.
You could think of this as a stocktacking exercise where we step though everything - everything get our attention, everybody gets a little more aware of the status of things. The PMC progressively moves towards a position where is has a good grip on what it is responsible for, I see this is really constructive and so far, the impact on the code based and documetation has been positive.
* "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.
* "forrestbot, jira tracker, using a wiki" are just tools and are as useful as they are used. I love forrestbot and the fact that jeff is maintaing it (thanks!), jira is better than bugzilla IMHO and wiki ... seems to be at least generating some docs.
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
Empower whom? For what work in particular? Perhaps you could switch in -verbose so that your coment could be translated into a constructive and usable suggestion?
2. stop putting fingers in the holes and start fixing the leaks.
Stop groaning and fix the license that are incorrect.
For (1) stop vetoes for non-technical reasons and by those who aren't willing to actually put in work to solve the problem.
If you feel that a veto is inappropriate the best course of action is to post a message to PMC stating your case. The PMC is there to ensure that things are done properly. They can certainly retract a veto if they feelit is appropriate.
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).
So take this as a -1.
We have put in a maven build on the Merlin package. The reports we have at the moment indicate that there are some problems. One of the reasons for putting in a maven build within Merlin was enable experimentation with Maven here within the community. Out of that experimentation we will be able to make reasonable decisions about the convensions we apply, approaches, etc. There are clealy things that remain to be resolved - Forrest doc build integration and gump integration are two examples. Perhaps you consider contributing to the community by applying your expertise to getting the Merlin example to the point where all of the points are resolved.
* Delete junk docs (ie docs that don't say anything but are just placeholders). (I will also do this if no one -1s it)
What about putting in place actual documetation - you know - two of three paragraph summary, maybe a component table, example of usage. I think that would be more constructive.
* Delete docs from apps and all references from website - not maintained anyways (I will axe)
Same comment as above.
* Delete any other non-maintained code or docs
Verbose mode required - which are codebases that you consider are non-maintained? In what respect are they non-maintained - unresolved bugs? Incomplete documetation? Maybe you could do a little audit and break down projects in terms of actions that in your opinion could be taken / should be taken?
* Drop Forrest dependency except where needed
* Stop insanity of uploading all the docs to site module and use site:deploy from maven
See maven comments above.
* stop the pointless moving around of code. It can be deprecated in place if need be
I actually prefer the compatability jar approach - it really does encourage people to migrate.
* remove all one-man codebases without prejudice
etc.
Do you have any specific codebases in mind? Perhaps you could could make some specific recommendations?
Plenty more things to do.
Great, I've got plently of time to listen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
