Re: [bareos-devel] Announcing end of this Mailing list, Github discussion as replacement

[Peter 'PMc' Much]

On Thu, Oct 24, 2024 at 02:32:51AM -0700, Bruno Friedmann (bruno-at-bareos) wrote:
! We are pleased to announce the introduction of GitHub Discussions as a
! replacement for the Bareos-devel mailing list. Dear community, We would
! like to inform you about a new tool we have set up to facilitate and get
! more efficient exchanges regarding some future development. GitHub offers a
! valuable tool called "discussions", which we plan to use as a replacement
! for the less active mailing list "bareos-devel" (Please be advised that
! this will become read-only in a few days)

Hello Bruno,
thank You for this information.

Sadly, missing in Your statement is the mainly relevant information:
furtheron, participation in the list is restricted to customers of the
Github corporation.[1] Ordinary people are therefore no longer allowed to
participate.

In fact this is nothing out of the usual: many projects did already
manage to reduce the amount of bugs by not allowing ordinary people to
report them.
Occasionally I do then resort to publishing the bugs on e.g.
forum.freebsd.org or bsdforen.de or where I am still allowed to
publish, usually for entertainment.

Let's look at some examples:

* In core/src/lib/alist.h we have a function/macro
foreach_alist(var, list)
This function walks a list and therefore contains it's own implicit
loop counter. This function can therefore NOT be nested, because
the inner instance would modify the same loop counter as the outer
one, with unpredictable results.
So, for couple of years I was wondering why my volumes are not
found: I well know the required volume-018 is in drive-3 - but the
system does skip drive-3 and just not look at the volume there. :(
I tried a lot of workarounds until I figured that the actual cause
is the nesting of this foreach_alist().
There would be another funktion foreach_alist_index(inx, var, list),
and that one would probably be nestable. But that's not used - and
I didn't bother to properly repair the stuff; i just grafted a
local loop variable into the foreach_alist(), so that it ALWAYS
will use an individual index - and my drives were no longer
skipped.

* There is a job priority feature and an option allow-mixed. (Without
that option, the priority feature is of rather limited use.)
One would now expect that this feature would arrange jobs according to
their priorities. Only, it doesn't work.
After a thorough amount of searching I figured out why: while the
mixed-prio option does exist as an option switch, it isn't
fully implemented:
When a new job is started, the prio of that job gets compared to
the already running jobs, specifically to the *FIRST* of the
already running jobs. That would suffice if there were no
mixed-prio option - because then all the running jobs would have
the same prio.
But with mixed-prio one would need to compare against *EVERY* of
the already running jobs and find the highest prio among them. And
that part is missing.[2]

cheerio,
PMc


[1] Somebody might say, becoming a customer of Github is usually free
of charge. While this might be true from a monetary perspective,
Github is certainly not free of regulation. In fact, the
regulations rather comprise a little book. thereamong
regulations that would require a lawyer versed in international
property law to even understand them; and also they subdue all
account activity under the atrocious U.S. warmongery, which we
do oppose already since 1968.

[2] While I'm at it, here is a patch that might work:

--- core/src/dird/jobq.cc.orig 2024-01-17 15:42:17.000000000 +0100
+++ core/src/dird/jobq.cc 2024-07-03 23:58:38.477411000 +0200
@@ -462,12 +462,11 @@
// If any job in the wait queue can be run, move it to the ready queue
Dmsg0(2300, "Done check ready, now check wait queue.\n");
if (!jq->waiting_jobs->empty() && !jq->quit) {
- int Priority;
bool running_allow_mix = false;
je = (jobq_item_t*)jq->waiting_jobs->first();
+ int Priority = je->jcr->JobPriority;
jobq_item_t* re = (jobq_item_t*)jq->running_jobs->first();
if (re) {
- Priority = re->jcr->JobPriority;
Dmsg2(2300, "JobId %d is running. Look for pri=%d\n", re->jcr->JobId,
Priority);
running_allow_mix = true;
@@ -479,12 +478,14 @@
running_allow_mix = false;
break;
}
+ if (re->jcr->JobPriority < Priority) {
+ Priority = re->jcr->JobPriority;
+ }
re = (jobq_item_t*)jq->running_jobs->next(re);
}
Dmsg1(2300, "The running job(s) %s mixing priorities.\n",
running_allow_mix ? "allow" : "don't allow");
} else {
- Priority = je->jcr->JobPriority;
Dmsg1(2300, "No job running. Look for Job pri=%d\n", Priority);
}

