[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ffmpeg | Disable pocketsphinx on few more architectures (!5)



Quoting Pino Toscano (2020-08-23 14:04:53)
> In data domenica 23 agosto 2020 13:52:00 CEST, Jonas Smedegaard ha scritto:
> > Quoting Pino Toscano (2020-08-23 11:57:16)
> > > In data domenica 23 agosto 2020 11:47:47 CEST, Jonas Smedegaard ha scritto:
> > > > Jonas Smedegaard commented:
> > > > 
> > > > Thanks for your proposed change.
> > > > 
> > > > Please, however, instead contribute to the related Debian bugreport archived at https://bugs.debian.org/968555 and accessible by posting email to <mailto:968555@bugs.debian.org>.
> > > > 
> > > > Sorry for the confusion and inconvenience: Even though this Gitlab service at salsa.debian.org offers an issue tracker, Debian uses a different email-based issue tracker.
> > > > 
> > > > I will now close this issue _without_ solving it, and hope you will join the conversation at bug#968555
> > > 
> > > Err, sorry, but this is not true. There were other MRs in the past for
> > > ffmpeg, and they were accepted/merged by other ffmpeg uploaders.
> > > Also, I see you disabled MRs altogether, which makes even past MRs not
> > > reacheable anymore, which is bad.
> > > 
> > > Please reconsider this, Jonas.
> > 
> > It is true that Debian uses debbugs as issue tracker.
> 
> This does not imply anything about other solutions.
> 
> > You are free to insist that it is possible to do other things than what 
> > I am pointing out as a recommended way forward.  Maybe someone find your 
> > different approach great and best and true.
> 
> Jonas, I honestly do not understand the point you are trying to make
> here. There are two problems in what you did, let me explain them
> further more:
> 
> Problem #1: sudden rejection of merge requests.
> They were accepted in the past, mostly by James Cowgill:
> https://salsa.debian.org/multimedia-team/ffmpeg/-/commit/6b1b5c4cccd2d98d4c0177e840a3f2fff27c9d9a
> https://salsa.debian.org/multimedia-team/ffmpeg/-/commit/d0ecb3e1fac0f656253f1d18a007dd63f76daaf6
> https://salsa.debian.org/multimedia-team/ffmpeg/-/commit/2158164c70223f7881136200cd5427e65a6af66b
> Considering my MR was !5, this makes 3 out of 4 previous MRs reviewed
> and accepted by ffmpeg maintainers (assuming you didn't kick James out
> in the meanwhile, of course).
> For a potential contributor, looking at a packaging repository and
> noticing that MRs are accepted encourages sending changes as MRs;
> suddently changing this by another maintainer gives a *bad* message,
> i.e. that there is no agreement by maintainers, and this kind of
> contributions is at the whim of the "active maintainer of the week".

For the record, I received this message from the salsa issue tracker:

> @js can you please take a look at this before your next upload? 
> Thanks!

You asked *me* specifically to merge, not the team generally.

There nothing "sudden" about me rejecing MRs on salsa.

Had you not asked me specifically, I would most likely have ignored it.

Maybe you would then have had a great experience, because someone else 
in the team who _does_ use salsa MRs had stepped in and processed your 
MR.

Maybe you would have had a worse experience: no response, and an MR 
being ignored by the team.  And other newcomers would have a bad 
experience as well: lack of chatter in the issue tracker and a stale 
unprocessed MR...

Same speculation for maintenance of ffmpeg in general: Maybe it would 
have been greater maintained if I had not helped.  I mean, you consider 
me merely the "active maintainer of the week", right?

It was exactly because I was concerned about the impression by newcomers 
that I did not ignore your direct message, but spent time explaining 
where to more appropriately report the issue instead, and then spent 
time disabling the interface to avoid others being mislead by the 
currently unused issue tracking and git processing tools.


> Problem #2: hiding of past MR information
> Since you disabled the MRs in the salsa repository, then all the past
> ones cannot be seen anymore. I think all the discussions/etc are still
> in the gitlab database, but practically speaking all the data is *lost*
> for normal users (including you and me). This is the equivalent of
> making bugs in the BTS no more accessible, not even as archived.

I am unaware of a way to communicate "this package is not this week 
managed by use of gitlab issue tracker and MR processing" without at the 
same time saying "MR processing of last week is currently not public".

If you are aware of some way to do that, please do tell.  Because my 
_main_ objective was to communicate the whim of this weeks developer 
over the whim of last weeks developer, but I certainly would not mind 
_secondarily_ preserving historic artifacts of the whims of last weeks 
developer - if possible.


> Again, Jonas, please reconsider what you did. This has nothing to do
> with my own stupid patch, but in general with the way you are showing
> "collaboration".

Seems you confuse "collaboration" and "embrasing salsa as issue tracker 
and patch processor".


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: