You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/03/19 14:53:45 UTC

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



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: todo list

Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 24 Mar 2003 19:43, Leo Simons wrote:
> > Sounds like a totally different issue, normally referred
> > as Trademarks.
>
> "Apache" is not a registered trademark for the ASF. You will notice the
> lack of "TM" or "SM" in the logos :D

trademarks don't have to be registered to be trademarks. Registeration only 
gives more weight but non-registered are defensible if certain conventions 
are followed (ie you have defended and enforced historically or this is a 
first violation).

> > Am I allowed to release a software called "Niclas Excel"? Even a
> > spreadsheet application?
>
> probably, since Excel is not a registered trademark, you could release
> software called like that. In the case of a spreadsheet application,

You couldn't without violating a trademark (regardless of whether it is 
registered or not but I assume it is).

-- 
Cheers,

Peter Donald
*------------------------------------------------*
| The student who is never required to do what   |
|  he cannot do never does what he can do.       |
|                       - John Stuart Mill       |
*------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: todo list

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Leo Simons wrote:
> IANAL!
> 
> Niclas Hedhman wrote:
>> ?? That means that if I _don't_ use Apache software I can call the software 
>> "RedHat Apache" ??
> 
> yep, but it wouldn't be a very cool thing to do :D.
> 
>> Sounds like a totally different issue, normally referred 
>> as Trademarks.
> 
> "Apache" is not a registered trademark for the ASF. You will notice the 
> lack of "TM" or "SM" in the logos :D

that does not prevent it from being an unregistered mark --
which it is -- that cannot be used without the permission
of the mark's owner.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: todo list

Posted by Leo Simons <le...@apache.org>.
IANAL!

Niclas Hedhman wrote:
> ?? That means that if I _don't_ use Apache software I can call the software 
> "RedHat Apache" ??

yep, but it wouldn't be a very cool thing to do :D.

> Sounds like a totally different issue, normally referred 
> as Trademarks.

"Apache" is not a registered trademark for the ASF. You will notice the 
lack of "TM" or "SM" in the logos :D

> Am I allowed to release a software called "Niclas Excel"? Even a spreadsheet 
> application?

probably, since Excel is not a registered trademark, you could release 
software called like that. In the case of a spreadsheet application, 
you'll probably get sued, because you're deceiving your buyers, lifting 
on the marketing budget of MS, etc etc. In cases like this, the one with 
the most lawyers often wins.

cheers,

- Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: todo list

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 20 March 2003 20:02, Stefano Mazzocchi wrote:
> Niclas Hedhman wrote:
> > Today I CAN take the code and do something else with it, without
> > consulting Apache, I can spawn it, make it commercial, practically
> > anything except leveraging on the Apache name.
> > What more can I do IF ASF didn't have copyright on a particular file?
>
> Call it RedHat Apache.

?? That means that if I _don't_ use Apache software I can call the software 
"RedHat Apache" ??  Sounds like a totally different issue, normally referred 
as Trademarks.

Am I allowed to release a software called "Niclas Excel"? Even a spreadsheet 
application?

Sorry, for getting way off-topic...

Niclas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> It is my understanding that a work is copyrighted automatically,
> copyright notice or not, as soon as it exist on any transfer
> medium (i.e. not just in my head).

Confirmed by Al Schlessinger (the top formost authority on the
subject).

The copyright notice that we present includes a license for use.

We (the Apache Software Foundation) retain ownership of the code,
and license it to our users.  We happen to have a liberal license
while others are more restrictive (and much longer).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Thu, 20 Mar 2003 19:24, Leo Sutic wrote:
> 
>>I think this is standard practice internationally. A copyright
>>notice is *not* needed for copyright protection. You get that
>>automatically.
> 
> 
> yep (well almost - it depends on your country) - but that has nothing to do 
> with what I am talking about. But without a license no user can use the file 
> (well thats depends on place in the world actually). Explicitly stating 
> incorrect facts in a "contract" when you know the facts to be incorrect is a 
> little bit different.

The copyright year is not a fact in a contract. The *license* is one 
thing, the copyright is another.

The Apache License 2.0 will make this distinction more obvious and solve 
our issues once and for all.

Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

> From: Peter Donald [mailto:peter@realityforge.org] 
>
> Explicitly stating incorrect facts in a "contract" when you 
> know the facts to be incorrect is a little bit different.

