[arch-general] Participation of Arch in Google Summer of Code.

[Eli Schwartz]

On 2/19/19 1:20 AM, Michael Lojkovic via arch-general wrote:
> On Sat, 2 Feb 2019 20:51:37 +0530
> Aniket Pradhan <aniket17133 at iiitd.ac.in> wrote:
> 
>> Hello Govind, and Everyone!
>>
>> Thanks for your feedback.
>>
>> Your arguments are on point, and I agree with you on the fact that the
>> ideas do not apply to Arch.
>>
>> If we can think of some better ideas (which apply to Arch, like the
>> reproducible builds or the CLI tool as you discussed) we would need
>> people to step up and mentor these ideas out of their free time.
>> Moreover, if Arch is willing to include some community tools (who
>> decides which tools should be included), we might get some more cool
>> ideas, but in the end, we would also need someone to mentor the idea.
>>
>> In the end, it all boils down to the availability of mentors. and
>> ideas.
>>
>> I also had this cool idea, where developers (who will act as mentors)
>> can pitch in their ideas for community packages and select students
>> through GSoC. This will provide them with the necessary help in
>> developing the tool. However, then it would not be a
>> "community-driven" package, would it?
>>
>> There can be several flaws to this suggestion, but as Govind said, it
>> would be amazing if others can share their opinion on this topic.
>>
> 
> The only thing I can think of, which applies to Arch is implementing
> remakepkg features in pacman. I was going to add those in when I got
> around to it, but it's also worth doing for Google Summer of Code.
> 
>  https://bbs.archlinux.org/viewtopic.php?id=236076

You need the Google Summer of Code to implement an external tool that
has already been implemented?

Who told you to declare that this is definitively a desired,
guaranteed-to-be-accepted feature, moreso that it is the only
outstanding feature for the pacman project? We have 219 outstanding bug
reports and feature requests, some of which would implement valuable
safety features like aborting gracefully (rather than crashing after
invalidating your system) if the user does something unwise like
overwrite /var/cache/pacman/pkg with a symbolic link.

"People want to know what they could do for Arch for GSOC", and you
advertise some personal interest as being representative of the only
thing you think Arch needs? When people have already mentioned things
like pacman itself (see the aforementioned 219 bugtracker tickets), the
build system and reproducible builds efforts, the security tracker...

"The only thing I can think of which applies to Arch" is something no
one has ever requested be added to makepkg, and furthermore -- it is out
of scope. makepkg builds packages based on source code, remakepkg
mutates existing ones in a manner that is not applicable to PKGBUILDs.
makepkg can already --repackage your build directory with a modified
PKGBUILD, if you ask it to, which is in scope for makepkg because it
just involves picking up a makepkg build halfway through.

Seems to me like remakepkg is already a perfectly suitable thirdparty
tool that shares no commonality with makepkg, hence why it is a
*thirdparty utility* -- and pacman is not the canonical provider of
thirdparty utilities. Nor should it be -- if the primary "person who
cares" about the tool does not regularly interact with the pacman-dev
mailing list, the code would simply rot as part of pacman, and
furthermore, even if it did see active development in the pacman tree,
it would be forced to conform to the slower release cycle of pacman for
no reason.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190219/ec0d582a/attachment.sig>