[aur-general] TU Application - Dustin Falgout

[Levente Polyak]

On 03/02/2016 11:58 PM, Dustin Falgout wrote:
>> To: aur-general at archlinux.org> From: anthraxx at archlinux.org
>> Date: Wed, 2 Mar 2016 22:48:27 +0100
>> Subject: Re: [aur-general] TU Application - Dustin Falgout
>>
>> On 03/02/2016 09:19 PM, Balló György wrote:
>>> If you don't specify tag or commit hash at the end of the git source, then
>>> you should use the -git suffix. Users expect if the package has no -git
>>> suffix, then it's a working static version tested by the maintainer, and
>>> not some experimental code from git HEAD.
>>>
>>
>> Its not just a should but a guideline rule [0] that must be followed
>> upon. For official repositories it is mandatory and will also be
>> enforced because of multiple reasons: the most obvious ones are rebuilds
>> on sobumps and reproducible packages (not yet there but a topic that is
>> being worked on).
>> The only difference is that (besides that the AUR is unsupported) on the
>> AUR people may not notice it or care enough to enforce that. However, in
>> my personal opinion, a trusted user should do things above the general
>> average, that's IMHO why someone should be _trusted_.
>>
>>
>> On 03/02/2016 08:21 PM, Dustin Falgout wrote:
>>> I do have a sane reason indeed. Upstream is not following their
>>> github releases. If you look in openSUSE's package repo you will see >
>> that they are packaging the latest master as the most recently
>>> released version. Looking at the history of those packages it seems
>>> that whoever is maintaining the packages over at openSUSE does not
>>> use github releases in their release process on a regular basis.
>>
>> It applies for just one out of 3 packages, you should fully check your
>> claim before using it as an argument. Also 2/3 of those packages are not
>> something that could be considered "not released on regular basis"
>>
>> obs-service-set_version:
>> - last release: Sep 3, 2015
>> - patch commits since release: 4
>> - openSUSE version [1]: 0.5.3 release
>>
>> obs-service-tar_scm:
>> - last release: Jun 1, 2015
>> - patch commits since release: 9
>> - openSUSE version [2]: 0.5.3 0b4ce51 (2 patch commits since release)
>>
>> obs-service-recompress:
>> - last release: Nov 5, 2013
>> - patch commits since release: 7
>> - openSUSE version [3]: 7897d3f (7 patch commits since release)
>>
>> Actually, as mentioned above, its just the recompress packages that
>> really falls out of scope. The tar_scm is just a debian control file fix
>> and a missing extension parameter to service file.
>> I don't see any point why the release is not sufficient for those. Also
>> did you try to contact upstream about a recompress release?
>>
>>
>> On 03/02/2016 08:21 PM, Dustin Falgout wrote:
>>> Considering that, it doesnt make sense to tag the end of the pkgname >
>> with "-git"
>>
>> As mentioned in my very first section, this part is not something that
>> can be argued upon [0], there are just two sane possibilities:
>> 1) use a static version and have the pure package name
>> 2) use non-static VCS (like git HEAD) and add such postfix to pkgname
>>
>> cheers,
>> Levente
>>
>> [0] https://wiki.archlinux.org/index.php/VCS_package_guidelines#Guidelines
>> [1]
>> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-set_version
>> [2]
>> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-tar_scm
>> [3]
>> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-recompress
> 
> 
>> It applies for just one out of 3 packages, you should fully check your
>> claim before using it as an argument

> I'm sorry, I did not realize we were having an argument. You asked me why I
> did it the way that I did and I explained. If I was planning to move those
> packages into community or if I thought there was even the remote possibility
> of my doing so, I would certainly make sure the packages were inline with the
> repo guidelines. However, that is not the case here. Those three packages are
> no longer of much use to me at this point. I didn't want to just orphan them
> considering they weren't requiring much from me in terms of maintenance so I
> kept them. In any case, I understand what you are saying. I am not now, nor was
> I ever, saying you are wrong. I should have made been more clear about that,
> my apologies. 
> 
> Best Regards,Dustin 		 	   		  
> 

Excuse me being a bit late, I was planning to respond before the end of
the discussion but was held up from real life things.

I did not intended it just as a question to get an explanation, it was
more a dialogue of improving your packages and making you aware of some
problems. To be honest I'm still a bit confused and wondering as you
implemented the quotes around the $pkgdir to those "abandoned" packages
but they still pull the git HEAD and that part was fully ignored
(besides acknowledging here that you don't think I'm wrong).

Being inline with general guidelines and having quality in PKGBUILDs
shouldn't be something exclusive to the binary repositories but a
general belief and ambition. Especially as a TU, quality and ambition to
do the best and follow the general belief of the guidelines is something
that is desired to be followed everywhere, no difference if AUR, binary
repository or other parts of the ecosystem.

Sincerely,
Levente