[TYPO3-ect] Ideas to clean up TER

[Franz Holzinger]

Hello

On 29/01/12 13:56, Jigal van Hemert wrote:
>> - If we want SVN / git as archive: do we also require extensions to be
>> in forge? And if so, doesn't it make sense to publish tags as extension
>> version in TER automatically? And by this requiring a solid tagging
>> workflow?
>
> No, extensions should not be required to be in forge. A tag doesn't mean
> a new TER version automatically. Before an extension is ready for TER
> there could already be tags during development.

Forge should not be used for such unmaintained extensions.
Remove all old versions of the extensions from TER.
If no new version remains in TER, then the extension author should be 
removed and set to a person 'I need a maintainer'. If a new maintainer 
is found then he should obtain the extension key. He has 3 months time 
to upload a new version. Otherwise he will loose the extension key again.
The latest version of the code of an unmaintained extension should be 
kept in TER for 3 years, because otherwise nobody would take notice of 
it. It could be completely removed after 3 years of unmaintainance.

>> - What to do with extensions which are not in forge? It is now possible
>> to create a new forge project for an already published extensionkey...
>
> Automatically created forge projects? Can forge handle this load? A
> substantial number of extensions is put in TER (sometimes because of
> project requirements) while nobody is interested in maintaining them.
> This would add a load to forge, which in the end should be cleaned up too.

Forge should not be used here.

>> - How can we help developers find the minimal / maximal required
>> version? Does it make sense to set the max version automatically to the
>> maximum version of the current release the developer uses to publish the
>> extension? For example: I upload an extension in 4.4, and the maximum
>> version is 4.3.99, It would make sense to set this to 4.4.99 during
>> publishing... (With some kind of user interaction of course)
>
> Nice to have. Make a patch for the EM if you want!

No, the extension author must test his version under TYPO3 4.4.0 before 
he loads it up.

>> - Does it make sense to create some automatic checks? You know for sure
>> an extension is not compatible with 4.7 if eregi() is used for example,
>> and the same can apply to certain core methods...
>
> Also nice features, but rather independent from the cleaning of TER I
> guess.

You would need a test team which tests the extensions and writes 
automatic test cases. I think that this is not practicable.

>> Regarding the other stuff in this discussion: I'd prefer not to delete
>> the extensions from TER, but hide them in some setting in the extension
>> manager. Like we had "only search reviewed extensions" before.
>
> And the point would be? Most integrators would be annoyed that they
> "had" to set this setting first before getting access to all the
> extensions. Same as we had with the reviewed extension setting.
> That's not cleaning up, but making old stuff a little less obvious.

Delete them after 3 years of no maintainance. This would be enough time 
to find a new maintainer. Otherwise the extension is not worth to be 
kept for a longer time.

>> But I would like the notifications to developers when a new stable TYPO3
>> version is out, or the current maximum version is EOL. I can imagine
>> this is a trigger for developers to keep the extension maintained...
>
> Really a trigger? We have an announcement list, buzz, news,
> announcements on other mailing lists/newsgroups, release parties,
> messages on forums, websites, etc.
> We could try to get it on the evening news and maybe visit extension
> authors in person (just kidding).

There should be a notification form for users on typo3.org to write an 
email to the extension author and activate a notification email for the 
transfer of the extension key to the person 'I need a maintainer'. There 
should be some warning emails 3 months before the extension key is 
removed from him. He should be able to disable the removal if the error 
report has been wrong. The removal must be reset if a new version is 
uploaded to TER.
The extension should be removed 3 years later if nothing happens any 
more. The developer list should be informed 1 month before an extension 
is lost forever.


- Franz