www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (INFRA-12683) Moving binary bits between users and support resources -- support packages
Date Sat, 08 Oct 2016 19:08:20 GMT

    [ https://issues.apache.org/jira/browse/INFRA-12683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15558546#comment-15558546
] 

Mark Thomas commented on INFRA-12683:
-------------------------------------

Total message size between 2 bytes and 1000000 bytes
The following mime types are blocked:
application/excel
application/rtf
application/msword
application/ms-tnef
text/html
text/rtf
text/enriched
text/x-vcard
application/activemessage
application/andrew-inset
application/applefile
application/atomicmail
application/dca-rft
application/dec-dx
application/mac-binhex40
application/mac-compactpro
application/macwriteii
application/news-message-id
application/news-transmission
application/octet-stream
application/oda
application/pdf
application/postscript
application/powerpoint
application/remote-printing
application/slate
application/wita
application/wordperfect5.1
application/x-bcpio
application/x-cdlink
application/x-compress
application/x-cpio
application/x-csh
application/x-director
application/x-dvi
application/x-hdf
application/x-httpd-cgi
application/x-koan
application/x-latex
application/x-mif
application/x-netcdf
application/x-stuffit
application/x-sv4cpio
application/x-sv4crc
application/x-tar
application/x-tcl
application/x-tex
application/x-texinfo
application/x-troff
application/x-troff-man
application/x-troff-me
application/x-troff-ms
application/x-ustar
application/x-wais-source
audio/basic
audio/mpeg
audio/x-aiff
audio/x-pn-realaudio
audio/x-pn-realaudio
audio/x-pn-realaudio-plugin
audio/x-realaudio
audio/x-wav
image/gif
image/ief
image/jpeg
image/png
image/tiff
image/x-cmu-raster
image/x-portable-anymap
image/x-portable-bitmap
image/x-portable-graymap
image/x-portable-pixmap
image/x-rgb
image/x-xbitmap
image/x-xpixmap
image/x-xwindowdump
text/x-sgml
video/mpeg
video/quicktime
video/x-msvideo
video/x-sgi-movie
x-conference/x-cooltalk
x-world/x-vrml

> Moving binary bits between users and support resources -- support packages
> --------------------------------------------------------------------------
>
>                 Key: INFRA-12683
>                 URL: https://issues.apache.org/jira/browse/INFRA-12683
>             Project: Infrastructure
>          Issue Type: New Feature
>          Components: Mailing Lists, Website
>            Reporter: Shawn Heisey
>            Priority: Minor
>
> I'm a committer on lucene-solr.  I have opened SOLR-9587 as an idea I hope to implement.
> This idea contains certain challenges that I wish to discuss with INFRA before I get
started.  Once a user creates a support package, they will need to have a reliable conduit
by which they can get that information to those who can help with their problem, mostly on
the solr-user mailing list and some IRC channels that we maintain on freenode.
> One idea, if we can mostly keep the packages below 1MB in size, is the public-facing
apache paste bucket site, http://apaste.info ... but potentially thousands of packages with
an average size of hundreds of kilobytes appearing in that database in a short amount of time
is probably NOT a good thing.
> A well-optimized and dedicated web service for handling such packages is another idea,
but I have no idea what that would entail, and again, it's another burden on Infra, and probably
too much to ask if lucene-solr is the only project using such a resource.
> Asking users to use public resources like dropbox is compelling, and that will probably
be how we start out with this, but a headache-free process for end users would be very nice
to have.
> If infra DOES end up making a service, we can reduce the load by incorporating fairly
aggressive and non-optional expiration dates for all data.
> The last idea to discuss is attachments on our mailing list.  We have had very much mixed
luck with attachments on our list in the past, and would like to understand exactly what the
attachment rules are on solr-user@lucene.a.o ... and what infra really thinks about the idea
of these support packages traversing the list.  I do think attachments should NOT get stored
in the mail archives, regardless of what else happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message