[sr #110299] minor typo submits unfinished bug report

[Dave]

Follow-up Comment #5, sr #110299 (project administration):

Alternately, if you consider Summary-field submission essential to some
people's workflow, you could add a simple popup asking for confirmation,
defaulting to No, when someone submits via that mechanism.  Then implicit
submission changes from the keystroke "Return" to the key sequence "Return,
Tab, Return," which is simple to type for those intending it, but exceedingly
unlikely to be accidentally typed all in a row.

But given the illogic of the implicit field's placement, I'm skeptical that
it's as widely used as you fear.  Do the server logs record what submission
method was used?  It would be interesting to see how many used Summary-field
submission, and then see how many of those tickets appeared to be
inadvertently submitted.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110299] minor typo submits unfinished bug report

[Dave]

Follow-up Comment #6, sr #110299 (project administration):

As an experiment, when adding comment #5, I did not use the mouse to submit
it, but hit "Shift-Tab Shift-Tab Shift-Tab Return," and it worked fine.  So
there are still keyboard-based submission options that don't involve implicit
submission on an unexpected and illogical field.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110909] gnuboot git repository cleanup

[Ineiev]

Update of sr #110909 (project administration):

  Status:Works For Me => Done   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #109439] Commit notification hook mishandles non-ASCII author names

[Ineiev]

Update of sr #109439 (project administration):

  Status:None => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

It looks like the issue resolved itself in 2022-01 or 2021-12,
https://lists.gnu.org/archive/html/guix-commits/2022-01/msg02561.html


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110923] Please, close "make -j" bug, reported by me

[anonymous]

URL:
  

 Summary: Please, close "make -j" bug, reported by me
   Group: Savannah Administration
   Submitter: None
   Submitted: Thu 17 Aug 2023 09:40:00 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Thu 17 Aug 2023 09:40:00 AM UTC By: Anonymous
Dear Savannah,

it was my fault when I reported a bug:
- https://savannah.gnu.org/bugs/?64543

There is no issue in "make" utility.

The problem is in how it was used inside of Docker container by me.

I've used:
```
NUM_CPUS=$(grep -c ^processor /proc/cpuinfo)
make -j$(NUM_CPUS)
```

inside of Docker container, but this was my mistake.

There is no problem when using simply:
```
make -j
```

Unfortunately I was unable to leave neither a comment nor close the bug issue,
created be me.
Feel free to close this bug report.

Thank you!







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110299] minor typo submits unfinished bug report

[Ineiev]

Follow-up Comment #7, sr #110299 (project administration):

[comment #4 comment #4:]
> A single typo should not result in a malformed submission that is impossible
to correct.

Why impossible?  I just re-submit correctly, noting that the previous one was
wrong, and tracker manager closes the erroneous item as duplicate.

> Do the server logs record what submission method was used?  It would be
interesting to see how many used Summary-field submission, and then see how
many of those tickets appeared to be inadvertently submitted.

We don't snoop on our users, and in fact, I doubt Apache logs could actually
reveal such data.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110923] Please, close "make -j" bug, reported by me

[Ineiev]

Update of sr #110923 (project administration):

  Status:None => In Progress
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

You are requesting as anonymous.  Have you lost your account?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110299] minor typo submits unfinished bug report

[Dave]

Follow-up Comment #8, sr #110299 (project administration):

[comment #7 comment #7:]
> Why impossible?

Because even a manager cannot remove a ticket from the system.  It can only be
closed.  But you raise a valid point: my terminology was ambiguous--the typo
can be _corrected_, but it can't be _undone_, so I should have used the latter
term to make that clearer.

> I just re-submit correctly, noting that the previous one was
> wrong, and tracker manager closes the erroneous item as duplicate.

The word "just" is doing an awful lot of work in that sentence.  If a single
mistyped key requires an explanation from the offending user and action on the
part of a manager, there's a pretty serious design flaw.  A typo should be
immediately remediable by the user who committed it, without littering the
ticket system with a malformed entry.

This was the point of my search-box example: prematurely submitting a search
request means waiting maybe up to 3 seconds on a particularly slow connection,
then fixing the request and resubmitting it.  Typos are extremely common, and
fixing them should be quick and easy, not require an explanatory note and
management intervention.

Even on my parents' ancient typewriter, where a typo meant breaking out the
correction paper, correcting a single mistyped key was less work than this. 
I'd like to think a 2020s web site can improve upon the performance of a 1970s
typewriter.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110923] Please, close "make -j" bug, reported by me

[anonymous]

Follow-up Comment #2, sr #110923 (project administration):

[comment #1 comment #1:]
> You are requesting as anonymous.  Have you lost your account?

No. It wasn't anonymous request.
Just I had some issues (probably with "savannah.nongnu.org") when trying to
leave a comment on a bug, created by me. 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110907] reply-to emails which are comments on bugs

