Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #10777 > unrolled thread

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

Back to article view | Back to linux.debian.project

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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 <norbert@preining.info> - 2019-07-23 20:00 +0200
    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 <norbert@preining.info> - 2019-07-23 20:10 +0200
    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Ondřej Surý <ondrej@sury.org> - 2019-07-23 21:20 +0200
    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Ansgar <ansgar@debian.org> - 2019-07-23 21:40 +0200
      Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Ondřej Surý <ondrej@sury.org> - 2019-07-23 21:40 +0200
    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 <norbert@preining.info> - 2019-07-24 06:40 +0200
      Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Philip Hands <phil@hands.com> - 2019-07-24 07:10 +0200
        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 <norbert@preining.info> - 2019-07-24 09:10 +0200
          Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Philip Hands <phil@hands.com> - 2019-07-24 10:20 +0200
        Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Alexander Zangerl <az@debian.org> - 2019-07-24 09:20 +0200
          Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Alexander Wirt <formorer@debian.org> - 2019-07-24 09:30 +0200
          Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Vincent Bernat <bernat@debian.org> - 2019-07-24 11:30 +0200
            Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Alexander Zangerl <az@debian.org> - 2019-07-24 11:40 +0200
              Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Andrey Rahmatullin <wrar@debian.org> - 2019-07-24 12:10 +0200
              Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Phil Morrell <debian@emorrp1.name> - 2019-07-24 12:50 +0200
                Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Scott Kitterman <debian@kitterman.com> - 2019-07-24 14:30 +0200
                  Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Vincent Bernat <bernat@debian.org> - 2019-07-24 15:20 +0200
                    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Fabien Givors <f+debian@chezlefab.net> - 2019-07-24 17:40 +0200
                    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Scott Kitterman <debian@kitterman.com> - 2019-07-24 23:40 +0200
                      Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Vincent Bernat <bernat@debian.org> - 2019-07-25 11:50 +0200
                        Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Scott Kitterman <debian@kitterman.com> - 2019-07-25 13:40 +0200
                    Do we want to try to find consensus before a GR? Sam Hartman <hartmans@debian.org> - 2019-07-25 18:40 +0200
                      Re: Do we want to try to find consensus before a GR? David Bremner <david@tethera.net> - 2019-07-28 02:10 +0200
                  Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Adam Borowski <kilobyte@angband.pl> - 2019-07-25 06:30 +0200
                  Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa gregor herrmann <gregoa@debian.org> - 2019-07-26 05:10 +0200
                    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Andy Simpkins <rattusrattus@debian.org> - 2019-07-26 16:50 +0200
                      Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Tobias Frost <tobi@debian.org> - 2019-07-26 17:30 +0200
                      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 <norbert@preining.info> - 2019-08-27 02:10 +0200
                        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 <norbert@preining.info> - 2019-08-27 10:30 +0200
                      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 <guillem@debian.org> - 2019-08-27 11:30 +0200
                    Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Scott Kitterman <debian@kitterman.com> - 2019-07-26 19:00 +0200
                      dpatch was: Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Scott Kitterman <debian@kitterman.com> - 2019-08-27 03:00 +0200
            Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Thomas Pircher <thp+debian@p5r.uk> - 2019-07-24 12:40 +0200
            Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Florian Weimer <fw@deneb.enyo.de> - 2019-07-25 07:00 +0200
          Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Ondřej Surý <ondrej@sury.org> - 2019-07-24 13:50 +0200
            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 <norbert@preining.info> - 2019-07-24 14:10 +0200
              Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Tiago Bortoletto Vaz <tiago@debian.org> - 2019-07-24 15:30 +0200
                Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Adam Borowski <kilobyte@angband.pl> - 2019-07-25 06:20 +0200
              Re: GR proposal: mandating VcsGit and VcsBrowser for all packages,  using the "gbp patches unapplied" layout, and maybe also mandating hosted on  Salsa Ondřej Surý <ondrej@sury.org> - 2019-07-24 15:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

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

On July 25, 2019 9:46:08 AM UTC, Vincent Bernat <bernat@debian.org> wrote:
> ❦ 24 juillet 2019 21:29 +00, Scott Kitterman <debian@kitterman.com>:
>
>>>> 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 GR, the outcome is decided by a shouting contest. A GR
>seeems
>>>great to know if people are a majority or not.
>>
>> 50% + 1 of developers mandating details like this to 50% - 1 of
>> developers is a horrible way to solve problems like this.
>
>Still better than 10% mandating details like this to 90%.
>
>> If you want people to do things a certain way, have it solve problems
>> that cause people to decide they want to use it. Once you get rough
>> consensus on the new way, change policy.
>
>So, this is the shouting contest. A few people can post messages and
>make it appear there is no consensus.

Usually consensus doesn't magically appear.  It takes work.  At this juncture none exists.  The idea of solving this via GR seems to me like an attempt to avoid doing that work.

I'm curious who from amongst those pushing for this is volunteering to put all the QA maintained packages in git (or should those be removed)?  If you are going to mandate this, then I think those are the only two options.

Scott K

[toc] | [prev] | [next] | [standalone]

#10840 — Do we want to try to find consensus before a GR?

I had been hoping to start some discussions on these issues after
debconf.

I am not really interested in doing so against the backgdrop of a
potential GR happening at the same time.


Thomas, would you be willing to hold off on potential GR stuff until
after I see where we get with consensus?

Folks here, would you rather me try and find out how far we can get on
debian-devel using methodology similar to the debhelper discussions, or
would you rather Thomas draft GR text and look for seconds?

--Sam

[toc] | [prev] | [next] | [standalone]

#10858 — Re: Do we want to try to find consensus before a GR?

Sam Hartman <hartmans@debian.org> writes:

> Folks here, would you rather me try and find out how far we can get on
> debian-devel using methodology similar to the debhelper discussions, or
> would you rather Thomas draft GR text and look for seconds?

I think we ought to try _something_ before a GR, and the methodology
used for the dh discussion seems worth a try. If nothing else, it could
serve to help clarify whether we need a GR on the topic, but may also
have some more (IMHO) positive outcomes.

d

[toc] | [prev] | [next] | [standalone]

#10833

On Wed, Jul 24, 2019 at 12:23:42PM +0000, 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 concept.

The concept of "preferred form for modification" is mostly about those who
actually do the work.  If there's an active upstream taking a drive-by
patch, it's the upstream's opinion that matters.

Dumping a tarball into git doesn't restore lost commit messages, patch
history, nor authorship data -- just like you can't un-preprocess C code
(nVidia's "nv" driver comes to mind).

Ie, I consider making matters worse to be worth forbidding; I'm not
proposing declaring old code non-free because it doesn't use techniques
which were not even invented then.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#10852

[Multipart message — attachments visible in raw view] — view raw

On Wed, 24 Jul 2019 12:23:42 +0000, 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 few
days ago.


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   

[toc] | [prev] | [next] | [standalone]

#10853

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 easier for those not maintaining a
given package to view and make changes (occasionally distribution wide).

On the other hand there is also those who would rather not see this
become mandatory.  Various reasons have been given, but if I have
understood correctly they boil down to a few classes namely; doesn't
fit our model, a lot or work to change for few if any perceived benefit,
principled belief that maintainer is free to maintain however
they see fit.

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.

Clearly, maintained packages that do not match the proposed
new VCS & Layout will be harder &/OR require additional effort from
people that only understand this new work flow to to work on.  However
these packages are being maintained by people that DO understand the
existing workflows etc.  Sure such packages may not 'benefit' from some
of the CI testing that *may* get produced or some project wide automated
changes - these tasks *may* still need to be done by the existing
maintainers - that is a 'cost' of choosing not to standardise on on the
proposed new system.

Of cause should the package in question no longer be maintained by the
exiting maintainer/team then whoever picks up the package afterwards
would be free to move to the new setup as they see fit - potentially
understanding better the reason that the previous maintainer chose not
to adopt the new setup along the way :-)


/Andy

[toc] | [prev] | [next] | [standalone]

#10854

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

[toc] | [prev] | [next] | [standalone]

#10894

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, and I am sure you do that on purpose to press your own agenda
to force everyone to salsa.

Even on salsa there are (I am sure, because I have seen them before)
packages that are out of date, and you will not be able to push to it if
it is a personal project.

It boils down to responsiveness and collaborativenss of the maintainer,
and is not a question of non-free or not.

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. I for my side will not move over again, and if I am
forced I will just force-push released versions in one big bunch, and nothing
else, while actual development will happen somewhere else.


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


Best

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

[toc] | [prev] | [next] | [standalone]

#10896

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

[toc] | [prev] | [next] | [standalone]

#10897

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 <https://wiki.debian.org/Teams/Dpkg/AliothEscape> 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

[toc] | [prev] | [next] | [standalone]

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

On Thursday, July 25, 2019 11:02:14 PM EDT gregor herrmann wrote:
> On Wed, 24 Jul 2019 12:23:42 +0000, 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 few
> days ago.

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 with their feet.

Scott K

[toc] | [prev] | [next] | [standalone]

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

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 think it would be perfectly reasonable. 
> > The project has voted with their feet.
> 
> I wish we had release goals again, because that would really be a
> perfect fit.
> 
> Do you have the list of affected package available? How about we tackle
> this in a sprint, let's say, in Vaumarcus?

Here's the packages with dpatch in build-depends (they would all need checking 
- I assume lintian only uses it for its test suite):

reverse-depends -b dpatch
Reverse-Build-Depends
=====================
* bopm
* cadaver
* check-mk
* cryptcat
* docbook2odf
* dvbsnoop
* efax
* elscreen
* flexbackup
* flow-tools
* gkrellm-x86info
* ibam
* ippl
* libdumbnet
* libmdsp
* lifelines
* lintian
* manpages-es
* mgetty
* myspell
* noweb
* nwall
* ocaml-expat
* ocamlodbc
* python-authkit
* python-toscawidgets
* qmc
* readline5
* redet
* scim-canna
* scim-skk
* shanty
* spell
* synaptic
* syrep
* tapecalc
* tcm
* txt2regex
* vdk2
* vsdump
* wbox
* xaw3d
* xcal
* xsysinfo
* xxgdb

Scott K

[toc] | [prev] | [next] | [standalone]

#10812

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
addressing this issue.

I'm a Debian user with some experience of packaging in-house
applications, and very small exposure to uploading to Debian. I'm adding
my point of view as a relative newbie for packaging, FWIW.

The New Maintainer's Guide currently presents several different workflows,
with very little guidance on which one to use, therefore this proposal
sounds completely backassward to me: new maintainers are supposed to
learn about several competing workflows and figure out themselves which
one to use *before* building their first package, while experienced
developers are being mandated to use one specific one, even though they
might have valid reasons for using a non-standard one.

How about having one *recommended* workflow, which is well documented and
kept up-to-date, while still allowing experienced developers to adopt
alternatives? Or at least do this in two stages: first get newcomers and
people eager to change on board, and only then, in a second step,
mandate a change in workflow from old dogs who must be forced to learn
new tricks.

Thomas

[toc] | [prev] | [next] | [standalone]

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

* 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 not real Git.  You cannot simply
send a pull request for anything that changes source code.  You still
have to create a patch file and add it to the RPM spec file.  Some
package maintainers have their true repositories elsewhere and
synthesize the patches from that, but there's no standard way of doing
that yet.  (packit is not yet integrated with Fedora infrastructure,
and it is quite new.  It's unclear if it will fare better than the
many previous attempts.)

[toc] | [prev] | [next] | [standalone]

#10814

> 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” preferences.

Debian is a team effort and it always was, although it sometimes
look like a team of zen-buddhists - each walking a different path
and different direction - we do converge to a common goal at the
end.

It’s fine to be a different, but when it hinders other’s ability to contribute
sometimes it’s better to bite the bullet and be nice to your fellow
Debian Developers by making your packaging accessible.

Ondrej
--
Ondřej Surý
ondrej@sury.org

[toc] | [prev] | [next] | [standalone]

#10816

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
> trouble to go through because of someones “personal” preferences.

Sorry, I spent about 15 years packaging TeX and friends - and I spend
most of my Debian time with that.

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? (Or, heretic voice, maybe because it is easier to
throw people out when everything is standardized?)

Why don't you simply trust those who are responsible for packages that
they know what is the most appropriate way?

Are we now in a state in Debian that Developers are treated as employees
that have to obey and follow the rules, or are we still a group of
self-determined engineers that are able to make our own decisions,
including what packaging is the best/most convinient, with the aim of
building the best distribution?

> Debian is a team effort and it always was, although it sometimes

I strongly disagree  - it is **not** - it is the work of lots
of dedicated individuals, not team work. There are some teams that work
together, but this is not Debian.

> It’s fine to be a different, but when it hinders other’s ability to contribute
> sometimes it’s better to bite the bullet and be nice to your fellow
> Debian Developers by making your packaging accessible.

Again weak. If you want to contribute, unpack the source package and fix
bugs, improve packaging, whatever. Then send patches. The maintainer
will include that in the work flow - you learn how it works, and next
time maybe already do the same.

This is not even the slightest reason NOT to contribute.

Best

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

[toc] | [prev] | [next] | [standalone]

#10819

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
> > else needs to fix your packages, then it’s a heap of unnecessary
> > trouble to go through because of someones “personal” preferences.
> 
> Sorry, I spent about 15 years packaging TeX and friends - and I spend
> most of my Debian time with that.
> 
> 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? (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 emails that you insinuate,
semi-jokingly, that Debian might "throw people out" for whatever reasons
you like to think. I just wanted to point out here that this is not
true in Debian. And I do this because I don't want people to feel
themselves discouraged of speaking out in the project.

That exhausting process has hurt everybody involved, and has finished
with appologies from both sides after so much pain. And I just can't
believe that we didn't learn anything from it after all.

Bests,

-- 
tiago

[toc] | [prev] | [next] | [standalone]

#10832

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 emails that you insinuate,
> semi-jokingly, that Debian might "throw people out" for whatever reasons
> you like to think. I just wanted to point out here that this is not
> true in Debian.

Could you at least check whom are you talking about first, please?  Because
at this point your insinuation that Norbert is "joking" is disgusting.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄⠀⠀⠀⠀ sky.  Your cat demands food.  The priority should be obvious...

[toc] | [prev] | [next] | [standalone]

#10820

> 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 stop contributing. I find it useless to list them all just
to prevent you from strawmanning.

> (Or, heretic voice, maybe because it is easier to
> throw people out when everything is standardized?)

Anyway, I am really really tired of your whining in just every message you send,
so I am just blacklisting you.

Ondrej
--
Ondřej Surý
ondrej@sury.org

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.project

csiph-web