[Andreas Rogge]

Hi Peter,

Am 24.10.24 um 20:44 schrieb Peter 'PMc' Much:

> Sadly, missing in Your statement is the mainly relevant information:
> furtheron, participation in the list is restricted to customers of the
> Github corporation.[1] Ordinary people are therefore no longer allowed to
> participate.

So in this case "ordinary people" means those who absolutely don't want
to have a GitHub account?

I understand your concern and nobody is forcing anyone into using
GitHub. We will, of course, continue to accept reports and patches on
the users mailing list in the future.

Our main point is that we don't want to keep an inactive mailing list.
The devel list had 22 posts in 2022, 13 in 2023 and 8 in 2024 so far.
There is not much going on, so we don't see why we should keep it.
If you're not happy with GitHub discussions, just post to the users list
what you would have posted to the devel list.

> In fact this is nothing out of the usual: many projects did already
> manage to reduce the amount of bugs by not allowing ordinary people to
> report them.

That may be the case and I won't argue with you in this point, because I
don't care what some other random project might have done.

Nevertheless, I fail to see how we as Bareos are stopping you from
reporting anything.
I'll admit that we're advocating for the GitHub issue tracker, as that's
easiest for us to handle. However, nobody is stopping you from
* posting on the users mailing list
* using the contact form on our website
* sending an e-mail to our direct contact address
* sending an e-mail to one of our developers directly
* posting your information to some forum (where we might never see it)

If you have any advise what we can improve, feel free to share it. Maybe
on the users mailing list where more people can get involved.

> Occasionally I do then resort to publishing the bugs on e.g.
> forum.freebsd.org or bsdforen.de or where I am still allowed to
> publish, usually for entertainment.

I still fail to see how we denied you anything. Also, even if you just
do such things for fun, maybe post a link to the users list...

> Let's look at some examples:
> * In core/src/lib/alist.h we have a function/macro
> foreach_alist(var, list)

> [...]
So even now after seeing the text I am to be unable to locate a post
with that content anywhere.
However, as you might not yet have noticed, we also stumbled across this
issue and addressed it a few months ago in PR #1859 [1] (If anonymous
access to GitHub is a no-go for you, I'm happy to share the details
otherwise).

> * There is a job priority feature and an option allow-mixed. (Without
> that option, the priority feature is of rather limited use.)
> One would now expect that this feature would arrange jobs according to
> their priorities. Only, it doesn't work.
> After a thorough amount of searching I figured out why: while the
> mixed-prio option does exist as an option switch, it isn't
> fully implemented:
> When a new job is started, the prio of that job gets compared to
> the already running jobs, specifically to the *FIRST* of the
> already running jobs. That would suffice if there were no
> mixed-prio option - because then all the running jobs would have
> the same prio.
> But with mixed-prio one would need to compare against *EVERY* of
> the already running jobs and find the highest prio among them. And
> that part is missing.[2]

Thank you for taking the time to look into that.
If you've tested your fix and are otherwise okay with it, would you
prepare this with git format-patch, so I can make a pull request out of
it while retaining your copyright?
Also, feel free to add your name to the AUTHORS file, if you want to. As
we value shared code-ownership I don't want to take your changes and
publish them with my name-tag on them (unless you explicitly ask for that).

Best Regards,
Andreas

[1] https://github.com/bareos/bareos/pull/1859
--
Andreas Rogge andrea...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz