Re: [gentoo-dev] questions about small fixes/cleanups

[Daniel Campbell]

On 09/13/2016 11:57 AM, Michael Mair-Keimberger wrote:
> Hello Gentoo-Team,
>
> For some time now I'm trying to help improve the gentoo tree. I've
> started with fixing some HOMEPAGE variables in ebuilds and now removing
> obsolete patches from packages.
> Usually (especially with obsolete patches) it's quite simple to fix
> things, however every now and then i find some "special" cases were i
> don't know whats correct way to fix it.
> Even though i could ask on irc, I'm usually to lazy and now there are a
> few question were i would like to have an answer for. :)
>
> Homepages:
> * Dead homepages: I know there is this general rule of pointing to the
> 	No_homepage wiki page if there is no upstream homepage. However,
> 	when I fixed some homepage's i usually used an archived [1] homepage
> 	of the original homepage. While for some dev's this isn't a
> 	problem, others do not like the idea.
> 	Personally i would prefer having some homepage rather than no
> 	homepage at all. It would be nice to have a clear statement
> 	about that.
> * Waiting time: I couldn't find any references of how long to wait until
> 	a homepage can be changed because it's offline. Usually i would
> 	check for bugs, because if the bug is already quite old and the
> 	homepage is still offline it's safe to say we can change them.
> 	However, i also have an script which checks for offline
> 	homepages. But since a homepage can be temporally offline or just
> 	not available from my side of the internet i would like to know
> 	how long i should wait until i can fix it. I think 1 month
> 	would be a good start?
> * Redirection: There are quite a few pages which aren't exactly offline,
> 	but only forward the request to the current homepage. (like most
> 	of the gentoo project pages). I haven't touch them yet, but i
> 	would like to know if fixing them would be appreciated?
> * old ebuilds: It's often the case that if a homepage get's changed,
> 	older versions of the ebuild still use the old homepage. While
> 	it looks like portage/eix always show's the homepage of the
> 	newest ebuild i would like to know if older versions should be
> 	updated as well. Especially if only the homepage gets changed
> 	which usually doesn't require a reversion bump.
>
> Patches:
> * Wildcard patching: Usually i use my "patchtest" script for finding
> 	obsolete patches and while it still finds lots of false
> 	positives i also saw a rather odd patching style: Patching via
> 	wildcards. For example:
> 	epatch "${FILESDIR}"/${P}*.patch
> 	I looks a bit unsafe to use wildcards for patching, but I
> 	couldn't find anything which forbids it. Would be nice to know
> 	if that is ok.
> * scripts in FILESDIR: In some packages i found scripts which doesn't
> 	get used by the ebuild, but is probably used for generating
> 	patches/tarballs. Should i file a bugs about them as i though the
> 	FILESDIR should be only used for patches. Wouldn't be
> 	/etc/portage/scripts the perfect place for such scripts?
>
> Metadaa:
> * metadata.xml: In order to find the correct maintainer for PR's I've
> 	opened on github i also wrote a simply python scripts which
> 	extract's the metadata.xml files.
> 	Regarding GLEP 68 a name isn't required for a maintainer. However,
> 	if i see only a e-mail address in one package, the same e-mail in
> 	another package but also with a name, is it appreciated to fix
> 	the first package?
>
> I hope those questions aren't too stupid and i hope i can get some
> answers as it would make some decisions a bit easier..
> Also please don't judge my English, it's not the best :)
>
> Furthermore i also suggest creating a wiki page for people who look for
> simple tasks were they can help improve gentoo.
> After all, removing obsolete patches or update HOMEPAGE variables isn't
> really difficult, but it's a nice start to get involved. - and those are
> just two tasks, which btw are already quite heavy. (it's about 2 months now
> since i look for obsolete patches, and I'm now at dev-python...).
> I know i could start that by myself, but I'm really bad at wikis :D
>
>
> [1] http://libarchive.org/
>
I think a lot of your suggestions are sane and could improve the quality
of the tree quite a bit. I'm not part of the QA team so I don't know
their opinions on those particular things (in fact they've not really
updated the wiki much on their policies so it's hard to check things at
a glance...). If I could suggest something, it'd be encouraging
conversation with maintainers, as QA policy and making changes won't
produce any lasting improvement unless maintainers understand what
they're screwing up and/or have written guidelines they can check
periodically.

Integration with repoman would be the single most effective way to make
that happen, but I have to wonder if repoman should be taking on that
much responsibility. It's not unreasonable to expect maintainers to
actually visit the package's URL to make sure upstream is doing well.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6