Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Jonathan Dowland]

Hi Herbert,

On Mon, Jan 01, 2018 at 02:38:41PM -0200, Herbert Fortes wrote:

I opened an 'O' bug and you can take
the maintenance of the package. Which
is in good shape.


OK, thank you (yes it is in good shape). Thank you for packaging duc and
all your work on it. You will always be welcome to contribute to it
again if you want to. I hope you continue to contribute to Debian, and
best wishes to you with that!


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

Hi Jonathan,

You have more interesting in the
package than me.

I opened an 'O' bug and you can take
the maintenance of the package. Which
is in good shape.

Do not worry about anything.



Kind Regards,
Herbert

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

On 30/12/2017 13:41, Andrew Shadura wrote:

Hi,

On 30 December 2017 at 11:53, Herbert Fortes  wrote:




But I do not understand. It seems to me that an alias
solves the issue. And the user can set anything he
wants. Base on that, the use of 'Conflicts' seems too
much. It changes a lot of things. What am I not seem ?
  I learned that a NMU is when the package has a maintainer
but the maintainer does not take care the package, the
maintainer does not shows some activity for some time.


An alias is something the user would need to manually set up. Some users
might not know aliases exist, others might not want to set up an alias.
Why make the life of a user more inconvenient, when you as a maintainer
can fix that on your side?



Alias is really simple. And fix the issue.


It is one more thing the user has to do. You could do something to
free the user from this one extra action.


Change the way package is because one does
not want to press tab and upload a NMU is
awfull.


Could you please explain why are you so against changing the package
to make it a bit easier to use?



Why be so frustated to press tab or edit a file to
put one line, one time only.

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

use collab-maint? I did not need to do an NMU, I could have done a
regular upload. The reason I did this as an NMU, and the reason I used
the DELAYED queue, was just as a courtesy to you.


A NMU is when a maintainer does not care about
the package for a long time. And it is to fix
something. I did not a courtesy. A package has
a maintainer you talk to the maintainer first.

You understand a NMU wrong.

Your first upload was wrong. You do not think
about an upgrade. A 'what if' arguments can go
both sides. You are only seem yours.

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Jonathan Dowland]

Hi Herbert,

On Fri, Dec 29, 2017 at 07:05:18PM -0200, Herbert Fortes wrote:

But I do not understand. It seems to me that an alias solves the issue.
And the user can set anything he wants.


Each individual user could indeed add an alias themselves, but we could
remove the need for them to do so. One problem with the alias approach
is if you have multiple machines, some with duc and some with duc-nox,
and you use a common bashrc file, you would need to do more than just
add an alias.

This is not a "big" deal, sure, it's a small one, but we should fix
small ones as well as big. That's the beauty of Open Source IMHO. And
most of the work has been done already for this one.


Base on that, the use of 'Conflicts' seems too much. It changes a lot
of things.


Let me ask, what is the problem with a Conflicts? What circumstance is
there that this would cause a problem? I couldn't think of any. It's a
very small patch to the package sources as it turns out (much smaller
than an alternatives-based approach).


I learned that a NMU is when the package has a maintainer
but the maintainer does not take care the package, the
maintainer does not shows some activity for some time.


That's one reason for NMUs, but not the only reason. In the past, we had
a strong link between packages and maintainers, and a problem when
maintainers were busy or not active, and so NMUs were created. But these
days, maintaining packages collaboratively and not having a strong
maintainer:package relationship is more common and Debian is much
healthier for it. One tool for this is the "collab-maint" project: and
indeed, you have already packaged duc via collab-maint! So, you are
already signalling that the package can and should be maintained by any
capable maintainer. Was this not your understanding when you chose to
use collab-maint? I did not need to do an NMU, I could have done a
regular upload. The reason I did this as an NMU, and the reason I used
the DELAYED queue, was just as a courtesy to you.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Andrew Shadura]

Hi,

On 30 December 2017 at 11:53, Herbert Fortes  wrote:
>
>>>
>>> But I do not understand. It seems to me that an alias
>>> solves the issue. And the user can set anything he
>>> wants. Base on that, the use of 'Conflicts' seems too
>>> much. It changes a lot of things. What am I not seem ?
>>>  I learned that a NMU is when the package has a maintainer
>>> but the maintainer does not take care the package, the
>>> maintainer does not shows some activity for some time.
>>
>> An alias is something the user would need to manually set up. Some users
>> might not know aliases exist, others might not want to set up an alias.
>> Why make the life of a user more inconvenient, when you as a maintainer
>> can fix that on your side?

> Alias is really simple. And fix the issue.

It is one more thing the user has to do. You could do something to
free the user from this one extra action.

> Change the way package is because one does
> not want to press tab and upload a NMU is
> awfull.

Could you please explain why are you so against changing the package
to make it a bit easier to use?

-- 
Cheers,
  Andrew

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

>>
>> But I do not understand. It seems to me that an alias 
>> solves the issue. And the user can set anything he 
>> wants. Base on that, the use of 'Conflicts' seems too 
>> much. It changes a lot of things. What am I not seem ?
>>  I learned that a NMU is when the package has a maintainer 
>> but the maintainer does not take care the package, the 
>> maintainer does not shows some activity for some time.
> 
> An alias is something the user would need to manually set up. Some users
> might not know aliases exist, others might not want to set up an alias.
> Why make the life of a user more inconvenient, when you as a maintainer
> can fix that on your side?
> 

Alias is really simple. And fix the issue.

Change the way package is because one does
not want to press tab and upload a NMU is
awfull.



Regards,
Herbert

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Andrew Shadura]

On 29/12/17 22:05, Herbert Fortes wrote:
> Hi Andrew Shadura and Jonathan Dowland,
> 
> 
> First, let's not make big noise about this.
> 
> But I do not understand. It seems to me that an alias 
> solves the issue. And the user can set anything he 
> wants. Base on that, the use of 'Conflicts' seems too 
> much. It changes a lot of things. What am I not seem ?
>  I learned that a NMU is when the package has a maintainer 
> but the maintainer does not take care the package, the 
> maintainer does not shows some activity for some time.

An alias is something the user would need to manually set up. Some users
might not know aliases exist, others might not want to set up an alias.
Why make the life of a user more inconvenient, when you as a maintainer
can fix that on your side?

If you think Conflicts is too strong, you can provide alternatives, an
option Jonathan has suggested. That would allow the user to co-install
two packages if they want, but if you make the X11 version of the
package provide an alternative with a higher priority, it will be used
by default when both packages are installed.

-- 
Cheers,
  Andrew

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

Hi Andrew Shadura and Jonathan Dowland,


First, let's not make big noise about this.

But I do not understand. It seems to me that an alias 
solves the issue. And the user can set anything he 
wants. Base on that, the use of 'Conflicts' seems too 
much. It changes a lot of things. What am I not seem ?
 I learned that a NMU is when the package has a maintainer 
but the maintainer does not take care the package, the 
maintainer does not shows some activity for some time.



Regards,
Herbert

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Andrew Shadura]

Hi,

On Fri, 29 Dec 2017 19:46:38 + Jonathan Dowland  wrote:
> On Thu, Dec 28, 2017 at 09:18:32PM -0200, Herbert Fortes wrote:
> >Please, do not be so fast.
> 
> That's why I uploaded to DELAYED-7 -- so it wasn't fast.
> 
> >Does all that work really necessary ? There is no complain
> >until this week
> 
> It's been bugging me for a while but I've only just had time to file the
> bug (and work on the fix).
> 
> > and there are others packages with the same situation.
> 
> I haven't personally been affected by other packages in this situation,
> but if I was, I might try to fix them too.
> 
> On Thu, Dec 28, 2017 at 09:21:27PM -0200, Herbert Fortes wrote:
> >You already did the upload.
> >
> >I will cancel it.
> 
> On Thu, Dec 28, 2017 at 09:36:03PM -0200, Herbert Fortes wrote:
> >I will really appreciate if you cancel the NMU.
> 
> I think you already have? I can no longer see it in the DELAYED queue.
> 
> Now that you are engaging here I'd love to hear your opinion on your
> preferred approach going forward. I was actually about to cancel my
> upload because the Conflicts: in the duc binary needs to be versioned
> for smooth upgrades in the situation where someone has both installed
> already (work I have completed this evening).
> 
> Looking forward to hearing from you (and thanks for packaging duc in the
> first place)

I would like to say I agree here with Jonathan, there's no reason not to
have both packages provide the same binary. It's not difficult to
implement, and makes it is easier for our users to run — and users are
our priority in Debian.

If I were the maintainer, I would give this a second thought.

-- 
Cheers,
  Andrew

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Jonathan Dowland]

On Thu, Dec 28, 2017 at 09:18:32PM -0200, Herbert Fortes wrote:

Please, do not be so fast.


That's why I uploaded to DELAYED-7 -- so it wasn't fast.


Does all that work really necessary ? There is no complain
until this week


It's been bugging me for a while but I've only just had time to file the
bug (and work on the fix).


and there are others packages with the same situation.


I haven't personally been affected by other packages in this situation,
but if I was, I might try to fix them too.

On Thu, Dec 28, 2017 at 09:21:27PM -0200, Herbert Fortes wrote:

You already did the upload.

I will cancel it.


On Thu, Dec 28, 2017 at 09:36:03PM -0200, Herbert Fortes wrote:

I will really appreciate if you cancel the NMU.


I think you already have? I can no longer see it in the DELAYED queue.

Now that you are engaging here I'd love to hear your opinion on your
preferred approach going forward. I was actually about to cancel my
upload because the Conflicts: in the duc binary needs to be versioned
for smooth upgrades in the situation where someone has both installed
already (work I have completed this evening).

Looking forward to hearing from you (and thanks for packaging duc in the
first place)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

tags 885404 = wontfix
thanks


I do not see enough reason to change the way 
the package is. It is not hard to tab-complete.

The proposed solution was not Policy-preferred.
And force a NMU is not polite. NMU is not the
case.

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

On 28/12/2017 20:38, Jonathan Dowland wrote:

I've now implemented both and I'm leaning towards a simple Conflicts.

The Conflicts version is branch jmtd/885404-proposed:
6 files changed, 15 insertions(+), 4 deletions(-)
Lintian clean.

The alternatives version is branch jmtd/885404-alt:
10 files changed, 67 insertions(+), 3 deletions(-)
*Not* Lintian clean: needs an override for the test of relations against
the packages own name (Breaks << older versions).
This also potentially has multiarch problems.

It took me a fraction of the time to implement the proposed version.

I'm going to sleep on it but I plan to upload an NMU to DELAYED-7.



Better thinking.

I will really appreciate if you cancel the NMU.

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

On 28/12/2017 20:38, Jonathan Dowland wrote:

I've now implemented both and I'm leaning towards a simple Conflicts.

The Conflicts version is branch jmtd/885404-proposed:
6 files changed, 15 insertions(+), 4 deletions(-)
Lintian clean.

The alternatives version is branch jmtd/885404-alt:
10 files changed, 67 insertions(+), 3 deletions(-)
*Not* Lintian clean: needs an override for the test of relations against
the packages own name (Breaks << older versions).
This also potentially has multiarch problems.

It took me a fraction of the time to implement the proposed version.

I'm going to sleep on it but I plan to upload an NMU to DELAYED-7.




You already did the upload.

I will cancel it.

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Herbert Fortes]

On 28/12/2017 20:38, Jonathan Dowland wrote:

I've now implemented both and I'm leaning towards a simple Conflicts.

The Conflicts version is branch jmtd/885404-proposed:
6 files changed, 15 insertions(+), 4 deletions(-)
Lintian clean.

The alternatives version is branch jmtd/885404-alt:
10 files changed, 67 insertions(+), 3 deletions(-)
*Not* Lintian clean: needs an override for the test of relations against
the packages own name (Breaks << older versions).
This also potentially has multiarch problems.

It took me a fraction of the time to implement the proposed version.

I'm going to sleep on it but I plan to upload an NMU to DELAYED-7.



Please, do not be so fast.

Does all that work really necessary ? There is no complain
until this week and there are others packages with the same
situation.



Regards,
Herbert






 

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Jonathan Dowland]

I've now implemented both and I'm leaning towards a simple Conflicts.

The Conflicts version is branch jmtd/885404-proposed:
6 files changed, 15 insertions(+), 4 deletions(-)
Lintian clean.

The alternatives version is branch jmtd/885404-alt:
10 files changed, 67 insertions(+), 3 deletions(-)
*Not* Lintian clean: needs an override for the test of relations against
the packages own name (Breaks << older versions).
This also potentially has multiarch problems.

It took me a fraction of the time to implement the proposed version.

I'm going to sleep on it but I plan to upload an NMU to DELAYED-7.


Thanks,

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Jonathan Dowland]

On a closer reading of Policy, using alternatives is preferred, even if
a bit more complex.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.