Follow-up Comment #4, patch #3804 (project freeciv):
Yes, more abstraction makes sense, and certainly expands the range of what
ruleset authors would be able to do. is_flying_unit() and
is_flying_unit_class() are clearly not in the spirit of gen_move.
dai_choose_attacker_air() would need to
Follow-up Comment #1, patch #3808 (project freeciv):
Rather than being an absolute measure of the ability of the threatening unit
to get away, could this be a measure of difference between threatening unit
and auto-attacking unit? For example, in the default ruleset, untired
Horsemen should
Follow-up Comment #6, patch #3804 (project freeciv):
Heh, if you're happy with a less complex patch even if it's not known to be
correct for any imagined use cases, that makes it relatively easy. I'll
implement with two bitvectors (embark, disembark) that work like targets, and
in wipe_unit just
Follow-up Comment #3, patch #3808 (project freeciv):
My apologies: I misunderstood the intent. My concern is that I would like
autoattack to do *something*, even slow units autoattacking fast units. Not
having autoattack happen mid-turn before the attacking unit actually attacks
improves the
Follow-up Comment #8, patch #3804 (project freeciv):
Great. Thanks for the confirmation.
As for the examples from the Alien ruleset: my apologies if I implied such
changes should be made. I selected it as an example only because it has two
different semantics for unreachable units as well as a
Follow-up Comment #10, patch #3804 (project freeciv):
I've encountered a strangeness during the implementation: a difference in
behaviour of unit.c:can_unit_unload() when called from the client and the
server. I am using BV_ISSET(unit_type(pcargo)-disembarks,
uclass_index(unit_class(ptrans))) to
Follow-up Comment #12, patch #3804 (project freeciv):
The obvious is what needed stating. Thanks for the pointers: even worse, I
had not even defined these bitvectors in packets.def, so that regardless of
the fact that I wasn't sending them, they could not be sent.
Follow-up Comment #15, patch #3804 (project freeciv):
Moving the units to a separate patch seems perfectly reasonable, and I'm
fairly unconcerned if that ever lands: the units and vector definitions are
only set for testing, and may not actually work well in play.
Shall I also separate out the
Follow-up Comment #1, bug #20685 (project freeciv):
Aside from Ubuntu 11.10 (Oneiric), all current Ubuntu packages match the
Debian packages, and so if there is a desire for a change, it's probably
better to ship that change through Debian (although I'll upload something
directly if someone
URL:
http://gna.org/patch/?3815
Summary: Provide information about unit class nativity in
terrain help
Project: Freeciv
Submitted by: persia
Submitted on: Sat 30 Mar 2013 03:46:16 PM GMT
Category: client
Follow-up Comment #17, patch #3804 (project freeciv):
Thanks for the clarification. If the implementation model is acceptable,
that's enough for me, and I'll keep rebasing it against trunk locally until it
seems safe to apply. If anyone has trouble testing the patch currently
attached due to
to prepare and test a patch removing all of this (and
thereby simplifying ruleset documentation), but only if there isn't some
reason to keep them that escapes me.
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo
URL:
http://gna.org/patch/?3819
Summary: Generalise helptext for AttFromNonNative and Marines
Project: Freeciv
Submitted by: persia
Submitted on: Sun 31 Mar 2013 04:44:58 AM GMT
Category: client
Priority:
On Sat, Mar 30, 2013 at 10:02:02PM +0200, Marko Lindqvist wrote:
On 30 March 2013 18:42, Emmet Hikory wrote:
For terrain.ruleset, there are [options] and [parameters] sections.
Do most of these still serve useful purposes? From a quick look at the
code and a bit of testing, I would
On Sun, Mar 31, 2013 at 10:50:58AM +0300, Marko Lindqvist wrote:
On 31 March 2013 08:43, Emmet Hikory wrote:
On Sat, Mar 30, 2013 at 10:02:02PM +0200, Marko Lindqvist wrote:
On 30 March 2013 18:42, Emmet Hikory wrote:
[options]
may_road:
may_irrigate:
may_mine
URL:
http://gna.org/patch/?3821
Summary: Drop terrain options
Project: Freeciv
Submitted by: persia
Submitted on: Sun 31 Mar 2013 10:14:42 AM GMT
Category: general
Priority: 5 - Normal
Follow-up Comment #3, patch #3820 (project freeciv):
Indeed. There's little point to optimisations that don't :) Improved patch
attached.
(file #17625)
___
Additional Item Attachment:
File name:
URL:
http://gna.org/bugs/?20691
Summary: road_superhighway_trade_bonus in terrain.ruleset
doesn't work
Project: Freeciv
Submitted by: persia
Submitted on: Sun 31 Mar 2013 11:21:03 AM GMT
Category: rulesets
Follow-up Comment #1, bug #20691 (project freeciv):
For the future, this should just be removed entirely. The attached patch does
this on trunk, but will require a change to the capabilities string as the
network protocol has changed.
(file #17627)
Follow-up Comment #2, patch #3805 (project freeciv):
I think it does. While I have no direct experience, the information I
have found seems to indicate that civ1 has no paratroopers and civ2 requires
the destination to be Land. The best reference that mentions both of these
that I could
URL:
http://gna.org/bugs/?20695
Summary: Disaster nreq processing causes disasters mostly not
to happen
Project: Freeciv
Submitted by: persia
Submitted on: Mon 01 Apr 2013 03:06:35 AM GMT
Category: general
Follow-up Comment #1, patch #3816 (project freeciv):
This didn't get set to In Progress for a bit, and seemed easy enough, so I
prepared a sample patch. This patch depends on patch #3815, but if the
rejected client/helpdata.c hunk is dropped, will apply to trunk. If there is
a reason to apply
Follow-up Comment #2, patch #3815 (project freeciv):
I didn't mean to rush processing of this patch with the comment in patch #3816
, rather I just wanted to provide a hint for testing, as when I checked the
submitted patch against revision 22638 it didn't apply cleanly. Anyway, I
believe that
Follow-up Comment #2, bug #20695 (project freeciv):
Only for nreqs for effects, which I would expect to be removed in the spirit
of having one correct function to do each thing that needs doing. The place
it might be would be sanity_check_req_set, but that doesn't seem to be aware
of the idea of
Follow-up Comment #4, patch #3805 (project freeciv):
This updated patch is controlled by game.info.paradrop_to_transport. This is
disabled in most rulesets, but enabled in experimental for testing. If the
commiter doesn't feel it appropriate to enable it in experimental, please
change TRUE to
that are important
if porting patches to stable branches for accurate testing?
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Follow-up Comment #2, patch #3817 (project freeciv):
Not so concretely or specifically, but ruleset authors may model shore
bombardment by not allowing the unit to take over the city (set either
UTYF_CIVILIAN or fail to set UCF_CAN_OCCUPY_CITY). In all shipped rulesets,
unit classes identifed as
Follow-up Comment #5, bug #16164 (project freeciv):
In the case where occupychance 0, should a fueled unit with autoattack still
autoattack from a refueling point? If it does, should it return to base
immediately thereafter in the event it does occupy, or should it avoid
autoattacking in the
Follow-up Comment #6, patch #3805 (project freeciv):
Oops, right. Updated patch (transport-paradrop+option+docs.patch) includes
that.
(file #17654)
___
Additional Item Attachment:
File name: transport-paradrop+option+docs.patch Size:8 KB
that implementing the reqs for canals doesn't require
first allowing disjunctive requirement specification (which has it's own
large set of dependencies).
Thanks for your help.
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https
On Tue, Apr 02, 2013 at 03:27:26PM +0300, Marko Lindqvist wrote:
On 2 April 2013 12:53, Emmet Hikory wrote:
So, the solution would be to have some road compatibility check in
map.c:tile_move_cost_ptrs(). There are two methods to do this in the
ruleset that seem to have precedent
behavioural difference), and expect to publish to GNA within
the next several hours.
B) Road compatibility
Design finalisedi (see other thread): should be ready by Thursday at the
latest, but probably tomorrow.
Would either of these need to wait for 2.6?
--
Emmet HIKORY
Follow-up Comment #7, bug #16164 (project freeciv):
Bombers mix two concepts that may affect autoattack:
1) They are OneAttack units, which means that if they autoattack, they cannot
then either move or attack again, rendering the unit useless for human control
that turn.
2) They are fueled
URL:
http://gna.org/patch/?3826
Summary: Allow bases on city tiles
Project: Freeciv
Submitted by: persia
Submitted on: Tue 02 Apr 2013 04:29:57 PM GMT
Category: general
Priority: 5 - Normal
Follow-up Comment #2, patch #3826 (project freeciv):
Aha! revision 21864. Sorry about that.
allow-bases-in-cities+fixed-rulesets.patch should restore the prior behaviour
properly, unless I missed something between 21864 and 22649 that further
adjusted the values.
(file #17658)
URL:
http://gna.org/patch/?3829
Summary: Allow compatible roads
Project: Freeciv
Submitted by: persia
Submitted on: Wed 03 Apr 2013 11:11:55 AM GMT
Category: general
Priority: 5 - Normal
URL:
http://gna.org/patch/?3830
Summary: Change shore bombardment model to use nativity
rather than UMT_*
Project: Freeciv
Submitted by: persia
Submitted on: Wed 03 Apr 2013 12:30:06 PM GMT
Category: general
URL:
http://gna.org/patch/?3831
Summary: Remove obsolete MOVE_COST_RIVER definition
Project: Freeciv
Submitted by: persia
Submitted on: Wed 03 Apr 2013 04:59:12 PM GMT
Category: general
Priority: 5 -
Follow-up Comment #6, patch #3820 (project freeciv):
My response to my own itchiness had been to add Allow IgTer movement scaling
based on unit type to my ToDo, figuring that I would be able to resolve any
odd feelings as part of that. Unfortunately, the way that
pf_tools.c:igter_move_unit()
URL:
http://gna.org/patch/?3832
Summary: Allow BaseFlag and RoadFlag in reqs lists
Project: Freeciv
Submitted by: persia
Submitted on: Thu 04 Apr 2013 06:28:02 AM GMT
Category: general
Priority: 5 - Normal
URL:
http://gna.org/bugs/?20710
Summary: Editor can't place Maglev in alien or experimental
rulesets
Project: Freeciv
Submitted by: persia
Submitted on: Thu 04 Apr 2013 07:58:13 AM GMT
Category: rulesets
URL:
http://gna.org/patch/?3833
Summary: Consider base dependencies for bases
Project: Freeciv
Submitted by: persia
Submitted on: Thu 04 Apr 2013 08:47:27 AM GMT
Category: general
Priority: 5 - Normal
Follow-up Comment #12, patch #2265 (project freeciv):
Assuming appropriate client interface, one means to model it would be:
Donor loses unit when ACTIVITY_IMMIGRATE is selected (assuming AddToCity,
etc.).
Receiver has interface choice in city dialog which may be acted upon at any
time
Follow-up Comment #4, bug #18013 (project freeciv):
This can be done in rulesets since the application of patch #3264 . Add the
AttackNonNative flag to the Land class, and then add the
Only_Attack_Native to any Land units that you *don't* want to be able to
attack ships. If you only want units
URL:
http://gna.org/bugs/?20711
Summary: Diplomats don't respect targets vector
Project: Freeciv
Submitted by: persia
Submitted on: Thu 04 Apr 2013 02:09:16 PM GMT
Category: general
Severity: 3 - Normal
Follow-up Comment #2, bug #20711 (project freeciv):
Makes sense. In that case, I'll call a feature, but it's horridly incomplete
as-is, because it needs vectors set in all the rulesets, review and
adjustments to contact rules (who can contact whom when and how: Creating a
satellite unit and
centers such that
the AI then notices the improvement will give a bit more food, prompting
the building, which then prompts the AI to generate farmland, which just
feels way too heavy-handed to me).
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev
Follow-up Comment #2, patch #3832 (project freeciv):
Indeed, this doesn't help as-is, but I thought it was a good chunk to commit
while I was learning how the custom flag feature worked. That said, if you
believe it to be a 2.6 feature, I'll not rush on that, as it becomes obsolete
with extras.
Follow-up Comment #3, patch #3832 (project freeciv):
I realise on re-reading my last post that I may not have outlined why this
might be interesting at all. Apologies for that.
The ultimate goal was to be able to have different types of requirements for
move_cost=2 roads, depending on terrain,
URL:
http://gna.org/patch/?3835
Summary: Negated requirements sanity checking improvements
Project: Freeciv
Submitted by: persia
Submitted on: Fri 05 Apr 2013 08:22:55 PM JST
Category: general
Priority: 5
URL:
http://gna.org/patch/?3836
Summary: Documentation update for requirements
Project: Freeciv
Submitted by: persia
Submitted on: Sat 06 Apr 2013 01:48:56 AM JST
Category: docs
Priority: 5 - Normal
to do it welcome.
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Follow-up Comment #1, patch #3836 (project freeciv):
My apologies: apparently I failed to test that sufficiently. Please find an
updated patch that doesn't have the silly typos.
(file #17685)
___
Additional Item Attachment:
File name:
Follow-up Comment #3, bug #20710 (project freeciv):
Thinking about this in more depth, I'm less certain it works quite as well as
I thought. While informing autosettlers about maglev needing road seems to
make them make more roads, I think they do it for the wrong reasons: they are
looking at
;
Is there anything I can do with comments or other indicators to help
indicate to translators that the paired strings are intended to be negated
representations of each other, or is all this lost when the strings are
extracted for translation?
--
Emmet HIKORY
Follow-up Comment #5, bug #20710 (project freeciv):
Your patch is ideal for the editor aspect. Autosettlers is more complicated,
so better deferred to another bug or issue.
___
Reply to this item at:
http://gna.org/bugs/?20710
Follow-up Comment #19, patch #3804 (project freeciv):
I've rebased this on revision 22685, and split into three patches to make it
easier to read each and test separately. First is refactor-wipe-unit.patch,
which does just that: using unit_list structures to avoid drowning count
issues or
Follow-up Comment #2, patch #3833 (project freeciv):
So updated. It applies to revision 22685 and revision
22685+RecursiveRoads.patch equally well.
(file #17698)
___
Additional Item Attachment:
File name:
Follow-up Comment #3, patch #3836 (project freeciv):
Not being a native speaker makes you more qualified to identify potential
confusions. While ...on a tile in the city is gramatically correct, that it
is potentially confusing significantly increases the chances that translations
will be poor,
Follow-up Comment #2, patch #3835 (project freeciv):
Backport patches attached. Looking through them, I wonder if the
local_reqs_of_type[] checks in S2_4 and trunk should be wrapped in a
conditional like the reqs_of_type[] checks that follow. In the absence of
such a conditional, it is
Follow-up Comment #5, patch #3836 (project freeciv):
If we agree on radius than so shall it be :)
Regarding 0 and 1, rulesets load fine with those values. Testing, it
seems that they disregard them, so whether one has 0 or 1 for negated,
one ends up with an effect equivalent to FALSE. For this
Additional Item Attachment, patch #3836 (project freeciv):
File name: reqs-docs-better.patch Size:6 KB
___
Reply to this item at:
http://gna.org/patch/?3836
___
Message sent via/by
URL:
http://gna.org/patch/?3837
Summary: Unify UCF_ATT*NON_NATIVE and relevant type flags
Project: Freeciv
Submitted by: persia
Submitted on: Sun 07 Apr 2013 09:27:23 PM JST
Category: general
Priority: 5 -
Follow-up Comment #2, patch #3837 (project freeciv):
And excitingly, the files matched precisely before and after the patch. I'll
be sure to also check this way when I do not expect a behavioural difference.
___
Reply to this item at:
Follow-up Comment #9, patch #3836 (project freeciv):
If there is an explicit preference, it would be good to have it mentioned in
CodingStyle. I also prefer space at the end of the line, although many of the
codebases I've worked with have the space at the beginning. My assumption is
that space
Follow-up Comment #4, patch #3835 (project freeciv):
Unless refactored, the code can't complain about desert+not oceanic, so
that will remain. In practice, such redundancies will slow processing the
requirements vector, but should not otherwise impact the game. I have a
branch where I'm playing
Follow-up Comment #7, patch #3835 (project freeciv):
I haven't reviewed all of effects.c, but there's a number of calls into it in
various places that aren't AI-specific (like from combat), and the few parts I
inspected tend to call into requirements.c at a much lower level than the reqs
Follow-up Comment #8, patch #3835 (project freeciv):
And when I check what precisely needs doing for S2_4 and trunk patches to
ensure that !oceanic+grassland and land+!forest are both acceptable, I
discover that I was indeed reading the code wrong. These work with the
patches previously attached
Follow-up Comment #6, patch #3323 (project freeciv):
What part of this original request cannot currently be done in trunk? I
believe the drivers have been completed, if perhaps not as part of this
ticket.
Example ruleset definition using the working City range:
[base_gold_mine]
name = _(Gold
Follow-up Comment #3, patch #3332 (project freeciv):
Is this still needed? Can one use the negated value in reqs{} vectors to
meet the original intent of this patch?
___
Reply to this item at:
http://gna.org/patch/?3332
Follow-up Comment #3, patch #3756 (project freeciv):
Could some of this be integrated with the concept in patch #2721? Provide,
say, 5 keystrokes for players to allocate (e.g. EFIMR), which the ruleset
author would then define as different types in the ruleset and provide test
labels for use in
URL:
http://gna.org/patch/?3839
Summary: Low hanging nativity fixes
Project: Freeciv
Submitted by: persia
Submitted on: Mon 08 Apr 2013 04:58:06 PM JST
Category: general
Priority: 5 - Normal
URL:
http://gna.org/patch/?3841
Summary: Add strings for negated requirements
Project: Freeciv
Submitted by: persia
Submitted on: Mon 08 Apr 2013 11:03:29 PM JST
Category: client
Priority: 5 - Normal
Follow-up Comment #4, patch #3832 (project freeciv):
Updated patch applies over patch #3841 and includes the !preq-negated
documentation for baseflag/roadflag requirements. Also includes the Adjacnet
fix (inherited from rebasing above patch #3836).
(file #17717)
URL:
http://gna.org/patch/?3842
Summary: Ensure use of boolean TRUE/FALSE in reqs
specifications
Project: Freeciv
Submitted by: persia
Submitted on: Tue 09 Apr 2013 03:34:15 AM JST
Category: rulesets
Follow-up Comment #2, patch #3842 (project freeciv):
Thanks for the GNA instruction and adjustment.
Your logic is both more concise and absolutely correct: I missed the
implications of the SECFILE_RETURN_VAL_IF_FAIL check.
___
Reply to
Follow-up Comment #3, patch #3842 (project freeciv):
An updated patch implementing pepeto's more concise expression (Thanks!).
This has passed the same set of tests applied to the original patch, with the
same results.
(file #17722)
___
#3815 (which I expect to provide in the next 12 hours). If I
am incorrect, and anyone is waiting on something specific from me in
order to proceed with something, please let me know, and I'll try to
address it while I have access.
Thank you.
--
Emmet HIKORY
Follow-up Comment #5, patch #3815 (project freeciv):
The attached files provide one possible adjustment to the static helptexts for
S2_4 and trunk. In trunk, I did not remove the phrases Planet's radiation
makes it impossible for Earthly organisms to survive here., Burrowing units
are unable to
Follow-up Comment #10, patch #3835 (project freeciv):
I'm inclined to agree that survives shouldn't matter (the code was written
to compare the code structures, rather than with careful semantic analysis).
That said, I can think of a couple cases where one might use this:
a) Creating a
Follow-up Comment #20, patch #3804 (project freeciv):
Update to the experimental ruleset patch to take into account changes in
README.ruleset_experimental after revision 22705.
(file #17733)
___
Additional Item Attachment:
File name:
Follow-up Comment #4, patch #3837 (project freeciv):
Makes sense. I'll prepare some similar branches for S2_4 and S2_3, with less
focus on nativity, but rather focusing on ensuring that there aren't too
many assumptions preventing defining e.g. ships with embedded marine
components or similar on
Follow-up Comment #3, patch #3829 (project freeciv):
Roads integrate with themselves by forced insertion of the road for which the
vector is being constructed into it's own vector immediately following
initialisation (and before reviewing the integrates field) in ruleset.c and
packhand.c.
Or,
. using another vector to determine
targets or similar).
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
cannot protect themselves from the bombardier). That
said, I'll implement it with a different flag: do you think it should be
UTYF, UCF, or UCF+UTYF exception?
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org
Follow-up Comment #4, patch #3829 (project freeciv):
Err, rather, the code is just confusing: suggestions for comments to avoid
confusing future readers welcome.
Rulesets add compatible roads to the integrates vector.
load_ruleset_terrain():
Adds road being loaded to the (server-side)
Follow-up Comment #7, patch #3829 (project freeciv):
Ah, good point. Perhaps rather than adding roads to the integrators list at
parse time, it ought just set the bitvector (redundantly setting it causes no
issue, and checking that it is set likely usually wastes cycles). Once the
iterates
Follow-up Comment #4, patch #3826 (project freeciv):
The attached patch should address all comments, and applies against trunk.
Thanks for pointing out how roads/bases are removed when terrain is changed.
For some reason, in the initial testing, I wasn't successful in restricting
bases in
Follow-up Comment #3, patch #3830 (project freeciv):
Updated patch attached restoring original behaviour. The sea unit in harbor
case gets adjusted anyway because of BadCityDefender (but, yes, this shouldn't
be conflated). The ground unit defending against air unit case made fp=2
ground units
Follow-up Comment #23, patch #3804 (project freeciv):
Updated functional patches to use try_to_save_unit() instead of
unit_can_be_saved(). Once applied, this ticket should be closed, without the
unit patch.
(file #17765, file #17766)
___
Follow-up Comment #5, patch #3837 (project freeciv):
Patch attached for S2_3. The pf_tools functions are not adjusted, as the
nature of the flags in question don't have much meaning for UMT_LAND units
(which restriction is imposed by pft_fill_parameter()).
For S2_4, I'm much less certain of the
Follow-up Comment #2, bug #20744 (project freeciv):
try_to_save_unit() doesn't need to take the helpless argument for S2_4, as
this only exists as a base for future extension, but leaving it there should
cause no problem and it may be helpful to have the S2_4 and S2_5 functions be
identical to
Follow-up Comment #7, patch #3837 (project freeciv):
Then I'm just confused, and this should work for S2_4.
(file #17769)
___
Additional Item Attachment:
File name: S2_4-use-can_attack-foo-functions-more.patch Size:2 KB
Follow-up Comment #9, patch #3829 (project freeciv):
This is why the road is also self-added to the integrators road_type_list in
packhand.c:handle_rulesets_ready() (as part of the same iteration used to
process hiders): by not forcing self in the bitvector, the implementation is
entirely
Follow-up Comment #6, patch #3826 (project freeciv):
Updated patch adjusts base destruction to not be player-specific (so that
players may build cities on city-compatible bases they could not build
themselves, and keep the base), as well as removing any city-incompatible
roads when founding a
URL:
http://gna.org/patch/?3854
Summary: Consider nativity for is_square_threatened()
Project: Freeciv
Submitted by: persia
Submitted on: Sat 20 Apr 2013 06:32:27 AM JST
Category: general
Priority: 5 -
Follow-up Comment #1, bug #20587 (project freeciv):
Oops. Found this after posting patch #3854
Although closely related, I'm not sure this ticket is entirely closed by that
patch though: while it does remove the land restriction, it does not include
the deeper analysis that might be useful to
Follow-up Comment #5, patch #3830 (project freeciv):
I understand why an attacking unit might get reduced firepower when attacking
a non-native tile. I don't understand why this reduction fails to apply
depending on the defending unit: I would expect it to apply in all cases, as
it ought
URL:
http://gna.org/patch/?3856
Summary: Add nativity check for find_closest_city()
Project: Freeciv
Submitted by: persia
Submitted on: Sat 20 Apr 2013 08:55:07 AM JST
Category: general
Priority: 5 -
URL:
http://gna.org/bugs/?20747
Summary: Units in nested transport considered defensive units
Project: Freeciv
Submitted by: persia
Submitted on: Sat 20 Apr 2013 01:48:01 PM JST
Category: general
Severity:
1 - 100 of 623 matches
Mail list logo
