Hi,

Lately we got some mails with attachments on the mailing list that were rejected because the total size of the email exceeded 40 kB.

This limit has been 40 kB as long as I remember and I wanted to propose to increase it to 100 kB. Internet bandwidth has risen at least a factor 2.5 in the last 5 year, as far as I can see, so people should not be off less than 5 years ago.

Are there any objections?

Vincent
(Mailing list admin)

I think could be better to increase to 150KB.

This is enough for a long mail and to attach a screenshot or something else.

Cheers.

El 21/05/2009, a las 21:48, Vincent Snijders escribi?:

yeah, i agree with you. 150kb is enough.

2009/5/22 Giuseppe Luigi Punzi Ruiz

2009/5/21 Giuseppe Luigi Punzi Ruiz :

I think could be better to increase to 150KB.

100KB or 150KB is fine by me. 40KB was just to little, even for some "normal" patches.

This is enough for a long mail and to attach a screenshot or something else.

Users should also learn how to create screenshots. This is a major gripe I have, even inside our company as well. I often receive screenshots in BMP format in our office - and being around 2-3MB in side. And even worse, they insert the BMP inside a MS Word document!

Some pointers (seeing that we are developers here, this should be easy to do for all):

* PNG images are an ideal format, or GIF for animation display. JPG gives artifacts and make text look fuzzy.

* Only include the section/region of the screen or window that relates to the message. No need for full desktop size screenshots when you only wanted to show a problem in a button glyph for example.

* Changing the screenshot (PNG format) image mode from RGB to Indexed, reduces the the size a LOT. Plus, doing so the image still looks sharp. Using this, also allow you to include larger images while keeping the size relatively small.
Under GIMP this can be done by doing:
"Image > Mode > Indexed > Generate optimum palette" and then clicking Convert.

* Many screenshot programs don't include the mouse cursor. Somethings it is important to include a mouse cursor. The new Ubuntu 9.04 does this automatically.
If you use GIMP like I do (I'm on v2.4.5), I can supply a "mouse cursor" paint brush
which you can add to GIMP. This makes adding the mouse cursor afterwards very easy.

Like I said, some things just bug me a lot. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Op donderdag 21-05-2009 om 21:48 uur [tijdzone +0200], schreef Vincent Snijders:

This limit has been 40 kB as long as I remember and I wanted to propose to increase it to 100 kB. Internet bandwidth has risen at least a factor 2.5 in the last 5 year, as far as I can see, so people should not be off less than 5 years ago.

I thought the goal of the limit was to avoid that people would send patches to this mailing list, and then automatically suppose that someone would look at them and commit them.

Instead of creating a bug-report.

Joost.

Which is an interesting process. I'm quite happy to cast an eye over a patch inlined or attached to a mail, but it would have to be explained/titled as _very_ interesting to me to make me go and look at the tracker, download and examine the patch.

The easier it is for people to view something, the more likely they are to review it.

Keeping patches off the list is the best way to ensure they won't get comments..

Brad

Experience showed that patches sent to the mailing list tend to be forgotten. Not all patches are simply and can be applied immediatly.

Op zondag 24-05-2009 om 22:27 uur [tijdzone +0800], schreef Brad Campbell:

Joost van der Sluis wrote: The easier it is for people to view something, the more likely they are to review it.

But that's completely irrelevant. When someone submit a patch to this list, he thinks that people who can actually commit the patch will look at it.

But this is not the case. Because for those developers who have commit-rights, the easiest way to view patches is the bug-tracker, not this mailing-list. (ie: according to your own logic, they would not look at this list at all, except it would be very interesting for them)

Only those people who can not apply the patch, will look at it in the mailing-list.

Keeping patches off the list is the best way to ensure they won't get comments..

Well, if you want comments on the patch, this mailing-list is the place to be. But most people want that a patch is reviewed and comitted to svn. Not only commented upon. (although that could be usefull)

Result: someone send a patch to the ML. Someone else sends a reply that it's a good idea to change something. First person changes the patch and sends it again to this mailinglist. The second person says: 'well done, much better now'. And the first person is happy that his patch is approved.

Three months later when he tries the new version of Lazarus, he immediately looks if the patch is applied and his bug is solved and he discovers that that isn't done... We'll never hear from him again...

Patches send to this list will be forgotten. To make that clear to everyone: refuses patches. That'll save us a lot of trouble.

Joost.

But is there any practical difference when somebody in the mailing list replies that the patch sender should/must create an entry in the issue tracker, instead of the message being blocked and the list moderator explaining that?
And BTW isn't it somewhat expected that somebody who writes a 40k patch will know where to send a it? ;-)

Best regards,
Fl?vio

2009/5/24 Brad Campbell :

Keeping patches off the list is the best way to ensure they won't get comments..

That's why I do both. It might be more work for me, but at least they get discussed in the ML if needed. I attach the patch to Mantis bug report and post a summary in the mailing list with a link to the mantis report.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I'm in favor of increasing the limit to 150kb

As for patches, just e-mail the people sending them to put them on the bug tracker.

Op zondag 24-05-2009 om 13:12 uur [tijdzone -0300], schreef Fl?vio Etrusco:

All true. But don't forget to tell them that.

Joost

And BTW isn't it somewhat expected that somebody who writes a 40k patch will know where to send a it? ;-)

No. From my own experience the mailing list is easy to use, but I had many problems to put my first patch into the proper tracker.

BTW, where are the many bugtracker "Severity" keys explained? I have no idea what e.g. is Severity "text" :-(

DoDi

En/na Joost van der Sluis ha escrit:

Patches send to this list will be forgotten. To make that clear to everyone: refuses patches. That'll save us a lot of trouble.

What about patchwork?
http://ozlabs.org/~jk/projects/patchwork/

Bye

Both can be useful. The mailing list is the best place for discussing patches, the bug tracker to register patches for committing.

A limit of 40 kB won't really stop patches, certainly if it is zipped most patches are smaller than 40 kB.

A limit of 40 kB usually stops large unzipped patches and screen shots.

Vincent

Hans-Peter Diettrich wrote

BTW, where are the many bugtracker "Severity" keys explained? I have no idea what e.g. is Severity "text" :-(

I am not 100% sure either, but from the name I would logically conclude that it means text-only issue/change, e.g. in translation or error message.

Nice.. thanks for pointing. I was looking for such tool.

I'll have a look,

Thanks, Marc

If you set it up, please add fpc too ;)