Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #85152 > unrolled thread

Usage of real m68k hardware

Back to article view | Back to linux.debian.devel

Contents

  Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 08:40 +0200
    Re: Usage of real m68k hardware John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2018-03-28 09:00 +0200
      Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 10:00 +0200
        Re: Usage of real m68k hardware Carsten Strotmann <cas@strotmann.de> - 2018-03-28 10:20 +0200
        Re: Usage of real m68k hardware John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2018-03-28 10:20 +0200
          Re: Usage of real m68k hardware Laurent Vivier <laurent@vivier.eu> - 2018-03-28 10:20 +0200
          Re: Usage of real m68k hardware Ole Streicher <olebole@debian.org> - 2018-03-28 11:50 +0200
        Re: Usage of real m68k hardware Chris Lamb <lamby@debian.org> - 2018-03-28 11:10 +0200
          Re: Usage of real m68k hardware John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2018-03-28 11:40 +0200
            Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 12:10 +0200
              Re: Usage of real m68k hardware Emilio Pozuelo Monfort <pochu@debian.org> - 2018-03-28 12:30 +0200
              Re: Usage of real m68k hardware Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-03-28 13:40 +0200
            Re: Usage of real m68k hardware Thorsten Glaser <t.glaser@tarent.de> - 2018-04-17 19:30 +0200
              Re: Usage of real m68k hardware Ingo Jürgensmann <ij@2018.bluespice.org> - 2018-04-17 21:40 +0200
    Re: Usage of real m68k hardware Ingo Jürgensmann <ij@2018.bluespice.org> - 2018-03-28 09:30 +0200
    Re: Usage of real m68k hardware Carsten Strotmann <carsten@strotmann.de> - 2018-03-28 10:50 +0200
    Re: Usage of real m68k hardware Finn Thain <fthain@telegraphics.com.au> - 2018-03-28 11:20 +0200
      Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 12:20 +0200
        Re: Usage of real m68k hardware Geert Uytterhoeven <geert@linux-m68k.org> - 2018-03-28 13:00 +0200
        Re: interpretation of wontfix Simon McVittie <smcv@debian.org> - 2018-03-28 13:10 +0200
          Re: interpretation of wontfix Andreas Tille <andreas@an3as.eu> - 2018-03-28 14:00 +0200
            Re: interpretation of wontfix Marvin Renich <mrvn@renich.org> - 2018-03-28 14:30 +0200
          Re: interpretation of wontfix Marco d'Itri <md@Linux.IT> - 2018-03-28 14:50 +0200
            Re: interpretation of wontfix Holger Levsen <holger@layer-acht.org> - 2018-03-28 17:30 +0200
          Re: interpretation of wontfix Jonas Smedegaard <jonas@jones.dk> - 2018-03-28 15:40 +0200
          Re: interpretation of wontfix Sean Whitton <spwhitton@spwhitton.name> - 2018-03-28 19:10 +0200
            Re: interpretation of wontfix Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-03-29 15:00 +0200
              Re: interpretation of wontfix Sean Whitton <spwhitton@spwhitton.name> - 2018-03-29 17:20 +0200
              Re: interpretation of wontfix Adrian Bunk <bunk@debian.org> - 2018-03-29 20:30 +0200
          Re: interpretation of wontfix Don Armstrong <don@debian.org> - 2018-03-28 20:10 +0200
            Re: interpretation of wontfix Sean Whitton <spwhitton@spwhitton.name> - 2018-03-29 00:10 +0200
              Re: interpretation of wontfix Andreas Tille <andreas@an3as.eu> - 2018-03-29 08:30 +0200
            Re: interpretation of wontfix Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-03-29 15:10 +0200
              Re: interpretation of wontfix Ian Campbell <ijc@debian.org> - 2018-03-29 15:20 +0200
                Re: interpretation of wontfix Scott Kitterman <debian@kitterman.com> - 2018-03-29 16:20 +0200
                Re: interpretation of wontfix Wouter Verhelst <wouter@debian.org> - 2018-03-29 16:30 +0200
                  Re: interpretation of wontfix Adrian Bunk <bunk@debian.org> - 2018-03-29 20:20 +0200
    Re: Usage of real m68k hardware Holger Levsen <holger@layer-acht.org> - 2018-03-28 14:00 +0200
      Re: Usage of real m68k hardware Russ Allbery <rra@debian.org> - 2018-03-28 19:30 +0200
        Enhanced syntax for Architecture field (Was: Usage of real m68k  hardware) Andreas Tille <andreas@an3as.eu> - 2018-03-28 20:30 +0200
          Re: Enhanced syntax for Architecture field (Was: Usage of real m68k  hardware) Adam Borowski <kilobyte@angband.pl> - 2018-03-28 22:30 +0200
            Re: Enhanced syntax for Architecture field Ole Streicher <olebole@debian.org> - 2018-03-29 09:50 +0200
              Re: Enhanced syntax for Architecture field Adam Borowski <kilobyte@angband.pl> - 2018-03-29 19:30 +0200
        Re: Usage of real m68k hardware Adrian Bunk <bunk@debian.org> - 2018-03-28 20:30 +0200
          Re: Usage of real m68k hardware Michael Gilbert <mgilbert@debian.org> - 2018-04-01 01:50 +0200
        Re: Usage of real m68k hardware Philipp Kern <pkern@debian.org> - 2018-03-28 22:00 +0200
          Re: Usage of real m68k hardware Russ Allbery <rra@debian.org> - 2018-03-28 22:30 +0200
    Re: Usage of real m68k hardware Sean Whitton <spwhitton@spwhitton.name> - 2018-03-28 19:10 +0200
    Re: Usage of real m68k hardware Wouter Verhelst <wouter@debian.org> - 2018-03-29 14:10 +0200
      Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-29 14:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#85171 — Re: interpretation of wontfix

