[TYPO3-ect] Ideas to clean up TER

Kay Strobach typo3 at kay-strobach.de
Mon Jan 30 20:48:57 CET 2012


Hello at all,

i vote either for the wiki solution or the unmaintained flag.

An extension with this state should not be found by default ter search,
but there could be a simple switch to enable search for unmaintained
extension. Additionally the extension page should contain a very good
visible warning about the state.

Anyway an extension which is unmaintained should not be installable via
EM remotly!

Regards
Kay

Am 30.01.2012 18:47, schrieb Helmut Hummel:
> Hi,
> 
> On 30.01.12 12:55, Michael wrote:
>> On 30/01/12 20:33, Franz Holzinger wrote:
>>
>>>> I just want to clarifiy that "unmaintained" extensions sould also mean
>>>> unmaintained by the Security Team.
>>
>> Is the main difference between "normal" and "unmaintained" extensions
>> from the Security Team's perspective that if someone reports a security
>> issue with an "unmaintained" extension, the Security Team does not try
>> to contact the developer but simply removes the extension?
> 
> Right now, we do not have an "unmaintained" state. Because of this we
> handle reports for every extension, contact the author waiting for
> response (in some cases we get a reply, sometime not) and even publish a
> bulletin mentioning the extension has been removed. This causes a lot of
> extra work without any benefit.
> 
>> This would be
>> legitimate from my perspective.
> 
> This is why I would like to have that "unmaintained" state, so that we
> can communicate, that we do not care of unmaintained extension at all.
> 
>> Is there anything else that applies to "unmaintained" extensions in
>> regards of security and the Security Team in particular?
> 
> Nothing more than mentioned above.
> 
>> I understand that we want to clean up
>> the TER and I definitely support this. However, instead of physically
>> deleting unmaintained extensions or hiding their existence, I would
>> suggest to mark them and let every system, every component, etc. decide
>> how to handle those extensions. The EM could ignore them. The TER search
>> results could list but clearly highlight them as "unmaintained".
> 
> If anything there should be a switch that explicitly allows unmaintained
> extensions to be listed, but it should be off by default.
> 
>> The
>> extension key registration process could do whatever we decide. And so
>> on.
> 
> OK, that's a different story. If we would decide to really delete
> extensions we could also just delete the keys. But this did not cause
> too much troubles in the last years, so I do not see the need for any
> immediate action.
> 
>> A great example for "unmaintained" developments is the PHP::PEAR
>> repository. Have a look at the packages and go to "Mail":
>>
>> http://pear.php.net/packages.php?catpid=14&catname=Mail
>>
>> The package "Mail_Mbox" is not maintained at the moment, which is
>> unfortunately not very obvious in the list view, but click on the
>> package name:
> 
> The unmaintained state not being obvious in the list makes it a bad
> example for me.
> 
>> I really, really love the idea of "cleaning up the TER" (maybe better:
>> cleaning up the extension list) and I think the first step would be to
>> develop rules how to identify "unmaintained" extensions. Personally, I
>> like the concept Jigal suggested: tie extensions to TYPO3 versions. If
>> we introduce a new status ("unmaintained" or similar) that would give us
>> a lot of flexibility.
>>
>> The second step would be to decide how various systems (and maybe Teams
>> like the Security Team) should handle extensions with this status.
> 
> I have a strong opinion on this topic is, because I see how let's say
> 40% of the extensions are outdated, not updated for years, probably of
> bad code quality and therefore susceptible to have bugs and security
> issues on the one hand and eat up resources on the other hand.
> 
> They use our infrastructure, cause extra work for the security team, the
> ci team and every user who uses the search and needs to sort out these
> stubs.
> 
> Cleaning up for me means that the process of cleaning up should not
> cause much work and the result should be, that all of us (or at least
> the majority) should have less work.
> 
> There may be one or two valid usecases where it would be nice to have a
> nice interface to access outdated not maintained extensions, but
> covering these usecaes should not cause troubles for the main usecase:
> Easily find and install great extensions.
> 
> My fear is, that we work out and design complicated rules and workflows
> that never get implemented because the lack of time.
> 
> 
> So my suggestion would be to just hide all extensions according to
> Jigal's suggestions both from the TER search and the EM in the first
> place. If an extension author wants his or her extension to be listed
> again, he or she only needs to upload a new extension version which
> complies to the rules.
> This is a task which should be easy to implement and to which I would
> offer to contribute.
> 
> On top of that, if someone really likes to do that and actually
> implements it, we could optionally offer an extended (or additional)
> search for theses extensions.
> 
> Just my 2 cents.
> 
> Kind regards,
> Helmut
> 


-- 
http://www.kay-strobach.de - Open Source Rocks

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

Answere was usefull: https://flattr.com/profile/kaystrobach


More information about the TYPO3-team-extension-coordination mailing list