Ulrike Uhlig writes:
> On 26.09.19 08:03, Ansgar wrote:
>> What does stop the recommendations to be outdated in a year or two?
>> Given the long and slow process to gather them, there will probably be a
>> long and slow process to change them; that discourages actually changing
>> them (too high
Hi Holger,
On 24.09.19 15:21, Holger Levsen wrote:
> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>> For several of these recommendations if I cannot get consensus, I will
>> call for a GR myself.
>
> TBH, I'm not thrilled to read this, though of course it's in your rights
> to
Hi!
On 26.09.19 08:03, Ansgar wrote:
> Enrico Zini writes:
>> On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:
>> Also, as over time my packaging practices have become outdated, I have
>> found it both difficult and frustrating to engage on a quest for
>> figuring out "how does one
Enrico Zini writes:
> On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:
>> But I think having recommendations available when people are new, when
>> they are looking for what to do when writing new tools, when the trade
>> offs don't matter, is really important. I think it's important
On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:
> But I think having recommendations available when people are new, when
> they are looking for what to do when writing new tools, when the trade
> offs don't matter, is really important. I think it's important enough
> that it's worth
Mo Zhou writes:
> Is the recommendation working well under most circumstances?
> I mean, different teams have already made their conventions
> at these point, such as go team, rust team, nvidia team, etc.
> These team designed "local" recommendations always adapt
> well with special property of
> "Mo" == Mo Zhou writes:
Mo> As you said, recommendations are merely recommendations. Debian
Mo> developers customed to their own workflow may not necessarily
Mo> follow the recommendations. However, the recommendation makes a
Mo> difference for newbies or newcomers, if
On 2019-09-25 07:15, Sam Hartman wrote:
>> "Scott" == Scott Kitterman writes:
>
> >> For several of these recommendations if I cannot get consensus, I
> >> will call for a GR myself.
>
> Scott> What do you think is important enough in this area that you
> Scott> would rather
On September 24, 2019 11:15:33 PM UTC, Sam Hartman wrote:
>> "Scott" == Scott Kitterman writes:
>
> >> For several of these recommendations if I cannot get consensus, I
>>> will call for a GR myself.
>
>Scott> What do you think is important enough in this area that you
>
On 2019-09-25 05:32, Bernd Zeimetz wrote:
> On 9/24/19 3:21 PM, Holger Levsen wrote:
>> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>>> For several of these recommendations if I cannot get consensus, I will
>>> call for a GR myself.
>>
>> TBH, I'm not thrilled to read this, though
> "Scott" == Scott Kitterman writes:
>> For several of these recommendations if I cannot get consensus, I
>> will call for a GR myself.
Scott> What do you think is important enough in this area that you
Scott> would rather have people not contribute to Debian if they
On 9/24/19 3:21 PM, Holger Levsen wrote:
> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>> For several of these recommendations if I cannot get consensus, I will
>> call for a GR myself.
>
> TBH, I'm not thrilled to read this, though of course it's in your rights
> to do that.
Hi,
On 9/24/19 8:45 AM, Thomas Goirand wrote:
> Why would it be unacceptable that the whole of the archive be maintained
> in Git using Salsa? Wouldn't it be much nicer for everyone?
basically because sometimes it makes sense to have packages on github
(or gitlab, ...), close (or even within)
On September 24, 2019 12:10:39 PM UTC, Sam Hartman wrote:
>> "Bernd" == Bernd Zeimetz writes:
>
>Bernd> On 7/23/19 7:31 PM, Thomas Goirand wrote:
>>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using
>>> Git for packaging.
>
> Bernd> why is that a reason for a
Hello,
On Tue 24 Sep 2019 at 08:10AM -04, Sam Hartman wrote:
> So, I agree that a GR would be the wrong approach if we thought that we
> could get to a consensus strong enough for the policy editors.
>
> I also agree that the policy editors have the technical authority to use
> a different
On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
> For several of these recommendations if I cannot get consensus, I will
> call for a GR myself.
TBH, I'm not thrilled to read this, though of course it's in your rights
to do that. (I'm afraid such GRs would cost a lot of time which
> "Bernd" == Bernd Zeimetz writes:
Bernd> On 7/23/19 7:31 PM, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using
>> Git for packaging.
Bernd> why is that a reason for a GR? its a question for the policy
Bernd> editors.
So, I agree
Hi,
You may have noticed that the DPL asked me to put this thread on hold,
as he's discussing it in -devel. I've therefore given-up. However, let
me still answer.
On 9/23/19 8:45 PM, Bernd Zeimetz wrote:
> Also you would force everybody to use git, so this is not acceptable at all.
>
>> 3-
On 7/23/19 7:31 PM, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
why is that a reason for a GR?
its a question for the policy editors.
Also you would force everybody to use git, so this is not acceptable at all.
> 2- Mandating
On 8/27/19 10:25 AM, Norbert Preining wrote:
> Hi,
>
>> Norbert, I'm very annoyed by your wording. "Having an agenda" reads like
>> if I was writing out of malice, on purpose, just to annoy you. That is
>
> No, having an agenda is that you have a clear target which you want to
> achieve.
That's
On Mon, 2019-08-26 at 23:59:09 +0200, Thomas Goirand wrote:
> On 7/26/19 4:40 PM, Andy Simpkins wrote:
> > Personally I see no reason to mandate such a change, with policy only
> > recommending / preferring the proposed changes. Furthermore I accept
> > that the policy should strongly recommend
Hi,
> Norbert, I'm very annoyed by your wording. "Having an agenda" reads like
> if I was writing out of malice, on purpose, just to annoy you. That is
No, having an agenda is that you have a clear target which you want to
achieve.
> Reality is that you have no such opinion, you are just
On 8/27/19 2:06 AM, Norbert Preining wrote:
> Hi
>
> On Mon, 26 Aug 2019, Thomas Goirand wrote:
>> forced to either register on the said non-free platform, and use a
>> workflow which I very much dislike. It's either that ... or I just
>> ignore the VCS fields, and the VCS becomes outdated,
On Monday, August 26, 2019 6:01:05 PM EDT Thomas Goirand wrote:
> On 7/26/19 6:53 PM, Scott Kitterman wrote:
> > It's true it's not extinct, but it's close. It's only used by several
> > dozen packages now. If someone wanted to push to get dpatch completely
> > out of the archive this cycle, I
Hi
On Mon, 26 Aug 2019, Thomas Goirand wrote:
> forced to either register on the said non-free platform, and use a
> workflow which I very much dislike. It's either that ... or I just
> ignore the VCS fields, and the VCS becomes outdated, missing my upload,
> with a very good chance that it will
On 7/26/19 6:53 PM, Scott Kitterman wrote:
> It's true it's not extinct, but it's close. It's only used by several dozen
> packages now. If someone wanted to push to get dpatch completely out of the
> archive this cycle, I think it would be perfectly reasonable. The project
> has
> voted
On 7/26/19 4:40 PM, Andy Simpkins wrote:
> Hi all
>
> It seams to me reading this thread that there are those who would like
> to mandate the use of a given VCS on a particular host.
>
> The primary advantages being that it makes CI so much simpler, and
> having a uniform workflow makes it
On Thursday, July 25, 2019 11:02:14 PM EDT gregor herrmann wrote:
> On Wed, 24 Jul 2019 12:23:42 +, Scott Kitterman wrote:
> > We are
> > perfectly capable of phasing out obsolete workflows without a
> > hammer like a GR (remember dpatch).
>
> Unrelated to the general topic but since you
On Fri, Jul 26, 2019 at 11:40:31AM -0300, Andy Simpkins wrote:
> Hi all
(...)
> /Andy
Thanks Andy for putting that into words, I completly agree with you.
--
tobi
On Wed, 24 Jul 2019 12:23:42 +, Scott Kitterman wrote:
> We are
> perfectly capable of phasing out obsolete workflows without a
> hammer like a GR (remember dpatch).
Unrelated to the general topic but since you mention it: Yes I
remember dpatch -- it's not phased out, I just encountered it a
]] Thomas Goirand
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
Like Steve said, there are cases where git is not the right
tool. Recommending, fine. Mandating? No, I think that would be a bad
idea.
> 2- Mandating using the "gbp patches unapplied"
On July 25, 2019 9:46:08 AM UTC, Vincent Bernat wrote:
> ❦ 24 juillet 2019 21:29 +00, Scott Kitterman :
>
This entire discussion feels to me like a small group of developers
trying to tell the rest of us "my way or the highway". We are
perfectly capable of phasing out obsolete
❦ 24 juillet 2019 21:29 +00, Scott Kitterman :
>>> This entire discussion feels to me like a small group of developers
>>> trying to tell the rest of us "my way or the highway". We are
>>> perfectly capable of phasing out obsolete workflows without a hammer
>>> like a GR (remember dpatch).
>>
* Vincent Bernat:
> Because without uniformity, we make it harder for people to contribute.
> I have already mentioned Fedora that provides everything in git with CI
> enabled, ability to contribute with pull requests, but that's far the
> only proponent.
Fedora still uses VCS-in-VCS, so it's
On Wed, Jul 24, 2019 at 12:23:42PM +, Scott Kitterman wrote:
> Since use of a public VCS isn't universal among free software projects,
> the implication is that one could take a non-free upstream tarball, dump
> it into git on salsa and magically make it free. I think this is a
> ridiculous
On Wed, Jul 24, 2019 at 09:20:07AM -0400, Tiago Bortoletto Vaz wrote:
> On Wed, Jul 24, 2019 at 09:01:34PM +0900, Norbert Preining wrote:
> > (Or, heretic voice, maybe because it is easier to
> > throw people out when everything is standardized?)
>
> Norbert, it's not the first time in recent
On Wed, Jul 24, 2019 at 8:56 PM Holger Levsen wrote:
> On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote:
> > tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this?
> no, its too early to standardize on layouts.
And whether or not it is time (I find myself agreeing
On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote:
>
> tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this?
no, its too early to standardize on layouts.
--
tschau,
Holger
---
On 7/23/19 7:31 PM, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
>
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.
>
> 3-
On 7/24/19 6:31 AM, Norbert Preining wrote:
> So be it, but don't put *your* bothering onto others. I am bothered by a
> lot of things, too, and I don't ask you to be bothered the same way.
Even if you dismiss Github, replace it by $foo, and explain to me why I
should register there because you
On July 24, 2019 1:16:37 PM UTC, Vincent Bernat wrote:
> ❦ 24 juillet 2019 12:23 +00, Scott Kitterman :
>
>> This entire discussion feels to me like a small group of developers
>> trying to tell the rest of us "my way or the highway". We are
>> perfectly capable of phasing out obsolete
* Bastian Blank:
> On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
>> On 7/23/19 11:59 PM, Adam Borowski wrote:
>> > Big fat enormous NO! gbp is a workaround for the biggest evil in our
>> > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the
>> > impression
On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote:
> Big fat enormous NO! gbp is a workaround for the biggest evil in our
> packaging: quilt. Watching pro-git-only talks on the Debconf, I got the
> impression that if we dropped the VCS-in-VCS approach, there'd be no need
> for most
On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
> On 7/23/19 11:59 PM, Adam Borowski wrote:
> > Big fat enormous NO! gbp is a workaround for the biggest evil in our
> > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the
> > impression that if we dropped the
On 24.07.19 17:38, Fabien Givors wrote:
> Le 24/07/2019 à 15:16, Vincent Bernat a écrit :
>> Without a GR, the outcome is decided by a shouting contest. A GR seeems
>> great to know if people are a majority or not.
> A GR is not just a poll.
Yup. I personally see little chance this goes
Le 24/07/2019 à 15:16, Vincent Bernat a écrit :
> Without a GR, the outcome is decided by a shouting contest. A GR seeems
> great to know if people are a majority or not.
A GR is not just a poll.
Consider the following two questions:
i) Which is the recommended workflow among X, Y, Z?
ii) Do I
> Do you ask me to increase my work load to at least 300% only because of some
> standardization procedure for the minuscule chance that I am suddenly
> abducted by aliens?
No, it’s not about being abducted by the aliens, but there are other more
realistic factors
that might get any developer to
On Wed, Jul 24, 2019 at 09:01:34PM +0900, Norbert Preining wrote:
> On Wed, 24 Jul 2019, Ondřej Surý wrote:
> > > so, why isn't it enough to recommend those things?
> >
> > Because you are not the only developer in the whole world?
> > And when you disappear or just don’t have a time and somebody
❦ 24 juillet 2019 12:23 +00, Scott Kitterman :
> This entire discussion feels to me like a small group of developers
> trying to tell the rest of us "my way or the highway". We are
> perfectly capable of phasing out obsolete workflows without a hammer
> like a GR (remember dpatch).
Without a
On July 24, 2019 10:43:57 AM UTC, Phil Morrell wrote:
>On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
>> i detest unwarranted, imposed, uniformity. i *love* consistency. we
>have
>> had consistency in the distribution for ages. we don't need uniform
>> workflows.
>
>It's
On Wed, 24 Jul 2019, Ondřej Surý wrote:
> > so, why isn't it enough to recommend those things?
>
> Because you are not the only developer in the whole world?
> And when you disappear or just don’t have a time and somebody
> else needs to fix your packages, then it’s a heap of unnecessary
>
> so, why isn't it enough to recommend those things?
Because you are not the only developer in the whole world?
And when you disappear or just don’t have a time and somebody
else needs to fix your packages, then it’s a heap of unnecessary
trouble to go through because of someones “personal”
On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
> i detest unwarranted, imposed, uniformity. i *love* consistency. we have
> had consistency in the distribution for ages. we don't need uniform
> workflows.
It's not (always) about mandating workflows, see Ian's careful
Vincent Bernat wrote:
> While not having any official position in either of these projects, I
> was able to contribute easily to both of them because they use a
> standard workflow: no need to read tons of documentation.
There is some truth in this, but I'm not sure the proposal is directly
Hi,
Am 23.07.19 um 19:31 schrieb Thomas Goirand:
> So, the topics are:
>
> [snip]>
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.
Other people have already brought up reasons against
On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
> >> so, why isn't it enough to recommend those things?
> >Because without uniformity, we make it harder for people to contribute.
>
> i detest unwarranted, imposed, uniformity. i *love* consistency. we have
> had consistency in
On Wed, 24 Jul 2019 11:23:07 +0200, Vincent Bernat writes:
>> so, why isn't it enough to recommend those things?
>
>Because without uniformity, we make it harder for people to contribute.
i detest unwarranted, imposed, uniformity. i *love* consistency. we have
had consistency in the distribution
On Wed, Jul 24, 2019 at 02:23:26PM +0500, Andrey Rahmatullin wrote:
> > > If we're not willing to force people to use debhelper, forcing them to
> > > use git and
> > > salsa seems much more extreme.
> >
> > +1
> >
> > let's first, if at all, get the mandatory use of debhelper into policy
> >
On Wed, Jul 24, 2019 at 10:49:05AM +0200, Daniel Baumann wrote:
> > If we're not willing to force people to use debhelper, forcing them to use
> > git and
> > salsa seems much more extreme.
>
> +1
>
> let's first, if at all, get the mandatory use of debhelper into policy
> which is much more
❦ 24 juillet 2019 17:07 +10, Alexander Zangerl :
> well, i do exist. i have a few packages that aren't vc'd, and i don't see
> any need to change that. while i don't mind git, but i'd hate to be _forced_
> to use salsa and gbp.
>
> so, why isn't it enough to recommend those things?
Because
On 7/24/19 7:29 AM, Harlan Lieberman-Berg wrote:
> If we're not willing to force people to use debhelper, forcing them to use
> git and
> salsa seems much more extreme.
+1
let's first, if at all, get the mandatory use of debhelper into policy
which is much more important.
Regards,
Daniel
Norbert Preining writes:
...
> I am personally not upset at all,
On reading back what you wrote, I see that the impression I'd somehow
gained has no basis in fact, so I'm sorry for even suggesting it.
Perhaps it was just the brief flurry of "Reply to every email" behaviour
that set some
On Wed, 24 Jul 2019, Alexander Zangerl wrote:
> On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes:
> >You may be responding on behalf of people who turn out not to exist.
>
> well, i do exist. i have a few packages that aren't vc'd, and i don't see
> any need to change that. while i don't
On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes:
>You may be responding on behalf of people who turn out not to exist.
well, i do exist. i have a few packages that aren't vc'd, and i don't see
any need to change that. while i don't mind git, but i'd hate to be _forced_
to use salsa and
Hi
> Would it not be worth waiting for them to respond to this issue
> themselves, rather than immediately firing off a series of emails that
> give the impression that you are personally upset about this?
Communication with contributors can be difficult and long delayed,
mostly due to being
On Tue, Jul 23, 2019 at 1:31 PM Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
While I personally don't have a problem with this, I'm not sure how
/necessary/ it is. Though inconvenient, if we have source-only
uploads as mandatory,
Norbert Preining writes:
...
> Fine with me, strongly recommend git - anyway, it is already a fact that
> it is the de-facto standard, so this is a non-argument. My argument is
> for those developers who might have other ways/interests.
Would it not be worth waiting for them to respond to this
Hi Thomas,
> Then use one?
I do use, but several people I know don't.
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
How do you want to handle permissions? So there is a super user on salsa
who
On 7/23/19 11:59 PM, Adam Borowski wrote:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
>> packaging.
>
> Good. Especially if we can then drop quilt.
>
>> 2- Mandating using the "gbp patches
Steve McIntyre writes:
>>3- Mandating using Salsa as a Git repository.
>>
>>I do believe #1 will pass easily, but that it's useless without #2, and
>>there is some kind of uncertainty. For #3, I'm not even sure we should
>>vote for that, I probably even prefer it not to be voted for myself,
On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> > 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> > packaging.
>
> Good. Especially if we can then drop quilt.
>
> > 2- Mandating using
On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
Good. Especially if we can then drop quilt.
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most
Michael Banck writes:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>> This probably has been floating around for some time. IMO, enough time
>> so that we start to discuss $subject.
> Why is this a GR and not a policy proposal?
Policy changes require strong consensus, and
On Tue, Jul 23, 2019 at 04:47:32PM -0300, Michael Banck wrote:
> > This probably has been floating around for some time. IMO, enough time
> > so that we start to discuss $subject.
>
> Why is this a GR and not a policy proposal?
The policy documents the majority practices, which I think cannot be
Hi,
On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> This probably has been floating around for some time. IMO, enough time
> so that we start to discuss $subject.
Why is this a GR and not a policy proposal?
Michael
> Most other distributions I know about seem to have only the packaging
> information (debian/*) and not the upstream source in their version
> control system. So more people might be familiar with this; it also
> also makes tree-wide changes to packaging much easier ;-)
Is there a tooling
Thomas Goirand writes:
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
> to all packages.
That wouldn't be changed by having all repositories on Salsa. You would
need to require the same
On 7/23/19 8:05 PM, Steve McIntyre wrote:
> There are genuinely good reasons for *not* using salsa. If the debian
> packaging is directly included as part of the upstream git repo(s)
> somewhere else, for example.
I just has a very interesting conversation with Tollef. If you use a
native
> On 23 Jul 2019, at 15:11, Thomas Goirand wrote:
>
>
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
> to all packages. And that's even without considering the entry barrier
> for contributing
On 7/23/19 7:55 PM, Norbert Preining wrote:
> Hi
>
> On Tue, 23 Jul 2019, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
>> packaging.
>
> I don't see how we can mandate git. What if I do *not* use any vcs at
> all?
Then use one?
> I don't see
❦ 23 juillet 2019 19:05 +01, Steve McIntyre :
>>3- Mandating using Salsa as a Git repository.
>>
>>I do believe #1 will pass easily, but that it's useless without #2, and
>>there is some kind of uncertainty. For #3, I'm not even sure we should
>>vote for that, I probably even prefer it not to be
Hey Thomas!
On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>
>This probably has been floating around for some time. IMO, enough time
>so that we start to discuss $subject.
>
>Before starting any type of text for such a GR, I'd like to hear you
>folks. What are your thougts about
On Wed, 24 Jul 2019, Norbert Preining wrote:
> > 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> > packaging.
I forgot to add. If you ever want to go there, you also have to add
mandate that the maintainer pushes the most recent versions
to the VcsGit
Hi
On Tue, 23 Jul 2019, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
I don't see how we can mandate git. What if I do *not* use any vcs at
all? And I know enough projects that run on svn, hg, and other vcs.
I don't see that
Hi there!
This probably has been floating around for some time. IMO, enough time
so that we start to discuss $subject.
Before starting any type of text for such a GR, I'd like to hear you
folks. What are your thougts about all this? Especially, I'd like to
hear others that would be *AGAINST*
85 matches
Mail list logo
