Re: [PROPOSAL] lifecycle release

Stephen McConnell 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).
>>  
>>
> 
> 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.

All a copyright notice has to reflect is when the code was initially
created.  For new stuff this is 2003.  A copyright lasts for 50 years
after the owner's death--I need to double check for corporate ownership
which is the case for ALL Aapche code.

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

It is also bringing up the code that we are not willing to maintain as a
community as we come accross it and deal with it at that time.

>> Two main things.
>> 1. Empower those who are doing the work

I thought we all could do the work.

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

Better solution: determine if we are supporting the library, and
write real docs if we are or place it somewhere else if not.