Hi,

I've uploaded golang-github-chromedp-chromedp some time ago, it's needed
for git-pages. While I have much interest in git-pages, I don't really
care about golang-github-chromedp-chromedp.

However, golang-github-chromedp-chromedp and
golang-github-chromedp-cdproto always go in lockstep, in order to update
chromedp you need to update cdproto.

Given that I'm actively updating chromedp continuesly to make sure we
have the current version in Debian, this becomes quite tedious to always
ask and wait for cdproto to be updated first.

Would you mind taking over chromedp and keep them both updated, or would
you like me to take over cdproto instead?

Regards,
Daniel

Hi,

the following three packages are all related packages, they have tight
dependencies and need to be updated in a synchronised way:

   golang-github-chromedp-cdproto, maintained by debian-go
   golang-github-chromedp-chromedp, maintained by me
   golang-github-go-echarts-snapshot-chromedp, maintained by me

I've NMU'ed golang-github-chromedp-cdproto today, after waiting for 5
weeks for any signal whatsoever from the maintainer (#1142393). This is
very frustrating for me as this is not happening for the first time
(I've directly asked Andrew last March to update it).

I've proposed to solve this (#1142395), without any response whatsoever
since 5 weeks too.

I would like to avoid this when updating golang-github-chromedp-chromedp
the next time, should I file a Intend-To-Salve bug against
golang-github-chromedp-cdproto or what do you suggest?

Regards,
Daniel

Daniel Baumann <daniel@debian.org> writes:

I think golang-* packages are a bit special in Debian: nobody (AFAIU)
cares about them, they are all just vehicles to build other packages.
Thus, I think few cares about a particular Go package A until it causes
problems for another Go package B they work on, and then they make a
team upload of package A (after reverse build checking, of course).  For
this reason, it would be nice if (essentially) all of golang-* packages
in Debian were team-maintained by the Debian Go Team so that they all
can be kept updated by the team.

/Simon

thanks, but I atm prefer not to for various reasons.

 > it would be nice if (essentially) all of golang-* packages> in Debian
were team-maintained by the Debian Go Team so that they all

as said in the initial message to this bug, I don't mind if you take
over the two other packages, however, my expectation is that they will
be (pro)actively maintained. If it turns out they are not, they'll block
me and will require me to constantly prod and regularly NMU it, which is
waste of time and effort.

oiow, imho, package should be maintained actively or be dropped. are you
willing to do that for the mentioned packages?

Regards,
Daniel

Daniel Baumann <daniel@debian.org> writes:

I don't know those packages at all, so I would only look at (and
possibly upload) them by chance if they pop up in some list of packages
that reaches my attention.  So maybe I'm not the best fit.  It sounds
like you would be a good (co)-maintainer/uploader of them?  I don't know
the history, but I would be surprised if anyone in the go team would
oppose if you added yourself to 'Uploaders' for some go-team maintained
packages and made uploads.  (Although I am often surprised what people
object to...)

/Simon

We're going in circles. To summarize, I understand that the Go team
isn't maintaining this concrete package as active as I would like it to
be (and doesn't want to take over the other two), and I don't want to
join the Go team at this point. So I will continue the bug+NMU way for
the time being.

Regards,
Daniel

Daniel Baumann <daniel@debian.org> writes:

Whatever works best for you and the packages -- although there is no
rule that says you have to be a Go team member to be in the uploaders
field and prepare uploads of packages without the NMU-process, is there?

There are literally thousands of Debian Go Team packages maintained as
"badly" as these ones.  And hundreds of them significantly much worse!

I'm not sure what if anything can be done about this, beyond having
people effectively doing QA uploads of unrelated go packages when they
need to for some other dependency (like you do here).  And letting go of
zombie packages which has no use and eat up our precious QA time.

IMHO, we need LESS barriers for making effective contributions.
Barriers create frustration, like you showed here.  I think that
probably everyone working on Go packages in Debian shares the same
frustration about poorly maintained Debian Go packages.

/Simon

my issue is not with the team, but me having a workflow which is not
involving salsa, and uses git with different debian packaging standards.

therefore my initial proposition in the bug: either I take over the
blocking package, or I'm handing over the two blocked packages provided
all three of them are actively kept up2date (as they are depends of
other packages that need it current). if neither of these two options
are possible, then for me NMU'ing is the best.

can be, but this package here is the one that blocks me, not the others.

ack.

Regards,
Daniel