On Fri, 9 Feb 2018 13:13:37 -0200 Rafael Fontenelle wrote:

I don't see it as mandatory, but if I was the maintainer of this development package I would do as the developer says and request package deletion.

I, on the other hand, wouldn't. The entire point of -<vcs> packages is to run the incomplete development code, anyone that's running it should understand that it's incomplete and potentially unstable.

On Wed, 14 Feb 2018 12:16:57 +0100 (CET) Alad Wenter via aur-general wrote:

...

Doug Newgard via aur-general hat am 9. Februar 2018 um 16:22 geschrieben:

On Fri, 9 Feb 2018 13:13:37 -0200 Rafael Fontenelle wrote:

...

I don't see it as mandatory, but if I was the maintainer of this development package I would do as the developer says and request package deletion.

I, on the other hand, wouldn't. The entire point of -<vcs> packages is to run the incomplete development code, anyone that's running it should understand that it's incomplete and potentially unstable.

I don't see how that justifies explicitely going the wishes of upstream. If the author doesn't want feedback on his development code, that's his choice and it's not our place to motivate him otherwise by keeping this package.

Alad

Getting feedback on the code doesn't have much do to with the existence of this package. Two totally different issues.

On 02/14/2018 09:09 AM, Alad Wenter via aur-general wrote:

...

Doug Newgard via aur-general hat am 14. Februar 2018 um 14:33 geschrieben:

Getting feedback on the code doesn't have much do to with the existence of this package. Two totally different issues. Well, upstream disagrees. To quote his email again,

"Could you please remove this package? I keep getting bug reports for it, but the thing is, the SVN version is not intended for public consumption at all."

That seems like a problem which is solved by upstream providing instructions on the bug reporting page, that bugs should only ever be reported for stable releases and not for the development code. Taking the package down from the AUR will not solve the root of his problem, even if it does hide the worst offender. And I'm unconvinced that we should punish people who just want to use the latest code in blissful peace. So, I guess the question is, what does "not intended for public consumption at all" actually mean? - If it means "the code is unstable and probably broken, so it is a bad idea to use it and I won't support you in doing so", then the package should be deleted for reasons that have nothing to do with the developer's request. - If it means "I don't like to be bothered by bugreports because I consider nothing to be official unless I make a stable release, and I would rather discover the issue myself", then there is no reason to stop people from running perfectly good development software that has been publicly published. And the developer should just tell people his preferences on the support page where he leaves his email-based bug reporting instructions. ... Aside: ewwwwwww email-based bugtracker. He probably gets a fair number of duplicate bug reports for the versions he *does* want people to report bugs for, because intelligent and capable users still have no way of determining if a bug was already reported. If he wants less distracting bug mail, he is going about it entirely the wrong way... -- Eli Schwartz Bug Wrangler and Trusted User

> Simon Doppler  hat am 14. Februar 2018 um 15:46 geschrieben:
> 
> 
> On Wednesday, 14 February 2018 15:29:29 CET Eli Schwartz via aur-general 
> wrote:
> > > "Could you please remove this package? I keep getting bug reports for
> > > it, but the thing is, the SVN version is not intended for public
> > > consumption at all."
> > [...]
> > - If it means "I don't like to be bothered by bugreports because I
> >   consider nothing to be official unless I make a stable release, and I
> >   would rather discover the issue myself", then there is no reason to
> >   stop people from running perfectly good development software that has
> >   been publicly published. And the developer should just tell people his
> >   preferences on the support page where he leaves his email-based bug
> >   reporting instructions.
> 
> In this case, he should not publish the development code anyway, since nothing 
> will stop users from submitting bug reports for development code (whether it 
> is mail based bug reporting, mailing list based, using Git{hub,lab,*}-style 
> issues or an actual bugtracker).
> 
It's disappointing how everyone shifts the blame towards and ridicules upstream, rather than respect their wishes regarding the _packaging of their own code_. Those are practices that remind of certain other distributions. But whatever - I shall not further argue about it.

John: Please include a post_install/post_upgrade message in your package that warns users on _not_ to complain to upstream in case of errors.

Alad

On 14/02/18 15:19, Alad Wenter via aur-general wrote:

John: Please include a post_install/post_upgrade message in your package that warns users on _not_ to complain to upstream in case of errors.

Alad

I have done this now. I have also disowned it because I no longer have a requirement for it and it would be better if someone could take it on that actually needs it. Note that the package in its current state does not build. I have added a note to this effect to its AUR page.

Probably by committing directly to master for every commit instead of merging from another branch when you're finished your new feature. I do this for small one person projects, i don't care if this commit breaks the build cause I'll fix it in the next one. On 15 February 2018 at 19:54, mar77i via aur-general wrote:

-------- Original Message -------- On February 14, 2018 3:46 PM, Simon Doppler dopsi@dopsi.ch wrote:

...

On Wednesday, 14 February 2018 15:29:29 CET Eli Schwartz via aur-general In this case, he should not publish the development code anyway, since nothing will stop users from submitting bug reports for development code (whether it is mail based bug reporting, mailing list based, using Git{hub,lab,*}-style issues or an actual bugtracker). Simon Doppler (dopsi) E: dopsi@dopsi.ch

I seriously wonder, though. How *do* you so consistently break things between releases?

cheers! mar77i

Sent with ProtonMail Secure Email.