On Tue, 18 Jul 2017 11:47:55 -0400
"Ismael L. Donis Garcia" <slibre@???> wrote:

> Package: amprolla
>
> Create the Release file of the experimental branch with the line:
> Codename: none
>
> And should have the name of the branch
> Codename: experimental
>
> This prevents me from downloading the repositories to my PC.
> Which prevents me from using devuan in places where there is no
> Internet access.
>
> goodbye

Ismael has *a lot* more patience than I. After the first time someone
said "make a bug report" without an exact URL, I'd have been gone.

One of the most impressive things I ever saw was an Orlando startup, I
think a free software startup, but I don't remember, whose policy was
that a user should *never* have to deal with bug tracker software. The
user describes it on the mailing list, list-mates ask incisive
questions to get complete and accurate info, and then any bug entry is
done' by people who are good at that kind of stuff.

Ismael was first asked to fill out a bug report, without the added text
"at bugs.devuan.org". Sounds simple to you, but an unnecessary time
waster for him. Those four words should be included with every request
for bug tracking.

You get to bugs.devuan.org, and the first thing you need to do is read
"Instructions for reporting a bug." Oop, more reading. And then you
learn you should check on the WWW and elsewhere for similar bugs.
Where? How?

First crack out of the box, it asks you for a package name. As they say
in court: "Objection: Calls for a conclusion on the part of the
witness." He knows what program he was running or trying to run, but
what package provided it? Probably not. And if you ask and he guesses
wrong, the people needing to solve the problem are going to start out
based on a bad assumption. And it just keeps getting worse from there.

You know, I've had situations where I found a bug, asked a few
questions, solved the bug, wrote the solution on the mailing list,
marked it <solved>, and was then asked to jump through a bugtracker's
hoops to re-record it. I went on to other things.

Here's the problem: You're integrating a bug acquisition system with a
bug tracking system. They're two different things, that should be
handled at two different times, probably by two different kinds of
people.

Bug aquisition software faces the user, with no assumptions about the
user's technical aptitude, knowledge of the software, or knowledge of
the process of troubleshooting.

Bug tracking software, on the other hand, automates a skillful and
knowledgeable counter person in a repair shop. And because it's
automated, it can do things like search for similar problems, it can be
searched, and it can be used as a question/answer facility between the
person researching/fixing the problem, and the person who reported it.
But the user shouldn't enter a symptom description into it: That
would be begging to proceed on untested assumptions, and would
inconvenience many users to point where they wouldn't do it.

Once upon a time Troubleshooters.Com had something called the Symptom
Description Wizard. It's still there, but most of it is a Java applet
no browser will run anymore. This is the kind of thing that's needed
for symptom acquisition. Maybe I'll rewrite it without Java.

To summarize: Many people use ten or twenty different pieces of Free
Software. Each piece has its own "bug tracker" with its own URL and
rules and demanded info. Some even refuse to go farther if something
isn't put in: It's like "ha ha sucker, we wasted your time. Wanna go
double or nothing?" I think the Free Software world will be much more
efficient if the User is thanked for submitting a good and complete
symptom description, without having to know project specific
information.

SteveT

Steve Litt
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz