Date: Thu, 28 Sep 2000 22:22:35 -0300 From: "Mario Sergio Fujikawa Ferreira" <lioux@uol.com.br> To: mi@aldan.algebra.com Cc: Mario Sergio Fujikawa Ferreira <lioux@uol.com.br>, freebsd-ports@FreeBSD.ORG, andrew@cream.org Subject: GNATS new classes proposal (WAS: Re: erlang port -- a poster child (Re: I'll be rolling a 4.1.1 r) Message-ID: <20000928222235.A11559@Fedaykin.here> In-Reply-To: <200009282257.e8SMvZv73577@misha.privatelabs.com>; from mi@aldan.algebra.com on Thu, Sep 28, 2000 at 06:57:12PM -0400 References: <20000928190414.A38465@Fedaykin.here> <200009282257.e8SMvZv73577@misha.privatelabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Well, since this pretty much became a proposal, I'll write it as such. In the spirit of enabling easier parsing of the GNATS database, many users have been proposing the creation of additional class of PRs. Sort of a proposal draft follows: On Thu, Sep 28, 2000 at 06:57:12PM -0400, mi@aldan.algebra.com wrote: > On 28 Sep, Mario Sergio Fujikawa Ferreira wrote: > > = I am not sure this is the right way to do these things. > = However, even if these are correct some questions already arise: > = > = 1) We are adding 2 new classes that are category specific > = (this is prone to PR filling mistakes and confusion) > > I think, this can be generalized to be update and maintainer-update > or some such for other parts of the system -- not just ports. I'm > sure there are non-committers involved with software in contrib, for > example... That way handling of other PRs can be streamlined too and > most of your reservations will become moot :) I know. I was just throwing bait. However, I do not think that updating is a good class. I would propose as generic: 1) new-proposal: or, something like that for totally novel things, pretty much applies to every category. However, it might be misfiled by ppl wanting wish. Nevertheless, good documentation should deal with this as it should deal with pretty much everything else; :) 2) maintainer-update: even non-ports parts of the system are maintainer related in some way, just check cvsweb to get an idea, e.g., do not even dare touch sysinstall without asking jkh if you are not sure you should be touching it; 3) maintainer-approved: implicitly means, I will do something to something (update it, erase it, move it, whatever it) with the blessing of the maintainer. This particular class is prone to 2 different interpretations: 3.1) only tweakable by 'edit command' like wish: it would be an internal committer way of saying - if any other committer want to do something about it, it is safe because I got confirmation from the maintainer; 3.2) send-pr normal class: hey, the maintainer said it was ok - committers -> I can tkgnat, separate this babes, CC the maintainers just to make sure it is for real, then commit them all. It is not perfect but works as a way of filtering some of the noise; of course, IF it is not abused as it is surely a candidate of. Comments, additions, rewrites? A candidate for a PR of class "wish" follows at the end of this email. My 2 cents, Mario Ferreira > = 2) GNATS or the filling PR tools should have some sanity > = checking: ports-update and port-maintainer should give some sort > = of gnats-adm warning for mistaken filling; and, the filling > = forms/tools shouldn't allow it. > = 3) We need some sort of tool (perhaps other than GNATS, I > = can't judge it) that implicit allows us to use specific class/categories > = combinations. From my novel_this_morning_understanding of GNATS, > = this is not something it does kindly. Classes are all generic. ==== Wish List (good or just redtape? You judge it) Wish List (meaning, I could do it, but it just gives me a big headache just to imagine it): Something I am missing here is a way to unambiguously identify the sender or confirm claims in PRs (mainly maintainer-approved and maintainer-update). Just bear with me in this one, it has probably been proposed tons of times but ...: (scenario) I fill a PR, I set class maintainer-approved. GNATS gets it. Committers sees it but has to send email to maintainer to verify the claim. However, if the maintainer could just log in the GNATS web interface, check the PR, fill a specific password-(ssl)-field with username_password_pair-digital-stamp of approval, then a huge burden would be removed from the PR ppl. Just that no one starts shouting at me that nobody will remember the passwords, this is OPTIONAL, those who use it will get better response times, those who don't will get normal response times, you might even never get a username_password pair, just say you will never use it and it won't be created for safeness sake. This is feasible, besides, I really think that maintainers should be saved in same sort of database queriable interface. See, I am lioux, whenever I fill maintainer TAGS, it is filled with lioux. lioux is preprocessed and filled with lioux real meaning (lioux at linf dot unb dot br) whenever someones checks a port with say "make maintainer". This info could be saved at Mk/contact_info.mk (comment line ala bsd.port.mk, touch it and die). Therefore, we would have uniform MAINTAINER lines for same maintainers. Therefore, when I fill username=lioux, you (and the database) know who it means because these usernames have to the same. Then, it is a crosscheck this person saying that he gives his blessing is maintainer of blabla which the PR modifies? Another issue, GOD they stole my password and the maintainer confirmation was bogus: shame on you. We have cvs undo. Some hassle but not terrible, just stablish some sort of lost password policy (issue another, revoke for 1 week before reissuing, whatever). This way, we could save ourselves (after implementation) LOTS of time by knowing for "sure" in advance that we can just go and commit. Please remember that PRs and ports tend to grow exponentialy; however, both the number of hours in a day and the number of trustable ppl to be committers does not not. ==== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000928222235.A11559>