I don't think it's fatal in this case so I see no reason
to consider a wrong copyright notice in our licenses to be
serious. But I see no reason to go to any lengths to *keep*
it wrong either. (I.e. dropping this.)

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 19:24, Leo Sutic wrote:
> I think this is standard practice internationally. A copyright
> notice is *not* needed for copyright protection. You get that
> automatically.

yep (well almost - it depends on your country) - but that has nothing to do 
with what I am talking about. But without a license no user can use the file 
(well thats depends on place in the world actually). Explicitly stating 
incorrect facts in a "contract" when you know the facts to be incorrect is a 
little bit different.

-- 
Cheers,

Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
---------------------------------------------- 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Leo Sutic <le...@inspireinfrastructure.com>.
It is my understanding that a work is copyrighted automatically,
copyright notice or not, as soon as it exist on any transfer
medium (i.e. not just in my head).

The University of Washington seems to agree with this:

http://depts.washington.edu/uwcopy/information/copyrightlaw/1.shtml

"Copyright protection subsists... in original works of authorship fixed 
in any tangible medium of expression... from which they can be
perceived, 
reproduced, or otherwise communicated, either directly or with the aid
of 
a machine or device." 17 USC §102(a) 


I think this is standard practice internationally. A copyright
notice is *not* needed for copyright protection. You get that
automatically.

/LS

> From: Peter Donald [mailto:peter@realityforge.org] 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 19:25, Leo Sutic wrote:
> More on copyright notices:
>
> http://depts.washington.edu/uwcopy/information/copyrightlaw/12.shtml

Read the paragraph under "Important note:". Though it barely touched on the 
point.

-- 
Cheers,

Peter Donald
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience           |
*-----------------------------------------------------* 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Leo Sutic <le...@inspireinfrastructure.com>.
More on copyright notices:

http://depts.washington.edu/uwcopy/information/copyrightlaw/12.shtml

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 20 Mar 2003 17:28, Niclas Hedhman wrote:
> On Wednesday 19 March 2003 21:53, Leo Simons wrote:
> > Peter Donald wrote:
> > > 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 you want to ever be able to enforce the license it is. While not covered by 
contractual law (at least in Australia/US) it is close enough and it would 
never stand up in court of law.

> 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.

It is not about that.

> Maybe I'm too frivolous on this, and missing something truely important.

no - you got it.

-- 
Cheers,

Peter Donald
------------------------------------------------------------
 militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------ 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: todo list

Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 19 March 2003 21:53, Leo Simons wrote:
> 
>>Peter Donald wrote:
>>
>>>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.
> 
> 
> Maybe I'm too frivolous on this, and missing something truely important.
> 
> What happens in 2050, when Apache looses the Copyright??

Apache looses copyright of the stuff that hasn't been touched in 50 
years. I think I would love to see software that is 50 years old just die!

> It becomes FREE, freer than ASL !!  ??

Yes. It's called 'public domain' and it's different.

> Today I CAN take the code and do something else with it, without consulting 
> Apache, I can spawn it, make it commercial, practically anything except 
> leveraging on the Apache name. 
> What more can I do IF ASF didn't have copyright on a particular file?

Call it RedHat Apache.

Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Wednesday 19 March 2003 21:53, Leo Simons wrote:
> Peter Donald wrote:
> > 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.

Maybe I'm too frivolous on this, and missing something truely important.

What happens in 2050, when Apache looses the Copyright??
It becomes FREE, freer than ASL !!  ??

Today I CAN take the code and do something else with it, without consulting 
Apache, I can spawn it, make it commercial, practically anything except 
leveraging on the Apache name. 
What more can I do IF ASF didn't have copyright on a particular file?

Niclas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


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

Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> 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.

I reverted the stuff in Cornerstone.  I unintentionally did not revert
the changes in Thread.



>> 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?

We also have alot of questions with our users that come up from time
to time.  They are along the lines of "Excalibur Logger doesn't work
with LogKit X because of exception Y".  Instead of finding all the
places where components are not working with each other (because they
are in CVS), we are baselining our product-set.

This fresh start approach allows us to audit what we will support,
and validate that it does not break back compatibility.  That also
means we need to add tests--so any help will be appreciated.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: todo list

Posted by Nicola Ken Barozzi <ni...@apache.org>.

Leo Simons wrote, On 19/03/2003 14.53:
...
>> 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".

Actually, a file's copyright should really be updated only when really 
modifying it, not in bulk.


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org