Re: [gentoo-dev] Looking for co-maintainers for number of packages
07.07.2022 11:27, Martin Kletzander пишет: On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote: I've been rather busy lately and can't keep up with all of my packages. There are pending bumps, some bugs, but nothing too crazy or hard. So I'm looking for someone to co-maintain (or even take over if you insist) the following packages: Noob question, I would have to be a Gentoo developer/maintainer to help with that, am I right? Don't worry, proxied maintainers can easily (co-)maintain packages too. * app-shells/fish Responsive upstream, not very frequent releases, cmake. Requires some attention on non-x86 as arch bugs are rather frequent. But nothing too crazy. Since I do not have any experience with official maintainership I would hesitate to commit to anything I am not a user of, but I do use fish and keep an eye on releases a bit (which I would do more, of course). [...] PS. Huge bonus if you can test packages not only on x86_64. Ofc I can help with some gotchas in packages and have no plans on abandoning those completely, but realistically I'm not doing enough to keep those properly maintained at the moment. I can test that every now and then and even fix some possible issues, hopefully. Let me know if I can be of help or whether I should rather go through proxy maintainers or another route. It's possible for a particular developer to be the proxy, and it's possible for p-m project to be proxies for the proxied maintainers. Have a nice day, Martin -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Looking for co-maintainers for number of packages
On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote: I've been rather busy lately and can't keep up with all of my packages. There are pending bumps, some bugs, but nothing too crazy or hard. So I'm looking for someone to co-maintain (or even take over if you insist) the following packages: Noob question, I would have to be a Gentoo developer/maintainer to help with that, am I right? * app-shells/fish Responsive upstream, not very frequent releases, cmake. Requires some attention on non-x86 as arch bugs are rather frequent. But nothing too crazy. Since I do not have any experience with official maintainership I would hesitate to commit to anything I am not a user of, but I do use fish and keep an eye on releases a bit (which I would do more, of course). [...] PS. Huge bonus if you can test packages not only on x86_64. Ofc I can help with some gotchas in packages and have no plans on abandoning those completely, but realistically I'm not doing enough to keep those properly maintained at the moment. I can test that every now and then and even fix some possible issues, hopefully. Let me know if I can be of help or whether I should rather go through proxy maintainers or another route. Have a nice day, Martin
Re: [gentoo-dev] proposal
On 07.07.22 09:45, Michal Prívozník wrote: I think that rejecting a contribution (regardless of the flag) should be based on technical merit, rather than individual maintainers personal preferences. I do understand some packages are like your babies, you watch them grow, fine tune everything. But in the end, if somebody finds a bug in the ebuild/eclass/... and is even willing to provide a fix, we should have a discussion about the proposed fix rather than refer to a flag (or lack of thereof) when closing the MR (unmerged). It was never the intention to create a scenario where maintainers reject a contribution based on such a flag. Gentoo, being free and open source software, if fully aligned with the spirit of FOSS, which *everyone* can use, study, share and *improve*. With the replies in mind, I gave this some more thought. I think the best default is "everyone can propose changes to the maintainer, on which the maintainer has to act within a reasonable amount of time". However, there are maybe cases where trivial fixes for low-maintenance packages are for some reason not merged into ::gentoo and the maintainer is unresponsive. If those packages where flagged with , then I would be less reluctant to commit them to ::gentoo. After committing, I would always inform the maintainer. On the other hand, there is the situation where seemingly innocent changes could cause some fallout, because this is the kind of package where you assume you know what is going on from reading the ebuild and playing with it, but you actually don't. Such packages could carry a flag indicating that all changes require review by the maintainer. It appears that gives the wrong impression, so maybe ? - Flow
Re: [gentoo-dev] proposal
On 7/6/22 18:04, Fabian Groffen wrote: > - please do not needlessly change style: if you do not "maintain" the > ebuild, respect the style of the maintainer, so only add the changes > you need, keep it minimal, respect the original even though you don't > like it (and don't use QA as an excuse to change style) QA actually states to honor the maintainer's style as much as possible, https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html "Respect developers' coding preferences. Unnecessarily changing the syntax of an ebuild can cause complications for others. Syntax changes should only be done if there is a real benefit, such as faster compilation, improved information for the end user, or compliance with Gentoo policies. " Of course there are some "strict" rules, but very much is left to the maintainer. https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0101 > - when you make a change, make sure you check for bugs in the following > days, so you can cleanup yourself should there be fallout > ago does a good job CCing the commit author too in his bug reports, if the person is not the maintainer. This only applies to tinderbox bugs though. Obviously you should manually CC the author if you see the bug coming from their commit. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] proposal
On 7/4/22 16:19, Florian Schmaus wrote: > I'd like to propose a new metadata XML element for packages: > > > > Maintainers can signal to other developers (and of course contributors > in general) that they are happy with others to make changes to the > ebuilds without prior consultation of the maintainer. > > Of course, this is not a free ticket to always make changes to packages > that you do not maintain without prior consultation of the maintainer. I > would expect people to use their common sense to decide if a change may > require maintainer attention or not. In general, it is always a good > idea to communicate changes in every case. > > The absence of the flag does not automatically allow the conclusion that > the maintainer is opposed to non-maintainer commits. It just means that > the maintainer's stance is not known. I do not believe that we need a > flag, but if the need arises, we > could always consider adding one. Although, in my experience, people > mostly like to communicate the "non-maintainer commits welcome" policy > with others. I worry that this might send wrong signal. My understanding is that just like any OSS also Gentoo struggles with attracting new contributors and telling anybody "hey, your contribution is not welcome" does not help. I think that rejecting a contribution (regardless of the flag) should be based on technical merit, rather than individual maintainers personal preferences. I do understand some packages are like your babies, you watch them grow, fine tune everything. But in the end, if somebody finds a bug in the ebuild/eclass/... and is even willing to provide a fix, we should have a discussion about the proposed fix rather than refer to a flag (or lack of thereof) when closing the MR (unmerged). Michal
Re: [gentoo-dev] proposal
Hi All,
On 2022/07/06 15:50, Michał Górny wrote:
> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
>> I'd like to propose a new metadata XML element for packages:
>>
>>
>>
>> Maintainers can signal to other developers (and of course contributors
>> in general) that they are happy with others to make changes to the
>> ebuilds without prior consultation of the maintainer.
> I don't think adding such an element is a good idea. In my opinion,
> this will strengthen the assumption that "unless otherwise noted, you
> don't dare touch anything" (even though that's not your goal). "Common
> sense" should really be good enough for almost everything.
I agree, but also note that what I consider to be "common sense" isn't
always "your common sense".
I also agree that having some way to indicate the preference on the
specific package may be a good thing. With various possible levels of
sensitivity.
For example, net-misc/asterisk and net-libs/pjproject is very sensitive
for me. net-misc/dahdi{,-tools} and x11-wm/evilwm less so. In all
cases I'd still prefer to be kept in the loop at a minimum.
As such, it looks like there is multiple options, and there are
suggestions for various tags, this is a sensible way to indicate
preference. Eg, also, what kind of fixes don't require communication,
eg, I've seen drive-by's on the above packages to fix dependencies based
on slots because depended on packages changed their structure, or
because LUA became slotted, or adding := etc ... This makes sense to
allow these, but if you're going to mess with my ./configure on asterisk
or pjproject without consulting with me I'm going to be upset. A simple
code fix to fix some compile error (specific to say llvm), probably
fine, but I'd still appreciate communication as I'd like to submit that
upstream kind of thing as well.
If this does go live, then there should be a single tag where the value
indicates the level of "sensitivity", or multiple tags of which only one
is allowed. Since some of these options may be orthogonal to each
other, a single tag with multiple attributes may be more appropriate, I
don't know, nor do I personally care that much, so far I've been
respected, and the drive-by's that has been made were all either part of
global fixes, or in the one or two cases where it was specific, was put
into the tree as ~ so were all just fine. In one particular case it was
also masked specifically because the change depended on another change
to happen simultaneously/close together (lua slotting) - the experience
of which was most refreshing. Obviously nothing is set in stone w.r.t.
specifics, but if the initial course is at least somewhat in the right
direction it's easier to course-correct.
I thus have no strong opinion one way or the other, but just wanted to
state the above.
Kind Regards,
Jaco
