I can't speak to the hosting costs and donation rates, but as someone who
ran the forums for a long time, I can see a very real benefit to 'retiring
the old and starting over.' People often want to respond to extremely old
threads, not realizing that the information is outdated and no longer
...@gmail.com> wrote:
>
>
>
> On Wed, Jan 18, 2017 at 10:00 PM, Paul Louden <paulthen...@gmail.com>
> wrote:
>
>> Rockbox is a volunteer project, nobody is paid or full-time.
>>
>
> Then what is this?
>
> [image: Inline image 1]
>
>
Rockbox is a volunteer project, nobody is paid or full-time. There's
probably not someone available to respond or able to address that issue
right now.
On Jan 18, 2017 8:52 PM, "Jason Arthur Taylor via rockbox-dev" <
rockbox-dev@cool.haxx.se> wrote:
> I got no replies the last time I reported
Didn't we try this once years ago with IDs allocated from another project,
and run into issues when we contacted for clarification and found that
doing so would still technically be 'against the rules'?
On Wed, Dec 9, 2015 at 5:30 PM, franklin_wei via rockbox-dev <
rockbox-dev@cool.haxx.se>
This doesn't seem like a development question. Are you asking for
programming help in disabling hardware components, or are you just asking
about how to change settings in the firmware, which oddly is exactly what
the section of the manual you're quoting is already telling you how to do?
When you
As an iFP799 owner, let it rest. :)
On Aug 4, 2014 3:27 PM, Michael Sevakis jethea...@sbcglobal.net wrote:
The reason I dig this up from the dead is to suggest including IFP7xx in
the purge. It's very incomplete with special exclusions in various places
emphasizing its lack of finish. I doubt
Coming out of hibernation to say I agree completely - the HWCodec branch
can be laid to gentle rest.
I'd have to agree that I think it's about time to retire the Archos
builds. HWCodec + Lowmem seems to create an undue burden. It would
most likely be better for the users if a final official Rockbox build
were determined (either a previous release that owners of the hardware
like, or a special
On Tue, May 29, 2012 at 3:27 PM, Michael Sparmann these...@gmx.net wrote:
+1, and I think 256 IDs are not all that much. They probably have a
block of 65536 addresses, and acquiring such a block only costs a
one-time fee of $2000. So we'd basically be asking them for about $10
worth of IDs.
Rockbox doesn't make plans to support any specific device. People
interested in supporting any given device do the work, or they don't.
If you don't find much information shared on a specific device in the
wiki, and not much conversation about it on IRC, it's likely work
isn't being done.
Shouldn't we remove the patches category on Flyspray then, much like
we did Feature Requests?
We've more or less tried using pluginlib actions to have generalized
keymaps. The problem is, it simply doesn't really work. Since the
directional keys can be quite different from target to target (on
wheel targets up and down are going to be wheel up and down, whereas
on joystick targets it will
I don't care what actually *does* the list spacing/expanding. To me
the important part is that it's configurable from within Rockbox,
rather than being something only configurable via .cfg file (like many
theme options).
Because touchscreen devices can differ not only in physical count of
pixels,
So, To the people nice enough to say thanks and try to try my mind,
fix the above and we'll see (I'd be incredibly surprised if anything
changes).
Believe it or not, I do appreciate the work you've done. I pretty much
disagree with your general idea that people should speak their mind
less if
I think we're still at 3.X at the moment too. I don't think this
version brings anything worth increasing the major version number.
On Sat, Sep 24, 2011 at 7:16 PM, Jonathan Gordon jdgo...@gmail.com wrote:
3 - no other target has caused a major bump so why should android
be different?
I do agree 3.10 looks a bit funny. But on the issue of Android being
different from the other targets, it's more the transition from
On Wed, Sep 7, 2011 at 2:36 AM, Jonathan Gordon jdgo...@gmail.com wrote:
Why? Just come in irc and ask someone to press the button. They don't need
to do a full blown revue
Why do we need that step if they aren't even expected to review the
code? What do we gain from ask someone to press a
Just to clarify what I'm looking for, here's an example of naming a
category for every setting:
https://docs.google.com/spreadsheet/ccc?key=0AliucOXfAwkWdDBMNHdFSDBlTHUxWnJlV0p4bGtfelEhl=en_US
Don't comment on my namings. Heck, don't really even read through them
before doing your own. I'd really
On Tue, Aug 30, 2011 at 4:55 AM, Frank Gevaerts fr...@gevaerts.be wrote:
I don't care too much about the rest of the discussion, but I do think
credits do *not* belong in plugins. They may be implemented as a plugin,
but they're a rather fundamental part of rockbox.
I agree. I think wherever
On Sun, Aug 28, 2011 at 5:41 AM, Jonathan Gordon jdgo...@gmail.com wrote:
My view regarding debug is that there is nothing there that is
actually useful once a port is up and running *or during development*
Every now and then I've seen debug needed to check things in the past.
Personally, I'd
I'm pretty sure you're the only person who actually has issues with
TD going into settings, because you believe that it's not a setting.
There's plenty of discussion on the topic in IRC, so your statement
the only way to get any discussion is to commit and fend off the
hordes isn't really true.
Okay, what I'd like to see here is this:
People who actually want to directly contribute to this process
(filling out a list of categories at each step, etc), please respond
to this saying so, so that we can come up with dates and get this
thing moving, as well as trying to begin selecting our
You should probably also mention that included in those diffs is also
a rearranging of the main menu as you mentioned in your first message,
but left out in your summarized descriptions here.
Hey guys, so, we're contemplating trying this once more. Many of us
regularly come to the conclusion that the settings are not organized
in the best way possible. We also often never manage to do anything
about it. So we'd like to try again.
We're going to come up with a proper process under
On Tue, Aug 23, 2011 at 9:05 AM, bryan.chi...@rbs.com wrote:
I think it's worth trying to set a guideline for the maximum desirable menu
depth too - I don't think we'd want to go to fine grained for everything
unless it's just otherwise unworkable?
Bryan Childs
I'm really, really hoping
On Mon, Aug 22, 2011 at 7:10 PM, Jonathan Gordon jdgo...@gmail.com wrote:
I disagree with the first part of this change.
Time date doesnt make any more sense in settings than it does in
system (or info if you want to rename it). timedate isnt a
setting. And it does make sense to keep
On Mon, Aug 22, 2011 at 7:32 PM, Jonathan Gordon jdgo...@gmail.com wrote:
What has how you set it got anything to do with it being a setting or
not? Time does not magically change when you give your DAP to your
sibling.
No, but it changes when you enter another time zone. Or daylight
savings
Well, if the idea's to eventually remove the old order, or let it
expire as it becomes hard to support, it's better if it's a tag to
support the old order.
Another option would be to add it as an element of the BMP drawing tag
itself? The current way BMPs are drawn would mean I don't care about
On Thu, Jul 7, 2011 at 7:18 PM, Jonathan Gordon jdgo...@gmail.com wrote:
My intention is t force themers to fix their skins and adding another
param to the draw-image tags doesnt quite make it inconvinient enough.
Also a one line addition is far easier to tell users to add than to
change
On Thu, Jul 7, 2011 at 7:31 PM, Jonathan Gordon jdgo...@gmail.com wrote:
The whole point is to remove the incnsistancy in the draw oordering
with no option to change that (once this temp hack falls out of use).
Explicit ordering options wouldn't be inconsistent.
But again, why include a
On Thu, Jul 7, 2011 at 7:50 PM, Jonathan Gordon jdgo...@gmail.com wrote:
Because I dont know how long ill be able to suppoort the hack, and
doing it more permenantly means we are stuck with it which I dont
want. There is no real reason t frce the change now though
Isn't it better to force
On Thu, Jul 7, 2011 at 11:17 PM, Jonathan Gordon jdgo...@gmail.com wrote:
Not necessarily. Adding this tag means the old behaviour is deprecated
and could stop working any time. We (well I) wont support any skins
which rely on that deprecated behaviour.
Simply breaking the behaviour will
On Thu, Jul 7, 2011 at 11:38 PM, Jonathan Gordon jdgo...@gmail.com wrote:
OK, some time after the next release it will stop working...
That's exactly the kind of statement I'm arguing against. Will it
definitely be before the release after that? Why can't we have a
definite time, rather than an
The git page on the wiki seems to be more Why distributed version
control than specifically why git.
And while it does address some of the new things you can do with Git,
it was asked what will git give us? and that page doesn't answer
that nearly as well.
Who will benefit from a change to git?
On Fri, Jun 3, 2011 at 12:57 PM, Bryan Childs godea...@gmail.com wrote:
Is it *really* necessary that we do that here? There's SO much info out
there on the net about what it could do for you, that I don't see a lot of
point of trying to make it rockbox specific here, if there even IS anything
The nice thing about NN - Title.mp3 is that also works for filename
sorting, so doesn't require track number guessing. Track number
guessing basically won't to much good except in situations where the
numbers are ambiguous anyway, I think.
Just to chime in, I too like any button does it (as per the patch) and
make available the option to reverse the behaviour and leave the
default as USB file access.
I like this feature too.
On 3/23/2011 3:50 PM, Trevor wrote:
The C64 stuff has already been emulated, afaik. The two main formats I
really wanted was the VGM (Sega consoles and Arcade cabinets) and the
RSN (for the SNES) formats. Game boy sound has already been emulated
in rockboy, but it is laggy and it requires to
On 3/13/2011 5:19 AM, Jonathan Gordon wrote:
* plugins (We *could* build each .rock for multiple hardcoded sizes
which will work with the dynamic screen size build. android (as an
example) could download the .zip for the devices screen size which
would also include the cabbie theme)
I don't
On 3/13/2011 6:33 AM, Dominik Riebeling wrote:
Obviously that would be quite a lot of work ... on
the other hand, what plugins do we want to support on those platforms
at all? I don't see much plugins to be useful -- you can get tools and
games as native apps for the host.
That's more or less
And I agree with Dominik's reply to Paul. It would be great if RaaA
(where it made sense) to have a first run setup which grabbed device
relevant files but that is something to think about later (I tihnk
RBUtil for android would make an interesting GSoC project).
A native RBUtil that could
My personal expectation regarding database and file tree is if I click
on a file in the file tree or database, I expect it to resume from
whatever file I stopped playing no matter what I do to the disk (other
than of course removing that file).
With the database, if I insert and artist, then
On 3/7/2011 4:29 AM, pondlife wrote:
I think of a playlist as an entity in its own right. Whilst I may have
generated it from a directory or database query, I may then have manually
edited it (removing that one track I always skip...).
Once a manual edit has taken place, I'd expect it to be
Any chance we could get antialiased versions of the fonts used for color
targets in the default theme (and an appropriate update to the theme) to
go in with the patch?
On 2/24/2011 4:12 PM, Jonathan Gordon wrote:
Firstly its all touch targets not just RaaA. Secondly i agree with
pretty much all of it except the need for a STOP button. (long play is
fine)
I'm not sure long play is particularly intuitive or obvious. We mainly
only use it on other targets
On 2/13/2011 4:36 PM, David Hall wrote:
We're both talking about edge cases, the difference I see is that if the
priority order goes in as you state my described edge case needs a PC to
fix. If the priority order goes in as I ask both our edge cases can be
bandaged in the field with simple file
On 2/13/2011 5:10 PM, David Hall wrote:
The example I see presented here is just another in the infinite list of
possibilities. The difference is with my priority order a repair can be
made within rockbox, with the other way it can not. Neither address the
root cause of confusion and without
On 2/13/2011 5:20 PM, Jonathan Gordon wrote:
add the setting and kill the discussion.
What would the options be for this setting, exactly?
On 2/13/2011 5:26 PM, Jonathan Gordon wrote:
prefer embedded or prefer external
I'm not sure anyone's suggested that it should ever prefer embedded over
present individual images.
On 2/13/2011 5:29 PM, David Hall wrote:
That's exactly how it can be fixed.
It really doesn't matter if you find that practical or not. It is
doable, period. The priority scheme you propose is backed with nothing
other than edge cases, just as mine. They are equally valid concerns,
and
On 2/13/2011 5:59 PM, David Hall wrote:
On 02/13/2011 06:51 PM, Paul Louden wrote:
Touché. See what happens when you think about my concern instead of
steadfastly defending yours? ;)
I took your statement it cannot be fixed on the player for granted,
and didn't exam it, I'll admit
I see a significant amount more of this feature has been committed. When
exactly did it overcome the barrier of quite a few people objecting to it?
Didn't we have a relatively recent discussion about how if a decent
number of committers objected to a feature (as was the case with this
one)
On 2/8/2011 7:12 PM, Jonathan Gordon wrote:
What. The. FUCK!? you just had an hour long argument in IRC, you need
to start it all over again here?!
I started the discussion in IRC when I thought this email hadn't gone
through. It should show as having been sent *before* the discussion in
IRC.
On 2/8/2011 7:26 PM, Jonathan Gordon wrote:
On 9 February 2011 12:21, Paul Loudenpaulthen...@gmail.com wrote:
my apologies, you are indeed correct. I'll blame gmail for that.
It happens. I should've figured this would happen and sent another mail
or something. We don't need to rehash
On 1/4/2011 5:07 AM, sideral wrote:
[2] I've outlined some problems I've had with the bookmarking system in
this comment: http://www.rockbox.org/tracker/task/11748#comment37597
If I understand correctly, these are your problems with bookmarks:
* Bookmarks can only be found through the
On 1/4/2011 7:38 AM, Marcin Bukat wrote:
It's not a bug it's a feature :-)
Rockbox refuse to write data to disk if battery voltage drops below
dangerous level defined in target specific powermgmt-xxx.c file.
This is to prevent filesystem corruption which could occur if hard
power down happens in
On 1/4/2011 7:54 AM, sideral wrote:
Paul Loudenpaulthen...@gmail.com writes:
Basically it sounds like your objection to improving bookmarking is
it's buggy
I am sorry to see that you respond to what my objection sounds like,
rather than responding to the individual arguments I've made. I
On 12/26/2010 5:51 PM, sideral wrote:
My experience with the feature tells me that this is a nonissue. Even
with resume on automatic track change enabled, later chapters of an
audiobook are virtually never resumed in the middle simply because no
resume point has been stored for them. This is
On 12/26/2010 6:21 PM, sideral wrote:
Here's another thought. As I mentioned before, I view the autoresume
position as a per-track feature (hence, it has its place in the
database), whereas bookmarks take snapshots of playlists. Arguably,
what you want for your audiobooks is a bookmark, not a
On 12/22/2010 2:34 AM, Marcin Bukat wrote:
Paul, the discussion came to the stage where without proof-of-concept
patch (implementing your idea how this should work) it is pointless.
My personal feeling is that solution proposed by sideral is
overcomplicated and will interfere with (for example
On 12/21/2010 5:22 PM, Mike Giacomelli wrote:
If theres a lot of use cases, and the ones the patch currently implements are
implemented well, it should be committed and the additional cases handled in
future patches.
The main problem is that the
On 12/16/2010 4:59 AM, sideral wrote:
Nonetheless, under the premise of simplifying configuration you are
pushing to remove two features I regard as important (prevent skip to
0:00; autoresume on automatic track change), without allowing them to be
enabled by way of configuration.
You mention
On 12/16/2010 7:29 AM, sideral wrote:
You disable the autoresume-on-track-change feature.
But in practice, you will notice that, typically, the later chapters do
not have a resume point anyway, so there will be no point in disabling
that feature.
This is one of my points. The idea as I've
On 12/15/2010 7:19 AM, sideral wrote:
* Prevent skip back to track intro?
-- Never (other options would be: only for resumable tracks; or,
always)
Note: the last config option is currently named Allow skip back to
intro (with suitably inverted naming of the options, of course). Any
On 12/15/2010 9:29 AM, Marcin Bukat wrote:
We have option to set recording dir, starting browser dir etc. I don't
see any problem to add another 'special' configurable dir.
Marcin
Neither of those two options create a situation where two files in the
same playlist can end up transparently
On 12/15/2010 12:10 PM, Al Le wrote:
On 15.12.2010 17:32, Paul Louden wrote:
The starting folder sets where the browser *always* goes.
This is not uncoditionally true. If you enable the follow playlist
option the file browser will start in other directory than specified
by starting folder
On 12/15/2010 12:41 PM, Thomas Martitz wrote:
IIRC the playlist catalog only picks up playlists in /Playlists. Also
some browsers in the setting except the configuration files in fixed
dirs. Not sure if that counts.
Best regards.
Again those are just listing files in a specific folder
I think my biggest concern about this feature is that it seems
engineered/focused on the use case having a playlist of multiple files
the user wishes to store independent resume points within which seems
to me not the most common use case for automatic resuming.
I would expect the general use
On 12/15/2010 1:20 PM, Al Le wrote:
On 15.12.2010 19:15, Paul Louden wrote:
I thought follow playlist sets where you end up when you press
select in the WPS. Does it also change where you end up if you
choose Files from the main menu?
No, of course not. But if you go to the browser from
On 12/15/2010 1:31 PM, David Hall wrote:
If the test for inclusion includes can a user abuse the freedoms
Rockbox grants to do stupid things? shop might as well be packed up, IMHO.
I think though that this isn't quite the same. There's a difference
between allowing a user to explicitly do
On 12/15/2010 3:35 PM, David Hall wrote:
Which is why I think simply replicating what Sansa does (podcast
specific special folder) is the best solution. No additional
configurations / options, and one can not place files from said folder
into a mixed playlist w/o explicitly choosing to do so.
On 12/15/2010 3:51 PM, Thomas Martitz wrote:
I think it's definitely better than requiring the users to set up
complicated file filters. And it's seems be a solution somewhat
accepted by both users and manufactures.
As long as it doesn't try to resume playback in every file in my
On 12/15/2010 6:01 PM, Alex Parker wrote:
I can only reiterate that I am very against being forced to put items into a
specific directory to get a feature to work. A large part of why I use Rockbox
is being able to organise my files as I want, not as someone else has decided I
should.
To be
At the request of IrcNick Soap, I'm going to write my counter proposal.
I really don't want this to descend into a his idea vs my idea kind of
situation. What I'd like us to do is try to decide as a group what sort
of playback situations auto-resume should address (playlist full of half
On 12/15/2010 10:25 PM, Jonathan Gordon wrote:
A counter proposal doesnt mean anything. If sideral wants to
incorporate your ideas that is up to him, but while there is 1 mostly
finished implementation and one you should do it my way, the
implementation wins as far as I'm concerned.
You
On 12/14/2010 4:29 AM, sideral wrote:
There hasn't been much discussion on this aspect yet, but it's a good
discussion to have, so here we go. :) You're correct, the configuration
is probably the most complex part of this whole feature.
Generally speaking the ideal is to add as few new
On 12/4/2010 12:37 PM, Rocker wrote:
If you want to talk nonsense perhaps you should read your own post!
BTW:
I have donated to Rockox on several occasions. Way back before you were
involved in the project!
Bakc when the Voice UI was still a dream of mine!
I guess that was nonsense too right?
On 11/16/2010 11:53 PM, Jonathan Gordon wrote:
1) Main menu playlists - That should open the playlist catalog
instead of the menu you get now
2) context menu on Main menu playlists should open the current menu
3) the default action on .m3u files should be to open it in the viewer
4) the
On 11/17/2010 1:38 AM, Marcin Bukat wrote:
3) the default action on .m3u files should be to open it in the viewer
I *always* use m3u files to play whole album in order. It is stored in
the same dir as the files. Such change would break this badly.
wodz
Why do you need an m3u file to play a
On 11/17/2010 1:40 AM, ra...@mail.com wrote:
1) don't top post
2) use the database for that.
Oh, sorry. What I meant was that it would be nice to have playlists
(stored as files) based upon the database structure and not the
filessytem (which m3u is). Those playlist files are then
On 11/9/2010 10:22 AM, Alex Parker wrote:
I like the general idea, but the way it switches between what the
numbers mean depending on how many digits you use seems like it could
be confusing to me. Having 90 = 130 is a little odd, and if I see I
can type 90 to have 1 minute 30, I would
On 11/9/2010 10:15 AM, Peter Lecky wrote:
Hi all,
Can we again discuss patch FS#10891? it seems that there are users who
would like to have it in RB (see the discussion).
Peter
It might be good to clarify what the patch is about here, rather than
asking everyone on the mailing list to also
On 11/9/2010 3:20 PM, Jonas Häggqvist wrote:
On 09-11-2010 18:35, Marcin Bukat wrote:
BTW. Aren't viewers bind to particular file extensions? If so I
wouldn't bother to do
any more advanced detection. If someone rename .bmp to .jpg it's
his/her problem.
The thing is that the image viewer
On 10/26/2010 6:16 AM, Thomas Martitz wrote:
I'd propose to make the change for all and force people to adapt the
missing parts finally (the absolute point mode is not a new thing at all)?
So wait, the idea is to enable this mode so that you can force other
people to do the work of adapting
On 10/26/2010 6:27 AM, Thomas Martitz wrote:
On 26.10.2010 13:20, Paul Louden wrote:
I would maybe do it myself if I had access to the devices. And I bet
I'm not the only one the switch-over is needed badly.
Isn't this purely touchscreen+UI changes? As in, stuff that could be
done
On 10/26/2010 6:46 AM, Thomas Martitz wrote:
On 26.10.2010 13:40, Paul Louden wrote:
Well, you cannot sensibly use the sim for this because the mouse is a
terrible simulation of the thumbs, and because there's generally a
huge DPI mismatch between PC and device displays.
You need to see
On 10/26/2010 5:15 PM, Thomas Martitz wrote:
As if the grid mode was usable. In my opinion the absolute point mode
is much more usable even if some screens are not converted.
Is there a screen that doesn't work with grid mode and cannot be used,
or is this hyperbole and do you really just
On 10/26/2010 5:33 PM, Thomas Martitz wrote:
A first draft is maybe possible, but if it can't be tested if it's
usable it might end up being as bad as the grid mode (if that's even
possible). I wouldn't want to commit first drafts too.
Since the grid mode actually works on every screen, and
On 10/26/2010 5:40 PM, Antony Stone wrote:
I find this question hard to manage - isn't resolution a quantity, which is
measured in units of DPI?
How can screens of different DPI have the same resolution?
DPI means dots per inch. Resolution is an absolute measure of dots. A
1280x720 16 foot
On 10/26/2010 5:49 PM, Thomas Martitz wrote:
If I remember correctly, the idea of overriding settings and forcing
grid mode in screens that aren't adopted has been rejected in the
past. In this case it's a all or nothing decision.
It's certainly not a NoDo, so rejected in the past doesn't
On 10/26/2010 6:04 PM, Thomas Martitz wrote:
You seem mixing up Taking DPI into account for multiple versions of
the design with Taking DPI differences between the design target and
design test machine. That's not the same.
So the design test machine is somehow magically different than any
On 10/26/2010 6:22 PM, Antony Stone wrote:
On Wednesday 27 October 2010 at 00:45, Paul Louden wrote:
From http://en.wikipedia.org/wiki/Display_resolution -
the use of the word resolution here is a misnomer, though common
resolution properly refers to the pixel density, the number of pixels per
On 10/26/2010 6:26 PM, Thomas Martitz wrote:
RaaA has shown that the grid mode makes Rockbox appear broken as a
whole, while a few broken screens appears as ah, this particular part
isn't done yet. This is what the various articles, blogs and comments
have shown.
From LWN:
Running the
On 10/26/2010 6:54 PM, Thomas Martitz wrote:
As for your other ideas. I find improving the grid mode in any way is
a waste of human resources, which we don't have as a volunteer effort
project with 2 or maybe 3 people caring about UI at all (and with
caring I mean caring enough to spend time
From IRC:
What I'm asking is, if the goal is to make the screens bad so that
developers want to fix them, wouldn't leaving them in grid mode when the
rest of the UI is absolute also accomplish this pressure?
Why is very bad not good enough to accomplish your goal, but gone
is? I would think
On 10/26/2010 7:18 PM, Jonas Häggqvist wrote:
1. Absolute Point mode is the default.
2. Screens which have not yet been adapted to absolute point mode
revert to Grid mode with a visual cue (an overlaid 1 or 2px grid,
maybe a splash)
Just to be explicitly clear (I'm sorry if it was
On 10/12/2010 3:02 AM, Marcin Bukat wrote:
I don't like discontinuity in release numbering. For me such practice
is pure marketing.
Marcin Bukat
Release numbering is pure marketing in the first place. 3.7 doesn't
mean anything useful other than it came after any number lower than this.
A
On 10/12/2010 9:28 AM, Marcin Bukat wrote:
That's exactly my point - version number is to place particular
release in some chronological order nothing more.
This is patently not true. If chronological order were the only purpose,
there would be no reason not to just use the release date,
On 10/11/2010 12:43 PM, David Hall wrote:
I also believe that the +2 threshold should initially be a tentative
one, subject to later review by the RSB. The ultimate goal, IMHO,
should be an improvement to the overall happiness of the developer
community.
I can envision a cultural divide where
1 - 100 of 520 matches
Mail list logo