[Tristan Wibberley]

Follow-up Comment #4, sr #110907 (project administration):


[comment #3 comment #3:]
> Let us imagine that the message with the hash is intercepted; then it would
be possible for the interceptor to impersonate that user in that tracker item,
wouldn't it?

Often, but the from address is often secured (some newfangled authorised
mail-submission-agent system with DNS, I think) and you can check the security
of the email path in those cases, so if the user has nominated a from address
for a so-secured mail-exchange then you're alright in that case. I suggested
the user might nominate an email signature certificate which can't be
impersonated much more than the website login.

Even outside those cases, this is limited to commenting so you can clean up
once you realise that a user has been impersonated and change the salts as
often as you like. On the occasions that a salt has been changed before a user
replies you can send out a new address for them to resend their reply to so
you can even change the salt very often. If you allow this case then you can
indicate that the comment has no or little identity verification so people
don't act as if such a comment was an authority. Alternatively or in-addition,
on occasion a user could log in and validate the identity of comments sent by
email and you could make that easy by sending a digest with a validation link
either before or after the emails are spooled into comments. It would still be
more practical to converse on development topics than interrupting a user
workflow with website visits and the website login process injected between
thoughts. The advantage of sending a digest with validation request is that
this most awkward case can be handled with a spool separate to the rest of the
system.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110922] [SPAM] Clean Energy Hosting

[Corwin Brust]

Update of sr #110922 (project administration):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110923] Please, close "make -j" bug, reported by me

[Ineiev]

Update of sr #110923 (project administration):

Category:None => Savannah trackers - bugs,
tasks, etc.
  Status: In Progress => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Closing since the OP has successfully commented on bug #64543


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110907] reply-to emails which are comments on bugs

[Ineiev]

Follow-up Comment #5, sr #110907 (project administration):

TLDR: this looks too complicated to me.

> Often, but the from address is often secured (some newfangled authorised
mail-submission-agent system with DNS, I think) and you can check the security
of the email path in those cases, so if the user has nominated a from address
for a so-secured mail-exchange then you're alright in that case.

I'm not aware of this protocol; at any rate, I believe such things should
cover all users, not part of them.

> I suggested the user might nominate an email signature certificate which
can't be impersonated much more than the website login.

They might, but would it really be more convenient for them?

> Even outside those cases, this is limited to commenting so you can clean up
once you realise that a user has been impersonated

So far, we have neither means to clean up nor the need for it; to say nothing
of the work on detecting the impersonations.

> and change the salts as often as you like. On the occasions that a salt has
been changed before a user replies you can send out a new address for them to
resend their reply to so you can even change the salt very often.

If I change the salt very often, the user won't be able to use it,
and I can't see how it could protect against the interception.

> If you allow this case then you can indicate that the comment has no or
little identity verification so people don't act as if such a comment was an
authority.

I don't think it's a good idea to make our users learn another tracker-related
concept; trackers are already more than sufficiently complicated.

> Alternatively or in-addition, on occasion a user could log in and validate
the identity of comments sent by email and you could make that easy by sending
a digest with a validation link either before or after the emails are spooled
into comments.

If the user has to log in anyway, the usefulness of emails will be very
limited.

> It would still be more practical to converse on development topics than
interrupting a user workflow with website visits and the website login process
injected between thoughts.

It's possible to do that, the emails just don't land in the tracker.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110299] minor typo submits unfinished bug report

[Ineiev]

Follow-up Comment #9, sr #110299 (project administration):


> > Why impossible?
> 
> Because even a manager cannot remove a ticket from the system.  It can only
be closed.  But you raise a valid point: my terminology was ambiguous--the
typo can be _corrected_, but it can't be _undone_, so I should have used the
latter term to make that clearer.

Now I don't understand why anything like this should be 'undone'.

> > I just re-submit correctly, noting that the previous one was
> > wrong, and tracker manager closes the erroneous item as duplicate.
> 
> The word "just" is doing an awful lot of work in that sentence.  If a single
mistyped key requires an explanation from the offending user

Well, the user isn't required to explain anything: tracker managers are
intelligent enough to understand such things without explanation.

> and action on the part of a manager, there's a pretty serious design flaw.

Not at all; such items show up quite rarely, and it would be great if the
substantial work on the reported issue typically were as little as this.

> This was the point of my search-box example...

I agree this is different.  I disagree it's crucially different.

> Even on my parents' ancient typewriter, where a typo meant breaking out the
correction paper, correcting a single mistyped key was less work than this. 
I'd like to think a 2020s web site can improve upon the performance of a 1970s
typewriter.

I'm sure you are exaggerating.  In 70s, many typewriter users had no access to
correction paper at all.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #109703] package savane for debian

[Ineiev]

Follow-up Comment #2, sr #109703 (project administration):

See also task #15442.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/