Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

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 the way *you* feel about it. Not mine. I feel offended, because
"acting out of malice" is what I feel when reading you. So yeah, please
more carefully choose your words.

> Wrong. [...]
> 
> So please, don't assume anthing about what I think and read my
> intentions. Thanks.

What's funny is that what you expressed above is exactly what I assumed,
and understood without more explanation.

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Guillem Jover]

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 (i.e. require an explanation
> > why not) for NEW packages.

> As per our discussion in Debconf, we're attempting to remove Python 2
> from Bullseye. So, I decided to commit myself to try to do one Python 2
> removal per day. Doing so, I often encounter very badly maintained
> packages (ie: far behind upstream, bugs, no py3 support even if upstream
> has it, you name it...). And often, I get these packages maintained on a
> proprietary platform, where I have no write access. As a result, I'm
> 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 never get updated. That's really
> bad for any future contributor that probably will also encounter the
> same problem, with on top, my changes not commited. Add on top of this
> that when you do 'apt-get source foo', then apt suggests to fetch the
> sources from that non-free platform, which has outdated sources. How do
> you explain this to a Debian newbie that wants to start contributing to
> Debian? This really doesn't make sense at all.

I read a mass of conflated arguments there that make any such
discussion quite difficult IMO.


I fully understand, and agree myself with, not wanting to use a
proprietary platform as the *primary* site for one's projects, to
avoid lock-in, to support free-software ideals, etc. I do have
accounts, and even secondary mirrors on some of these though.

As maintainers we are expected to interact with upstreams, and submit
our changes there (not just for others benefit, but also for our own,
to avoid future conflicting changes, and to make Debian needs known),
which seems it would still be unnacceptable to you. Should we then ban
any such upstream from getting into Debian? That seems like a complete
non-starter TBH, or do you expect that's fine, but someone else then
needs to do the dirty work for you? If so, what's the difference with
people in Debian maintaining the packages wherever?


Another thing I extract from your reply is that you are assuming we'd
have all repos in salsa being write-for-all, and using the debian/
namespace. That implies a very big social change, with many as yet
undefined social norms, that feels being sneaked in as an aside.


There's also the problem with out-of-date repos or unmaintained
packages. We are supposed to file NMU bugs with patches anyway. I've
also seen repos being out-of-sync with what it's in the archive on
*salsa*. The problem with unresponsive maintainers has not really
changed, we have procedures for that. I don't see why people that
cannot upload to the Debian archive should expect to be able to
automatically have write-access to random packaging repos either?
(And this all seems rather odd, given that we are talking about git,
while _D_VCS being one of its common selling points.)


There's also the problem with the workflows. I find anything that is
not packaging-only to be so attrocious to deal with that I rather
prefer to use «apt source» and go from there. I also extract from your
reply you'd like to force a single packaging workflow. Having to do
my packaging work on anything that is not packaging-only would make
that work miserable for me.


And then there's the «force to use salsa». I've got a few secondary
mirrors there too (such as for the dpkg suite), and I use the platform
(in the same way I'd use github or others) to interact with packagers
or upstreams that host there, but I'd be extremely unhappy with being
forced to use it. And I'd rather remove the Vcs fields from the packages
I maintain. See  for
some of reasons why I didn't switch the dpkg suite to salsa. For the
other package I maintain, I switched away from Alioth long long time
ago, and have been very happy since. Alioth was also supposed to be
a long-term hosting platform, but TBH I expect my self-hosting to last
longer than Salsa too.


> How do you handle such case, if not enforcing some kind of rules? Well,
> that's what motivated me to start this discussion. However, I'll let Sam
> take over, and see how it develops.

We already have procedures (NMUs, salvaging, etc) and common
infrastructure (Debian Archive, Debian source, BTS, etc) for everything
you describe above. I only see gratuituous enforcement for one's
preferred options here TBH. :(

Thanks,
Guillem

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

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 (rightly) pissed
> by the recent event around your account being revoked, then reinstalled.
> Also, this has to do with the foo-guest -> foo (and the other way around
> in your case), which needs to be fixed anyways. So this is IMO not
> relevant at all here.

Wrong. I simply realized that a system that is managed by a few
personals with rather free reign on what to do is not where I want to
work. You say github is nonfree, but removing rights on gh is
practically impossible, I don't know whether it actually happened. 

I don't care for the nuclear case that MS decides to shut down gh from
one day to the next. The same can happen due to other reasons with
salsa, too - and we have seen this just last months. That is not the
problem, git has everything I care for, so I can just push somewhere
else.

I care more for arbitrary actions. And I don't want to say that the
removal of my access was an arbitrary action, but I want to say that
arbitrary actions are just too easy to happen on salsa with a small
management team, personal preferences and ideals. So simply put, I don't
trust that in future something similar might not happen out of different
and even more strange reasons, while I am quite sure that on GH this
will *not* happen. And I consider this more likely than the nuclear
action of GH closing down.

So please, don't assume anthing about what I think and read my
intentions. Thanks.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

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, missing my upload,
>> with a very good chance that it will never get updated. That's really
> 
> You are mixing unresponsiveness of the maintainer with non-free
> platforms

Well, the mix is indeed the problem!

> and I am sure you do that on purpose to press your own agenda
> to force everyone to salsa.

It's on purpose, because that's the problem, not because I'm acting out
of malice (ie: with an "agenda" that I need to "press") to annoy you.

Except yourself, and for obvious reasons which you already mentioned, I
haven't seen any opposition to the proposal.

> With any proposal like this the net effect is that those who prefer some
> other infrastructure than salsa will have an out of date git repo at
> salsa to satisfy your agenda, and real development will still continue
> somewhere else.

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
not the case. I just happen to have a different view on things. It's
been told to you many times, your choice of words looks very aggressive
to others, and it'd be nice if that changed.

> Please, stop you crusade, and simply accept that other developers have
> other opinions than yours, and other preferences.

Reality is that you have no such opinion, you are just (rightly) pissed
by the recent event around your account being revoked, then reinstalled.
Also, this has to do with the foo-guest -> foo (and the other way around
in your case), which needs to be fixed anyways. So this is IMO not
relevant at all here.

Thomas Goirand (zigo)