1 |
On 13/09/16 19:57, Michael Mair-Keimberger wrote: |
2 |
> Hello Gentoo-Team, |
3 |
> |
4 |
> For some time now I'm trying to help improve the gentoo tree. I've |
5 |
> started with fixing some HOMEPAGE variables in ebuilds and now removing |
6 |
> obsolete patches from packages. |
7 |
> Usually (especially with obsolete patches) it's quite simple to fix |
8 |
> things, however every now and then i find some "special" cases were i |
9 |
> don't know whats correct way to fix it. |
10 |
> Even though i could ask on irc, I'm usually to lazy and now there are a |
11 |
> few question were i would like to have an answer for. :) |
12 |
> |
13 |
> Homepages: |
14 |
> * Dead homepages: I know there is this general rule of pointing to the |
15 |
> No_homepage wiki page if there is no upstream homepage. However, |
16 |
> when I fixed some homepage's i usually used an archived [1] homepage |
17 |
> of the original homepage. While for some dev's this isn't a |
18 |
> problem, others do not like the idea. |
19 |
> Personally i would prefer having some homepage rather than no |
20 |
> homepage at all. It would be nice to have a clear statement |
21 |
> about that. |
22 |
> * Waiting time: I couldn't find any references of how long to wait until |
23 |
> a homepage can be changed because it's offline. Usually i would |
24 |
> check for bugs, because if the bug is already quite old and the |
25 |
> homepage is still offline it's safe to say we can change them. |
26 |
> However, i also have an script which checks for offline |
27 |
> homepages. But since a homepage can be temporally offline or just |
28 |
> not available from my side of the internet i would like to know |
29 |
> how long i should wait until i can fix it. I think 1 month |
30 |
> would be a good start? |
31 |
> * Redirection: There are quite a few pages which aren't exactly offline, |
32 |
> but only forward the request to the current homepage. (like most |
33 |
> of the gentoo project pages). I haven't touch them yet, but i |
34 |
> would like to know if fixing them would be appreciated? |
35 |
> * old ebuilds: It's often the case that if a homepage get's changed, |
36 |
> older versions of the ebuild still use the old homepage. While |
37 |
> it looks like portage/eix always show's the homepage of the |
38 |
> newest ebuild i would like to know if older versions should be |
39 |
> updated as well. Especially if only the homepage gets changed |
40 |
> which usually doesn't require a reversion bump. |
41 |
> |
42 |
> Patches: |
43 |
> * Wildcard patching: Usually i use my "patchtest" script for finding |
44 |
> obsolete patches and while it still finds lots of false |
45 |
> positives i also saw a rather odd patching style: Patching via |
46 |
> wildcards. For example: |
47 |
> epatch "${FILESDIR}"/${P}*.patch |
48 |
> I looks a bit unsafe to use wildcards for patching, but I |
49 |
> couldn't find anything which forbids it. Would be nice to know |
50 |
> if that is ok. |
51 |
> * scripts in FILESDIR: In some packages i found scripts which doesn't |
52 |
> get used by the ebuild, but is probably used for generating |
53 |
> patches/tarballs. Should i file a bugs about them as i though the |
54 |
> FILESDIR should be only used for patches. Wouldn't be |
55 |
> /etc/portage/scripts the perfect place for such scripts? |
56 |
> |
57 |
> Metadaa: |
58 |
> * metadata.xml: In order to find the correct maintainer for PR's I've |
59 |
> opened on github i also wrote a simply python scripts which |
60 |
> extract's the metadata.xml files. |
61 |
> Regarding GLEP 68 a name isn't required for a maintainer. However, |
62 |
> if i see only a e-mail address in one package, the same e-mail in |
63 |
> another package but also with a name, is it appreciated to fix |
64 |
> the first package? |
65 |
> |
66 |
> I hope those questions aren't too stupid and i hope i can get some |
67 |
> answers as it would make some decisions a bit easier.. |
68 |
> Also please don't judge my English, it's not the best :) |
69 |
> |
70 |
> Furthermore i also suggest creating a wiki page for people who look for |
71 |
> simple tasks were they can help improve gentoo. |
72 |
> After all, removing obsolete patches or update HOMEPAGE variables isn't |
73 |
> really difficult, but it's a nice start to get involved. - and those are |
74 |
> just two tasks, which btw are already quite heavy. (it's about 2 months now |
75 |
> since i look for obsolete patches, and I'm now at dev-python...). |
76 |
> I know i could start that by myself, but I'm really bad at wikis :D |
77 |
> |
78 |
> |
79 |
> [1] http://libarchive.org/ |
80 |
> |
81 |
I strongly recommend getting in touch with the Gentoo QA team either via |
82 |
their qa@g.o alias, or come to #gentoo-qa on Freenode IRC. This kind of |
83 |
thing could be really helpful for keeping the tree 'in-shape' and the |
84 |
more people who can contribute effective scripts to help identify and |
85 |
rectify 'bad' ebuilds the better. Feel free to idle in the #gentoo-* |
86 |
channels .. everyone else does, and you can always scroll back to see |
87 |
what's going on, and ask for more immediate assistance, leave notes for |
88 |
devs, etc quite easily. |
89 |
|
90 |
Dev's should be committing their new files using a tool called 'repoman' |
91 |
which is maintained by the Gentoo Portage team (dev-portage@g.o) who may |
92 |
also benefit from some bad examples to trap in this utility. It's |
93 |
recently been split from the Portage package into its own |
94 |
dev-portage/repoman which you may also find useful. Portage's git repo |
95 |
is at https://gitweb.gentoo.org/proj/portage.git/ if you wish to peruse! |
96 |
Cheers, |
97 |
Michael. |