From nobody Mon Jan 30 21:39:03 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5M5L21gnz3cfBk for ; Mon, 30 Jan 2023 21:39:18 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5M5K2Mmtz4421 for ; Mon, 30 Jan 2023 21:39:17 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fbLXZh9d; spf=pass (mx1.freebsd.org: domain of yetoohappy@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=yetoohappy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x634.google.com with SMTP id qw12so20064232ejc.2 for ; Mon, 30 Jan 2023 13:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=W7T+rW9AGsJrd3v/xR99z0Q/MnJe692T10YyPBDJlwk=; b=fbLXZh9dp/2Ux9YBbQyPP/o4cWILkS1w1P5d89ExGBP4yhYhQR/saBw8jlX0cwwFTL DKPT5IA+plnOTMunCiXSu50dJshwgrtj7HQxOGkOiUdt/W2jKK8zFGcjxbqWqzI31ATq uvkSpjrdpc6JtF7klYeZwlycdUJtMEKK2ai2PPjaaT9GYgARBaFIMsxhGANE9rvSx+2H x56wBhf6kO8Wgo1ICMLE/VBACj1USGGam/7pMVN3KxTEuhTuZ8ZGAIlhNmCbq5RPnEHb m6UL6Rg2/UFlvO+Uu9ST0kGldyAVGNp0DegvpU8c5GIGLQGnFnGGNNZDAcxRcXmbTahn uSiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W7T+rW9AGsJrd3v/xR99z0Q/MnJe692T10YyPBDJlwk=; b=QmobUuxv/9PNCOu4B35WY696dhO7m53BySxHEukv3uCY6Wvs5myp5S8Of9IistC9VM TxfvXOVbcH4Kgm7pjjTkyKbssT3B8HAODdRzjpBwGgiPLEQYJRjMoZhrgJIrLnXnLOqt iZIq29MGMvhWNABI+4/b7ojuyNbBUv3aWGVWuJaYgYCq7TuRrq66k7sKVBVXCzT2w68P qImpWgQEzm6rH6AaTijwtq5rS9ZG87yp+TJA+XKOsLBfuwBDEG0ecZD1JJ2ideEmPt3M Wrl0k/dZnwt2S38U9g7WFr19HgBuvoSG4n+aTrx3jTit8fz75QizhWCmKG12YuDLP+Ww /MTw== X-Gm-Message-State: AO0yUKW3SWI9ys6ESOR8ztr5nRfWhg3R1dKz/ebIGuEDPViWG3UcSf// 6Oq7YTT977jwttZjPNl7NNq4W5qBVBdtw7XY8ufQ941B X-Google-Smtp-Source: AK7set+wTP8yZwLGDYp7R8IZIs/6IgZ5yF14BA+NQw8rGfw8w4FVKk8PG4Nxx+uBfjS4hojbsQyH0L4Hq8CS3LqGzCY= X-Received: by 2002:a17:906:9e05:b0:883:ba3b:ebb8 with SMTP id fp5-20020a1709069e0500b00883ba3bebb8mr2007930ejc.308.1675114756044; Mon, 30 Jan 2023 13:39:16 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <202301300254.30U2sm0k061914@dell.no.berklix.net> <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> In-Reply-To: <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> From: Yetoo Date: Mon, 30 Jan 2023 13:39:03 -0800 Message-ID: Subject: Re: Tooling Integration and Developer Experience Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fdfe3705f3820b0b" X-Spamd-Result: default: False [-1.00 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.92)[-0.917]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-0.08)[-0.082]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P5M5K2Mmtz4421 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --000000000000fdfe3705f3820b0b Content-Type: text/plain; charset="UTF-8" My two cents... I think some of the integration issues can be resolved with some rule changes and showing those relevant rules that people will see every time they make a pull request, report, etc... as I think what will happen with each item is too uncertain even if there was automation. I think rules should enshrine a single place that will always get reports and places to review or pull request and/or discussion requires reports to be made there first. I think that single place should be bugzilla but I'm a bit biased toward bugzilla as I haven't created an account for freebsd phabricator. This would mean every review on phabricator or pull request on github would need an associated report on bugzilla as well as link to that report and link back on bugzilla in the url field (if only one allowed or easy per report, maybe make dedicated field for other trackers) or first comment or else bugzilla, github, and phabricator posts are closed. The problem of just having someone commenting a link where the pull requestin the middle of a long discussion is that it's hard to find. Perhaps this part can be automated first as it's draconian if rules/warnings can't be seen before and while editing. People can go to the mailing list to talk about issues or submit changes, but no change will be accepted until someone makes a bugzilla report for it and link back to mailing list and from mailing list to it. Then there can be more automation with phabricator and github notifying bugzilla that it exists/important events happened to the bug. I think if the rules viewed bugzilla centralized to all legs then the need for redundant notification and requests, such as git saying if there is an issue/review in phabricator and an issue report in bugzilla or a pull request automatically created in git when submitted to phabricator, would be avoided. If everything is moved into phabricator, including bugzilla, I think it's worth considering whether existing bugzilla reports, patches, tags, etc can be migrated without losing data. Bugzilla could be in a no new reports mode, but there would still be the problem of reports spread out across different systems. If github is going to be considered for issue tracking I just want to say, after having extensively using it for issue tracking, it tends to be difficult to find an issue if the exact title isn't entered and many duplicate reports are made as a result. Code search sucks and doesnt show you the multiple places in a file where a match was made so a user may be left wondering if code exists or not, but this doesn't seem to be germane given this is about issue tracking. > --000000000000fdfe3705f3820b0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My two cents...

I think some of the integration issues can be resolved= with some rule changes and showing those relevant rules that people will s= ee every time they make a pull request, report, etc... as I think what will= happen with each item is too uncertain even if there was automation. I thi= nk rules should enshrine a single place that will always get reports and pl= aces to review or pull request and/or discussion requires reports to be mad= e there first. I think that single place should be bugzilla but I'm a b= it biased toward bugzilla as I haven't created an account for freebsd p= habricator.=C2=A0This would mean every review on phabricator or pull reques= t on github would need an associated report on bugzilla as well as link to = that report and link back on bugzilla in the url field (if only one allowed= or easy per report, maybe make dedicated field for other trackers) or firs= t comment or else bugzilla, github, and phabricator posts are closed. The p= roblem of just having someone commenting a link where the pull requestin th= e middle of a long discussion is that it's hard to find.=C2=A0 Perhaps = this part can be automated first as it's draconian if rules/warnings ca= n't be seen before and while editing. People can go to the mailing list= to talk about issues or submit changes, but no change will be accepted unt= il someone makes a bugzilla report for it and link back to mailing list and= from mailing list to it. Then there can be more automation with phabricato= r and github notifying bugzilla that it exists/important events happened to= the bug. I think if the rules viewed bugzilla centralized to all legs then= the need for redundant notification and requests, such as git saying if th= ere is an issue/review in phabricator and an issue report in bugzilla or a = pull request automatically created in git when submitted to phabricator, wo= uld be avoided.

If every= thing is moved into phabricator, including bugzilla, I think it's worth= considering whether existing bugzilla reports, patches, tags, etc can be m= igrated without losing data. Bugzilla could be in a no new reports mode, bu= t there would still be the problem of reports spread out across different s= ystems.

If github is goi= ng to be considered for issue tracking I just want to say, after having ext= ensively using it for issue tracking, it tends to be difficult to find an i= ssue if the exact title isn't entered and many duplicate reports are ma= de as a result. Code search sucks and doesnt show you the multiple places i= n a file where a match was made so a user may be left wondering if code exi= sts or not, but this doesn't seem to be germane given this is about iss= ue tracking.

--000000000000fdfe3705f3820b0b--