Created attachment 155816 [details] svn diff for ports-mgmt/portmaster I see this port has gon unmaintained. I am an avid user, and would like to adopt this port. The attached patch (svn diff) lists me as MAINTAINER. That's it. Thanks! --Chris
Chris, I know is this going to come off rude, but I don't know how to sugar coat what comes next. The maintenance of portmaster requires committer-level expertise -- real in-depth knowledge of the ports system which is a fast moving target. In my opinion you haven't demonstrated the level of expertise that I suspect is required. This is not a typical "hey, throw my name of it" port. It should be maintained at an official level or honestly removed. I almost think the maintainership should be restricted to committers. Not to be exclusive but because it's rare non-committers have the knowledge (and when they acquire it, they are recruited to be committers)
(In reply to John Marino from comment #1) > Chris, > I know is this going to come off rude, but I don't know how to sugar coat > what comes next. > > The maintenance of portmaster requires committer-level expertise -- real > in-depth knowledge of the ports system which is a fast moving target. In my > opinion you haven't demonstrated the level of expertise that I suspect is > required. > > This is not a typical "hey, throw my name of it" port. It should be > maintained at an official level or honestly removed. > > I almost think the maintainership should be restricted to committers. Not > to be exclusive but because it's rare non-committers have the knowledge (and > when they acquire it, they are recruited to be committers) As always, I *greatly* appreciate your candor, whether I like the sound of it, or not. I also appreciate your consideration. I disagree with nearly none of what you state here; save my ability to manage this port. I quite agree that this is not a simple task, and I have long used, and wanted the opportunity to maintain this port. It is my opinion that users of this port might be better served, if it were converted to Perl; providing the ability to break it up into modules, so as to make the *enormous* collection of routines it is now composed of, *far* more manageable, and coherent. No? Thanks you again, John -- really. --Chris
This is my point -- it's not about managing, it's about creating. It has to stay in sync with the tree. The last time we had a lot of interaction, I was pushing hard for you to provide poudriere test logs and IIRC, you never go poudriere running. Well, portmaster is essentially another implementation of a big chunk of poudriere. So my concern is: if you were having trouble _using_ poudriere, how can we be confident that you can reimplement it? Most of those PRs require signficant fixes. This is not a "management" task, it's active development. This is why it was dropped -- too much requirement to maintain, no discernible benefit (I am not included "i like it better than raw pkg or poudriere" as a real benefit obviously)
(In reply to John Marino from comment #3) > This is my point -- it's not about managing, it's about creating. It has to > stay in sync with the tree. > > The last time we had a lot of interaction, I was pushing hard for you to > provide poudriere test logs and IIRC, you never go poudriere running. Well, > portmaster is essentially another implementation of a big chunk of > poudriere. > > So my concern is: if you were having trouble _using_ poudriere, how can we > be confident that you can reimplement it? > > > Most of those PRs require signficant fixes. This is not a "management" > task, it's active development. This is why it was dropped -- too much > requirement to maintain, no discernible benefit (I am not included "i like > it better than raw pkg or poudriere" as a real benefit obviously) Thanks for the reply, John. I have no issue with running poudriere. I have an issue running poudriere to best benefit my needs. I can't bend it to my will. So I have simply set up my own Jails, my own way. I appreciate your concern. But I've been thinking about this for *quite* some time, and I'm up for the challenge, or more accurately; the task. Even if I weren't, what's the worst that could happen; that it'd languish a little longer? Honestly; I'm up on it. Thanks! --Chris
There's lots of negatives to you doing a poor job. 1) By you picking it up 2 days after it's drop, you prevent others from being a maintainer -- and potentially people that are more qualified. So by applying a first-come-first-serve approach rather than an "maintainer will be selected from pool of applicants" approach has an obvious downside 2) portmaster is widely hated by the pool of committers. Nobody is going to be happy to see it languish rather than be eliminated. So if you aren't up to the task, there's a clear downside if the inevitable is to remove it. 3) Portmaster is hindering people from using proper, officially supported tools. This is another reason committers would like to see it go if it's not correctly supported. 4) Users are going to stick with portmaster but if it's not properly supported you are not doing them any favors. they'd be better served to move now. See? Have you really thought about these aspects?
by the way, you can submit patches to any port without being a maintainer. You can contribute to fixing it without having the responsibility of being the maintainer.
(In reply to John Marino from comment #5) > There's lots of negatives to you doing a poor job. > > 1) By you picking it up 2 days after it's drop, you prevent others from > being a maintainer -- and potentially people that are more qualified. So by > applying a first-come-first-serve approach rather than an "maintainer will > be selected from pool of applicants" approach has an obvious downside I still don't see myself as unqualified. > > 2) portmaster is widely hated by the pool of committers. Nobody is going to > be happy to see it languish rather than be eliminated. So if you aren't up > to the task, there's a clear downside if the inevitable is to remove it. I only offered that, because you seem so adamant about my inability to maintain it. *Not* because I think you may be correct in that regard. > > 3) Portmaster is hindering people from using proper, officially supported > tools. This is another reason committers would like to see it go if it's > not correctly supported. > > 4) Users are going to stick with portmaster but if it's not properly > supported you are not doing them any favors. they'd be better served to > move now. > > See? Yes. > > Have you really thought about these aspects? Yes. Except that I haven't considered the "committers hate portmaster" aspect, except that you brought it up earlier. Which also would include that affect on the others you mention. So am I to understand that *potentially* making portmaster better would also leave it "hated"? Is there no salvation for portmaster? This seems part of the larger message here. --Chris
(In reply to Chris Hutchinson from comment #7) > I still don't see myself as unqualified. Well, as I said up front, it's based on reviewing your previous works. I'm sure there's been some improvement, but I think this is expert-level stuff. I am not willing to denote that title to you yet. > So am I to understand that *potentially* making portmaster better > would also leave it "hated"? There's no "potentially" here. Either it gets better or it doesn't. Until it does, it's definitely hated. If it did get all the stuff fixed it would only be merely annoying -- but since no official is maintaining it, it can be disowned. So basically -- if it's fully functional, nobody can complain about it. > Is there no salvation for portmaster? Personally I don't get why it deserves salvation. I think it's time came and went, but the answer is within my previous. I think the best approach is prove that you are qualified -- and you do that by proving patches to fix all the reported problems. If you fixed them all and nobody else is doing it, I'd say you would have proven you can and should be the maintainer. So just use bugzilla, search for "portmaster" and start fixing them. Don't worry about the title.
s/proving patches/providing patches/
(In reply to John Marino from comment #9) > s/proving patches/providing patches/ (In reply to John Marino from comment #8) > (In reply to Chris Hutchinson from comment #7) > > I still don't see myself as unqualified. > > Well, as I said up front, it's based on reviewing your previous works. I'm > sure there's been some improvement, but I think this is expert-level stuff. > I am not willing to denote that title to you yet. > > > So am I to understand that *potentially* making portmaster better > > would also leave it "hated"? > > There's no "potentially" here. Either it gets better or it doesn't. Until > it does, it's definitely hated. If it did get all the stuff fixed it would > only be merely annoying -- but since no official is maintaining it, it can > be disowned. So basically -- if it's fully functional, nobody can complain > about it. > > > Is there no salvation for portmaster? > > Personally I don't get why it deserves salvation. I think it's time came > and went, but the answer is within my previous. > > > I think the best approach is prove that you are qualified -- and you do that > by proving patches to fix all the reported problems. If you fixed them all > and nobody else is doing it, I'd say you would have proven you can and > should be the maintainer. > > So just use bugzilla, search for "portmaster" and start fixing them. Don't > worry about the title. I fully intend to do that. I've spoken with Brian, on IRC. But he's a bit busy today, so we'll be speaking again tomorrow. Once I get the tree, I can *indeed* start providing patches, and will do so. In fact, I can post them right here. :) Speaking of being at "committer level", may I humbly request your personally reviewing those patches? May I also request your being my "mentor"? I can think of no one I feel more qualified to do so. I mean that sincerely. This is *NOT* "lip service"! Thank you again, for your candor, John. I don't take it personally, and really appreciate it. --Chris
(In reply to Chris Hutchinson from comment #10) > I can *indeed* start providing patches, and will do so. In fact, I can > post them right here. :) I think it would be more appropriate to post patches on the original PRs. It keeps the topics compartmentalized and it keeps the original reporter in the loop. > Speaking of being at "committer level", may I humbly request your personally > reviewing those patches? May I also request your being my "mentor"? I can > think of no one I feel more qualified to do so. I mean that sincerely. This > is *NOT* "lip service"! So we are talking about patches to the 4000-line script, not patches to the port that installs it, right? (which I assume is dead simple). I can look at patches, but they will likely be out of context and I'd have to review the entire script to put it into context, which implies I'd have to get intimately familiar with the internals in order to give real feedback. In reality, if there's a reproducible problem and your patch clearly fixes it without other regressions, chances are the patch is correct. I'd really just see you as the primary developer at that point. I think it would be more realistic that you would contact someone, including me, if you are "stuck" on how to solve a stated problem. Then you'd get pointed in the right direction, solve it, and whatever patch you come up with would be assumed to be correct (since it comes from the developer)
(In reply to John Marino from comment #11) > (In reply to Chris Hutchinson from comment #10) > > I can *indeed* start providing patches, and will do so. In fact, I can > > post them right here. :) > > I think it would be more appropriate to post patches on the original PRs. > It keeps the topics compartmentalized and it keeps the original reporter in > the loop. > > > Speaking of being at "committer level", may I humbly request your personally > > reviewing those patches? May I also request your being my "mentor"? I can > > think of no one I feel more qualified to do so. I mean that sincerely. This > > is *NOT* "lip service"! > > So we are talking about patches to the 4000-line script, not patches to the > port that installs it, right? (which I assume is dead simple). > > I can look at patches, but they will likely be out of context and I'd have > to review the entire script to put it into context, which implies I'd have > to get intimately familiar with the internals in order to give real > feedback. In reality, if there's a reproducible problem and your patch > clearly fixes it without other regressions, chances are the patch is > correct. I'd really just see you as the primary developer at that point. > > I think it would be more realistic that you would contact someone, including > me, if you are "stuck" on how to solve a stated problem. Then you'd get > pointed in the right direction, solve it, and whatever patch you come up > with would be assumed to be correct (since it comes from the developer) Sure. It all makes perfect sense. Sorry. Thanks! --Chris
Given the consensus was reached not to hand over the maintainership of that port, I am closing this PR.
Chris, If you are still interested I am still willing to review your patches and get them in. After some time with this I will gladly hand over full maintainership to you.