Date: Fri, 20 Jun 2008 13:55:08 +0300 From: Ion-Mihai Tetcu <itetcu@FreeBSD.org> To: "Jeremy Messenger" <mezz7@cox.net> Cc: cvs-ports@freebsd.org, cvs-all@freebsd.org, ports-committers@freebsd.org Subject: Re: cvs commit: ports/audio/wavplay Makefile ports/audio/ximp3 Makefile ports/cad/qucs Makefile ports/devel/gnucflow Makefile ports/devel/libclaw Makefile ports/devel/luabind Makefile ports/devel/p5-WeakRef Makefile ports/devel/py-ode Makefile ... Message-ID: <20080620135508.17f5b09b@it.buh.tecnik93.com> In-Reply-To: <op.uc0yr8s19aq2h7@mezz.mezzweb.com> References: <200806191728.m5JHSO6w037576@repoman.freebsd.org> <20080619203258.421406a4@it.buh.tecnik93.com> <op.uc0yr8s19aq2h7@mezz.mezzweb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/jhQnwqkqOumKp5kFdQqLx7X Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 19 Jun 2008 21:05:58 -0500 "Jeremy Messenger" <mezz7@cox.net> wrote: > On Thu, 19 Jun 2008 12:32:58 -0500, Ion-Mihai Tetcu <itetcu@freebsd.org> = =20 > wrote: >=20 > > On Thu, 19 Jun 2008 17:28:24 +0000 (UTC) > > Dmitry Marakasov <amdmi3@FreeBSD.org> wrote: > > > >> Log: > >> Update my email address in 132 ports. > >> > >> Approved by: miwi (mentor) > > > > So QA Tindy just queued them all. Joy! > > Let see what the output is gonna be ;-) >=20 > Interesting... Let's say, if someone touch a lot of ports like gettext fo= r =20 > example. Are your tinderbox going to do that too? In the current v.0.something yes, the mails would be generated. I review each of them before sending the out and in this case I'd stop them (Edwin would have had his inbox filled up otherwise because of the gettext bump he did). The mail goes to maintainer if the port is built either as a part of a regular build or as a dependency of an other build. It goes to the committer for commit triggered emails (I guess the maintainer should be CC'ed). It would be very nice if people would announce me in advance of this kind of commits (also of those to Mk/*). > If yes, I wouldn't want that email for sure because a lot of these > ports aren't maintaining by person that who did the committed. Well .... <evil grin> Generally speaking: if someone commits something broken it's his his job to fix it; we don't commit to our ports only (think PRs) and we do act as a kind of safety-belt for the contributors. For large sweeps the above rule is interpretable. The thing is I don't see any way to reliable automate this part. I have to trigger a build if anything changes in a port except in pkg-descr. A one line diff in any file might mean the port isn't broken anymore (and we don't bump PORTREVISON for this if the port didn't build before) or it might mean it just broke (think typos or something). I can ever ignore a single cvs rm of a file (might fix the build because it was an old patch forgotten in the last commit). Etc. Parsing the commit log to get some hints about what/why changed ... hahahaha. Same for any kind of heuristics on the diff. BTW, the RoadMap for now is: v.1: Optimizations for the build process: - re-implement it in a something that supports some decent string operation, error handling and database access - have each of the *_DEPENDS for each port in the database to be able to reorder the queue so that a port isn't built twice when there's no need and to make sure they are built in the right order in a multi-port commit; same for bsd.*.mk commits - above will also allow to schedule a rebuild of dependent ports - and incidentally to produce an very up-to-date INDEX - build process optimizations (like fetch the distfiles while tindy is building other ports) v.2: Distributed testing: - multi-host support: distribute the build on more tindy servers (over WAN) - maybe dist-cache support - multi-arch support v.3: - multi-env vars test (like built it with everything standard except PREFIX and NOPORTDATA, etc.) - non-default OPTIONS built testing v.4: Stats and goodies (these might get in earlier) - all kind of stats - RSS feeds - etc. The thing is implementing 80% of each of the above sub-targets doesn't take much time. The edge cases that for the rest 20% ... It would take a few months of day-job to make it work. So it will take a lot more time. --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B --Sig_/jhQnwqkqOumKp5kFdQqLx7X Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhbjJUACgkQJ7GIuiH/oeWIEgCgjn+G5szdIrja2jxUiotfh3lb aHcAn3CYTyGf1SiI5HG3m54/FxYAOhd7 =+lKb -----END PGP SIGNATURE----- --Sig_/jhQnwqkqOumKp5kFdQqLx7X--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080620135508.17f5b09b>