On Wed, Mar 28, 2018 at 12:01:19PM +0100, Simon McVittie wrote:
> On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote:
> > I think "wontfix" is exactly the feature of the BTS that was invented to
> > solve the problem I described.  The bug is not closed and remains listed
> > - so everybody is free to ignore that tag and close the bug.
> 
> Is this how most people interpret wontfix?

Honestly, I don't know.

> I'd usually interpreted it as
> an indication of policy rather than priority: "I acknowledge that this
> is a bug, but it isn't going to change, even if you provide a patch".

I see your point.

> For instance, if there's a design flaw that people are now relying on,
> such that correcting the design flaw would cause regressions that are
> at least as bad as the design flaw itself, then that's an ideal use for
> my interpretation of wontfix.
> 
> In Bugzilla, WONTFIX and its cousins NOTABUG and NOTOURBUG are
> resolutions, not tags (you use them by closing a bug as RESOLVED WONTFIX
> instead of RESOLVED FIXED), which suggests that my interpretation matches
> that of Bugzilla's designers; but perhaps the wontfix tag in the Debian
> BTS was meant to mean something different?
> 
> I would tend to use the help tag, not the wontfix tag, for bugs where I
> don't intend to work on the bug myself but I'd consider applying a patch
> (including porting to non-release architectures).

When I use the help tag I usually do this together with asking for help
say on debian-mentors, upstream or elsewhere.  I do not hope that some
help just comes from simply setting the tag.  I also look into bug
reports that I've tagged help from time to time whether some help might
have arrived which I could have missed for some reason.

I confirm that with your interpretation of wontfix it would be misuse if
I would set it in the said case.  I checked the doc[1] and while the
beginning of the explanation would fit your interpretation it leaves
some kind of "open door" for me in the end: "... or possibly for other
reasons."

I do not want to base my arguing on this last phrase.  I was just
seeking some practical means to also keep my team mates away who might
become attracted by a "help" tag.  The three bugs in question that
triggered my initial mail kept at least two developers of R packaging
team busy and I would love to have some means to prevent this.  In case
we decide that wontfix is not the right answer for this problem (and I
agree with your reasoning) we could possibly invent some "porters" tag
or something like this which would probably be the best solution for
this problem.

Kind regards

       Andreas.

[1] https://www.debian.org/Bugs/Developer.html#tags

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#85173 — Re: interpretation of wontfix

* Andreas Tille <andreas@an3as.eu> [180328 07:51]:
> On Wed, Mar 28, 2018 at 12:01:19PM +0100, Simon McVittie wrote:
> > On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote:
> > > I think "wontfix" is exactly the feature of the BTS that was invented to
> > > solve the problem I described.  The bug is not closed and remains listed
> > > - so everybody is free to ignore that tag and close the bug.
> > 
> > Is this how most people interpret wontfix?
> 
> Honestly, I don't know.
> 
> > I'd usually interpreted it as
> > an indication of policy rather than priority: "I acknowledge that this
> > is a bug, but it isn't going to change, even if you provide a patch".
> 
> I see your point.

I also interpret wontfix as "patches will not be accepted; the current
behavior will stand."

> When I use the help tag I usually do this together with asking for help
> say on debian-mentors, upstream or elsewhere.  I do not hope that some
> help just comes from simply setting the tag.  I also look into bug
> reports that I've tagged help from time to time whether some help might
> have arrived which I could have missed for some reason.

I would also interpret the help tag as "yes, this should be fixed, but I
would appreciate some assistance with it."

It might be helpful to have a new tag (perhaps "ignored"?) that means
that the maintainer believes that the effort to fix this bug would not
provide enough benefit to the overall user base of the package to
warrant spending the time to fix, but if someone who did care provided a
clean, easy-to-review-and-apply patch, it would be applied as time
allows.

...Marvin

[toc] | [prev] | [next] | [standalone]

#85174 — Re: interpretation of wontfix

[Multipart message — attachments visible in raw view] — view raw

On Mar 28, Simon McVittie <smcv@debian.org> wrote:

> Is this how most people interpret wontfix? I'd usually interpreted it as
> an indication of policy rather than priority: "I acknowledge that this
> is a bug, but it isn't going to change, even if you provide a patch".
This is how I see it: keeping the bug around as documentation to prevent 
other people opening it again.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#85176 — Re: interpretation of wontfix

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 28, 2018 at 02:40:58PM +0200, Marco d'Itri wrote:
> This is how I see it: keeping the bug around as documentation to prevent 
> other people opening it again.

IME there are two (more) aspects when dealing with wontfix bugs: keeping
those bugs open, so they are more visible or closing them. I've come to
prefer closing them and trying to document them in README.Debian or some
such.

IMO both aspects are valid and it's a matter of taste.

(Similarily (to closing and documenting wontfix bugs) at the end of
piuparts.git/TODO there is list of closed wishlist bugs which I closed
not because the feature is unwanted, but because noone is working on them,
so they are just cluttering the BTS view... 
see http://blog.liw.fi/posts/wishlist-bugs for a longer rationale.)


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#85175 — Re: interpretation of wontfix

[Multipart message — attachments visible in raw view] — view raw

Quoting Simon McVittie (2018-03-28 13:01:19)
> On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote:
> > I think "wontfix" is exactly the feature of the BTS that was 
> > invented to solve the problem I described.  The bug is not closed 
> > and remains listed - so everybody is free to ignore that tag and 
> > close the bug.
> 
> Is this how most people interpret wontfix? I'd usually interpreted it 
> as an indication of policy rather than priority: "I acknowledge that 
> this is a bug, but it isn't going to change, even if you provide a 
> patch". For instance, if there's a design flaw that people are now 
> relying on, such that correcting the design flaw would cause 
> regressions that are at least as bad as the design flaw itself, then 
> that's an ideal use for my interpretation of wontfix.
> 
> In Bugzilla, WONTFIX and its cousins NOTABUG and NOTOURBUG are 
> resolutions, not tags (you use them by closing a bug as RESOLVED 
> WONTFIX instead of RESOLVED FIXED), which suggests that my 
> interpretation matches that of Bugzilla's designers; but perhaps the 
> wontfix tag in the Debian BTS was meant to mean something different?
> 
> I would tend to use the help tag, not the wontfix tag, for bugs where 
> I don't intend to work on the bug myself but I'd consider applying a 
> patch (including porting to non-release architectures).

That sounds like a similar confusion over severity - often interpreted 
by bugreporters as tied to the bugreporter, where we kindly inform that 
it is meant to reflect the distribution as a whole:

Seems the logic of Bugzilla (and Debian?) is that "wontfix is intended 
to be tied to the distribution as a whole, not the (current) maintainer 
of a package.

That logic makes sense to me, but I have personally interpreted it as 
tied to me as maintainer.

I would support simply adding a note to the documentation of our 
bugtracker that "wontfix" is tied to the project as a whole (which still 
leaves room for strongly opinionated maintainers to interpret that as 
"hell yeah, I hate that and I choose to speak for us all in hating that, 
so WONTFIX you go!"


 - Jonas

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

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

[toc] | [prev] | [next] | [standalone]

#85179 — Re: interpretation of wontfix

[Multipart message — attachments visible in raw view] — view raw

Dear Ian, Don,

On Wed, Mar 28 2018, Simon McVittie wrote:

> On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote:
>> I think "wontfix" is exactly the feature of the BTS that was invented
>> to solve the problem I described.  The bug is not closed and remains
>> listed
>> - so everybody is free to ignore that tag and close the bug.
>
> Is this how most people interpret wontfix? I'd usually interpreted it
> as an indication of policy rather than priority: "I acknowledge that
> this is a bug, but it isn't going to change, even if you provide a
> patch".  For instance, if there's a design flaw that people are now
> relying on, such that correcting the design flaw would cause
> regressions that are at least as bad as the design flaw itself, then
> that's an ideal use for my interpretation of wontfix.
>
> In Bugzilla, WONTFIX and its cousins NOTABUG and NOTOURBUG are
> resolutions, not tags (you use them by closing a bug as RESOLVED
> WONTFIX instead of RESOLVED FIXED), which suggests that my
> interpretation matches that of Bugzilla's designers; but perhaps the
> wontfix tag in the Debian BTS was meant to mean something different?
>
> I would tend to use the help tag, not the wontfix tag, for bugs where
> I don't intend to work on the bug myself but I'd consider applying a
> patch (including porting to non-release architectures).

I think it would be useful to have your opinions on this, as originators
(at different points in history) of the current set of BTS tags.

Perhaps we could improve the description of the tag on
<https://www.debian.org/Bugs/Developer>.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#85206 — Re: interpretation of wontfix

Sean Whitton writes ("Re: interpretation of wontfix"):
> On Wed, Mar 28 2018, Simon McVittie wrote:
...
> I think it would be useful to have your opinions on this, as originators
> (at different points in history) of the current set of BTS tags.

Thanks for asking me, but I don't think I have much useful historical
context to add.  If I had anything to do with the tags, my influence
(and any coherent rationale that might have been behind it) is long
gone.

Considering the question de novo: we have two uses for `wontfix'.  One
means `lack of effort' or `too difficult' (which are really two sides
or the same coin) and the other is `changing this would actually make
things worse'.  The docs currently document only the latter meaning,
although they do leave the door open by saying `other reasons'.

I often find myself wishing for some tags which relate
to how soon we intende to deal with a bug.  It would be possible to
use usertags for this but I think something shared would be more
useful.

Perhaps

   soon

       The maintainers intend to fix this bug quickly, probably in the
       next upload to Debian unstable.

     [ I find myself using a browser tab on my laptop for this, which
       is distinctly suboptimal. ]

   deferred
 
       The maintainers lack the effort to work on this bug in the
       foreseeable future.

       Contributions to help progress this bug would be welcome, and a
       correct fix would be accepted.  But, the maintainers advise
       that working on other bugs may be an easier way of making
       bigger improvements to Debian.

       If significant progress is made on the bug, a contributor
       should unset this tag to ask the maintainers to reassess the
       situation.

  deferred-CODENAME

       The maintainers lack the effort to to work on this bug, and
       this is not likely to change before the release of CODENAME.
       (Like `deferred', but with an explicit timescale.)

?

We could replace `wontfix' meaning `this bug is too hard' with
`deferred'.

Ian.

[toc] | [prev] | [next] | [standalone]

#85216 — Re: interpretation of wontfix

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu, Mar 29 2018, Ian Jackson wrote:

> I often find myself wishing for some tags which relate to how soon we
> intende to deal with a bug.  It would be possible to use usertags for
> this but I think something shared would be more useful.

Nice suggestion.

> We could replace `wontfix' meaning `this bug is too hard' with
> `deferred'.

Right, but we'd probably want to keep it for the case of "this shouldn't
be fixed because it'll break other stuff" etc.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#85229 — Re: interpretation of wontfix

On Thu, Mar 29, 2018 at 01:59:29PM +0100, Ian Jackson wrote:
>...
> Perhaps
> 
>    soon
> 
>        The maintainers intend to fix this bug quickly, probably in the
>        next upload to Debian unstable.
> 
>      [ I find myself using a browser tab on my laptop for this, which
>        is distinctly suboptimal. ]

If this would be useful for your personal workflow, it sounds like a 
perfect usecase for a usertag with you as user.

>    deferred
>  
>        The maintainers lack the effort to work on this bug in the
>        foreseeable future.
> 
>        Contributions to help progress this bug would be welcome, and a
>        correct fix would be accepted.  But, the maintainers advise
>        that working on other bugs may be an easier way of making
>        bigger improvements to Debian.
>...

Sounds like overdesign to me.

When I see a bug "FTBFS on big endian" with "help" tag and a maintainer 
statement in the bug "I don't care about big endian but I am willing
to apply patches", then that's all I need to know.

> Ian.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[toc] | [prev] | [next] | [standalone]

#85181 — Re: interpretation of wontfix

On Wed, 28 Mar 2018, Simon McVittie wrote:
> On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote:
> > I think "wontfix" is exactly the feature of the BTS that was invented to
> > solve the problem I described.  The bug is not closed and remains listed
> > - so everybody is free to ignore that tag and close the bug.
> 
> Is this how most people interpret wontfix? I'd usually interpreted it as
> an indication of policy rather than priority: "I acknowledge that this
> is a bug, but it isn't going to change, even if you provide a patch".

The documentation of wontfix[1] currently allows for both
interpretations, and I think both are OK, especially if that helps
maintainers filter out bugs that aren't ever going to be fixed.

I think that the use of wontfix+help can disambiguate between the two
interpretations.

For example:

1) wontfix: This bug isn't going to be fixed; don't bother helping.

2) wontfix+help: this bug requires too much effort to fix, so I won't be
   working on it, but patches will be accepted.

3) help: I want to fix this bug, but I'm blocking on assistance from
   someone

But that's not documented at all.

Would a sentence: "Use the help tag in addition to the wontfix tag if
you would still accept a patch that fixed this issue." to the wontfix
description be useful?

1: https://www.debian.org/Bugs/Developer#tags
-- 
Don Armstrong                      https://www.donarmstrong.com

I've had so much good luck recently I was getting sated with it. It's
like sugar, good luck. At first it's very sweet, but after a while you
start to think: any more of this and I shall be sick.
 -- Adam Roberts _Yellow Blue Tibia_ p301

[toc] | [prev] | [next] | [standalone]

#85189 — Re: interpretation of wontfix

[Multipart message — attachments visible in raw view] — view raw

Hello Don,

On Wed, Mar 28 2018, Don Armstrong wrote:

> The documentation of wontfix[1] currently allows for both
> interpretations, and I think both are OK, especially if that helps
> maintainers filter out bugs that aren't ever going to be fixed.
>
> I think that the use of wontfix+help can disambiguate between the two
> interpretations.
>
> For example:
>
> 1) wontfix: This bug isn't going to be fixed; don't bother helping.
>
> 2) wontfix+help: this bug requires too much effort to fix, so I won't be
>    working on it, but patches will be accepted.
>
> 3) help: I want to fix this bug, but I'm blocking on assistance from
>    someone
>
> But that's not documented at all.

Indeed.  This is the first I have heard of combining wontfix+help, and I
suspect I'm not the only one.

I am not sure I can distinguish between your cases (2) and (3).  Isn't
the reason you need assistance that it requires too much effort to fix?
Or are you distinguishing between needing help because it's too much
effort and needing help because you don't have the requisite knowledge?
(There is a sense in which these are the same thing.)

> Would a sentence: "Use the help tag in addition to the wontfix tag if
> you would still accept a patch that fixed this issue." to the wontfix
> description be useful?

Notwithstanding my comments above, I don't want to bikeshed, so yes, I
think such a sentence would be useful.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#85194 — Re: interpretation of wontfix

Hi Sean,

On Wed, Mar 28, 2018 at 03:08:23PM -0700, Sean Whitton wrote:
> 
> > The documentation of wontfix[1] currently allows for both
> > interpretations, and I think both are OK, especially if that helps
> > maintainers filter out bugs that aren't ever going to be fixed.
> >
> > I think that the use of wontfix+help can disambiguate between the two
> > interpretations.
> >
> > For example:
> >
> > 1) wontfix: This bug isn't going to be fixed; don't bother helping.
> >
> > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> >    working on it, but patches will be accepted.
> >
> > 3) help: I want to fix this bug, but I'm blocking on assistance from
> >    someone
> >
> > But that's not documented at all.
> 
> Indeed.  This is the first I have heard of combining wontfix+help, and I
> suspect I'm not the only one.
> 
> I am not sure I can distinguish between your cases (2) and (3).  Isn't
> the reason you need assistance that it requires too much effort to fix?

In my interpretation 3) means:  I need help and I'm actively seeking for
it by asking upstream, on debian-mentors, debian-ports, my parents ;-)
etc.  As I previously said I will also keep on watching this bug whether
some help might have been arrived in the bug log since I might have
missed something in the incoming channels.

In contrast to this in case 2) I will not check again a bug tagged
wontfix+help and I will not become active myself to seek for help.

> Or are you distinguishing between needing help because it's too much
> effort and needing help because you don't have the requisite knowledge?
> (There is a sense in which these are the same thing.)
> 
> > Would a sentence: "Use the help tag in addition to the wontfix tag if
> > you would still accept a patch that fixed this issue." to the wontfix
> > description be useful?
> 
> Notwithstanding my comments above, I don't want to bikeshed, so yes, I
> think such a sentence would be useful.

+1

Kind regards

      Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#85208 — Re: interpretation of wontfix

Don Armstrong writes ("Re: interpretation of wontfix"):
> 2) wontfix+help: this bug requires too much effort to fix, so I won't be
>    working on it, but patches will be accepted.

I dislike the use of "help" in this context.  If the maintainers think
the bug is not worth their *own* time, it seems perverse for the
maintainers to set a tag which suggests to other contributors that
they should spend *their* time on it.

In general I think it's obscure to treat the tag power set as a matrix
and define special meanings for combinations.

Ian.

[toc] | [prev] | [next] | [standalone]

#85209 — Re: interpretation of wontfix

On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
> Don Armstrong writes ("Re: interpretation of wontfix"):
> > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> >    working on it, but patches will be accepted.
> 
> I dislike the use of "help" in this context.  If the maintainers think
> the bug is not worth their *own* time, it seems perverse for the
> maintainers to set a tag which suggests to other contributors that
> they should spend *their* time on it.

The case which caused this thread was[0] "maintainer does not have the
time/inclination to investigate/fix bugs on this non-release
architecture", the implication being that "the porters of that arch
should deal with this bug and provide a patch which the maintainer will
evaluate".

To that end perhaps this is a special enough case of "help" that a
specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
tags or a combination of "porter" and "ARCH" tags, or whatever). In
fact I don't see why we would limit it to non-release arches, it seems
useful for release arches too.

Or perhaps this just needs a consensus on the appropriate use of some
`port@debian.org` usertags?

Ian.

[0] approximately and appologies if I've grossly mischaracterized this.

[toc] | [prev] | [next] | [standalone]

#85213 — Re: interpretation of wontfix

On March 29, 2018 1:16:31 PM UTC, Ian Campbell <ijc@debian.org> wrote:
>On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
>> Don Armstrong writes ("Re: interpretation of wontfix"):
>> > 2) wontfix+help: this bug requires too much effort to fix, so I
>won't be
>> >    working on it, but patches will be accepted.
>> 
>> I dislike the use of "help" in this context.  If the maintainers
>think
>> the bug is not worth their *own* time, it seems perverse for the
>> maintainers to set a tag which suggests to other contributors that
>> they should spend *their* time on it.
>
>The case which caused this thread was[0] "maintainer does not have the
>time/inclination to investigate/fix bugs on this non-release
>architecture", the implication being that "the porters of that arch
>should deal with this bug and provide a patch which the maintainer will
>evaluate".
>
>To that end perhaps this is a special enough case of "help" that a
>specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
>tags or a combination of "porter" and "ARCH" tags, or whatever). In
>fact I don't see why we would limit it to non-release arches, it seems
>useful for release arches too.
>
>Or perhaps this just needs a consensus on the appropriate use of some
>`port@debian.org` usertags?
>
>Ian.
>
>[0] approximately and appologies if I've grossly mischaracterized this.

Personally, I find the "I don't think it's worth the effort, but if you think it is, I'll accept a patch" case to be reasonably common.

I don't think it's about power.  I think it's about different priorities and perspectives.

Scott K

[toc] | [prev] | [next] | [standalone]

#85214 — Re: interpretation of wontfix

On Thu, Mar 29, 2018 at 02:16:31PM +0100, Ian Campbell wrote:
> On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
> > Don Armstrong writes ("Re: interpretation of wontfix"):
> > > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> > >    working on it, but patches will be accepted.
> > 
> > I dislike the use of "help" in this context.  If the maintainers think
> > the bug is not worth their *own* time, it seems perverse for the
> > maintainers to set a tag which suggests to other contributors that
> > they should spend *their* time on it.
> 
> The case which caused this thread was[0] "maintainer does not have the
> time/inclination to investigate/fix bugs on this non-release
> architecture", the implication being that "the porters of that arch
> should deal with this bug and provide a patch which the maintainer will
> evaluate".
> 
> To that end perhaps this is a special enough case of "help" that a
> specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
> tags or a combination of "porter" and "ARCH" tags, or whatever). In
> fact I don't see why we would limit it to non-release arches, it seems
> useful for release arches too.
> 
> Or perhaps this just needs a consensus on the appropriate use of some
> `port@debian.org` usertags?

You mean like https://lists.debian.org/debian-devel-announce/2009/03/msg00015.html ?

(that never really caught on though)

I still think that having a per-port tag (which is *not* a usertag)
would be a good idea, but Don wasn't convinced (at the time; perhaps he
could be convinced today).

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab

[toc] | [prev] | [next] | [standalone]

#85228 — Re: interpretation of wontfix

On Thu, Mar 29, 2018 at 04:21:58PM +0200, Wouter Verhelst wrote:
> On Thu, Mar 29, 2018 at 02:16:31PM +0100, Ian Campbell wrote:
> > On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
> > > Don Armstrong writes ("Re: interpretation of wontfix"):
> > > > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> > > >    working on it, but patches will be accepted.
> > > 
> > > I dislike the use of "help" in this context.  If the maintainers think
> > > the bug is not worth their *own* time, it seems perverse for the
> > > maintainers to set a tag which suggests to other contributors that
> > > they should spend *their* time on it.
> > 
> > The case which caused this thread was[0] "maintainer does not have the
> > time/inclination to investigate/fix bugs on this non-release
> > architecture", the implication being that "the porters of that arch
> > should deal with this bug and provide a patch which the maintainer will
> > evaluate".
> > 
> > To that end perhaps this is a special enough case of "help" that a
> > specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
> > tags or a combination of "porter" and "ARCH" tags, or whatever). In
> > fact I don't see why we would limit it to non-release arches, it seems
> > useful for release arches too.
> > 
> > Or perhaps this just needs a consensus on the appropriate use of some
> > `port@debian.org` usertags?
> 
> You mean like https://lists.debian.org/debian-devel-announce/2009/03/msg00015.html ?
> 
> (that never really caught on though)
> 
> I still think that having a per-port tag (which is *not* a usertag)
> would be a good idea, but Don wasn't convinced (at the time; perhaps he
> could be convinced today).

When looking at FTBFS on the buildds common patterns are e.g.:
- FTBFS on big endian
- FTBFS on 32bit
- FTBFS on architectures where char is unsigned

I would not see the benefits of tagging 8 ports when the pattern of 
red/green makes it clear that the problem is due to char being unsigned.

There are special cases like config.{guess,sub} on brand-new archs,
but otherwise it is very rare that a package fails on exactly one 
architecture only.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[toc] | [prev] | [next] | [standalone]

#85170

[Multipart message — attachments visible in raw view] — view raw

Hi Andreas,

I'd suggest you let go and stop caring about m68k. m68k has been dropped
from Debian many releases ago, thus IMO bugs affecting only m68k are
probably at most normal severity, though minor or wishlist IMO make
equally sense. Or just closing them as out of scope. Or you could tag
them "help" and move on. The important thing is to let go and move on.
 
And please, m68k folks, dont get me wrong, I'm fascinated by your work and
applaud your efforts. I just dont think they should get in the way of
working on Debian (on our supported hardware plattforms). 


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#85180

Holger Levsen <holger@layer-acht.org> writes:

> I'd suggest you let go and stop caring about m68k. m68k has been dropped
> from Debian many releases ago, thus IMO bugs affecting only m68k are
> probably at most normal severity, though minor or wishlist IMO make
> equally sense. Or just closing them as out of scope. Or you could tag
> them "help" and move on. The important thing is to let go and move on.
>  
> And please, m68k folks, dont get me wrong, I'm fascinated by your work
> and applaud your efforts. I just dont think they should get in the way
> of working on Debian (on our supported hardware plattforms).

Back when I was maintaining OpenAFS, I frequently wanted some way as a
maintainer to easily tag a package as "this will never for the forseeable
future be supported on this architecture" and move on.  We don't have a
great mechanism for doing this right now -- there's a thing on the buildds
that's pretty opaque and that I don't know how to set as a maintainer, and
one can list a bunch of specific architectures on the package but that's
really awkward and interacts poorly with arch: all packages.

The chances of anyone really wanting to run some of this scientific
software on m68k seem remote, so it feels like it would be an overall
reduction of friction if the maintainer could just say "I don't support
this arch" and the porters could stop looking at those packages (unless
for some reason they disagree with the maintainer and think users of that
arch are really interested).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#85182 — Enhanced syntax for Architecture field (Was: Usage of real m68k hardware)

Hi Adrian,

On Wed, Mar 28, 2018 at 09:24:12PM +0300, Adrian Bunk wrote:
> 
> Dependency fields have negative syntax like !m68k, for the Architecture: 
> field this is only possible with a complete list of all architectures
> except the one you want to exclude.

I agree this could really simplify things and I would have used this
syntax in several cases.

Kind regards

     Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.devel

csiph-web