[PATCH] ftpd: RETR of a directory should fail

[Chris Johns]

On 6/05/10 11:12 PM, Ralf Corsepius wrote:
> On 05/06/2010 02:33 PM, Sebastian Huber wrote:
>> On 05/06/2010 02:12 PM, Ralf Corsepius wrote:
>>> On 05/06/2010 01:48 PM, Sebastian Huber wrote:
>>>> On 05/06/2010 01:42 PM, Ralf Corsepius wrote:
>>>>
>>>>> On 05/06/2010 01:27 PM, Sebastian Huber wrote:
>>>>>
>>>>>
>>>>>> Please do not send patches to this mailing list. Instead they should
>>>>>> go into
>>>>>> the bugzilla data base:
>>>>>>
>>>>> Sebastian, no idea were you've got this idea from.
>>>>>
>>>> It just makes sense.
>>>>
>>> Many projects will disagree with you.
>>>
>>> The traditional arguments against bugzilla (floating around ever since
>>> bugzilla exists):
>>> - It requires a log-in. Many users refuse to get one.
>> Yes, this is annoying, but it is only a configuration issue.
> Not only this, it also is a matter of spam prevention.

Agreed. We do not have to remove bugs that are spam. When I converted 
the GANTS database to bugzilla a large number of bugs were spam.

>
>> For FreeBSD it is
>> possible to send bug reports without a log in (they use Gnats).
>>
>
>>> - It means additional bureaucracy / overhead.
>> Yes, but this overhead helps to track the patches and reports.
>>
>
> Bugzilla has it's use-case: Bug tracking. I.e. to report bugs, esp. in
> cases when no immediate patch is around.
>
> For reviewing patches, bugzilla doesn't add any value in comparison to
> posting to lists.

I find a bug's single list of the thread easier to deal with. I can also 
find what I need to deal with quicker. Email and threading is weak and 
breaks.

> Finally, "patch-tracking" in general - Whether this makes any sense at
> all is highly questionable.

In terms of bugzilla maybe, other approaches, I tjink they could be 
useful. RTEMS has a large number of targets and some are 16bit. This 
makes the code sometimes difficult to get clean on all platforms. I 
think asking a user to download and build on all targets and BSPs is too 
much but this becomes the role of the person who applies the patch.

The daily build system I run that posts the errors in a table is part of 
a process to help deal with this issue but it is after the patch has 
been applied. The system is actually called the 'patch queue' and one 
day it would be nice to be able to submit a patch and get back the 
results. The feedback would the targets the patch breaks on and the 
differences in warning levels. This is not about a system to manage 
patches in RTEMS, rather a place to vet patches from users.

> Forcing/pushing around people to use bugzilla to submit patches
> certainly can be considered to rude and unfriendly.

We need to be flexible and approachable. If someone only wants to submit 
a patch to the mailing list that is fine with me. I just hope they are 
prepared to follow up and ping to make sure it is in the queue to be 
committed.

>>> - It means having http:-access
>>> - It's ui and usabilty leaves much to be desired.
>> Yes, it is not perfect. I am not a Bugzilla expert, but Gnats has also an
>> email interface (and more).
> Bugzillas internals are a real mess, customizing it is a night-mare.

Customization only ends in tears. Maybe this is doing us a service :)

> GNATS once was easy to maintain/customize, but it was unstable and had
> an effectively dead upstream. I don't know if this situation meanwhile
> might have changed (http://www.gnu.org/software/gnats/ indicates GNATS
> is dead).

I hope things have not changed.

> Openly said, I am really surprised, anybody is still using GNATS,
> because most users switched away from it
> (RTEMS was one of them - IIRC, we switched away from GNATS to bugzilla
> in 2005).

Lets not go there. I still have memories of the pain that caused.

Chris