From owner-freebsd-ports@FreeBSD.ORG Mon Nov 17 00:38:35 2003 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEB0516A4CE for ; Mon, 17 Nov 2003 00:38:35 -0800 (PST) Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by mx1.FreeBSD.org (Postfix) with SMTP id 56A7443FD7 for ; Mon, 17 Nov 2003 00:38:33 -0800 (PST) (envelope-from atamaniuk-ports@frobs.net) Received: (qmail 11728 invoked by uid 1003); 17 Nov 2003 08:38:54 -0000 Date: Mon, 17 Nov 2003 09:38:32 +0100 From: Patrick Atamaniuk To: Kris Kennaway Message-ID: <20031117083854.GA1424@mail.webmonster.de> References: <20031019233208.80051.qmail@mail.frobs.net> <20031116191222.GA30181@mail.webmonster.de> <20031116214023.GA16310@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031116214023.GA16310@xor.obsecurity.org> User-Agent: Mutt/1.4.1i X-Arbitrary-Number-Of-The-Day: 42 cc: Sergey Matveychuk cc: eikemeier@fillmore-labs.com cc: freebsd-ports@freebsd.org Subject: Re: ports/58260: New Port: print/lilypond-devel X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2003 08:38:35 -0000 Kris Kennaway(kris@obsecurity.org)@2003.11.16 13:40:23 +0000: > On Sun, Nov 16, 2003 at 08:12:00PM +0100, Patrick Atamaniuk wrote: > So you don't want anyone to commit it to FreeBSD? On the contrary, i generally still want it to be committed. As i have more urgent issues with print/lilypond (stable) itself, i decided to leave the development version somewhere public available without the need to constantly bug committers for now. I have a bad feeling writing a mail like `can anybody please look into that again?`, since i feel `for what did i file a pr if i have to ask once a month for review`. Personal thing. Applies for development/unstable ports only. Since the development version is subject to more often changes, i fear that the pr will be a huge list of followup diffs, soon. So i thought portrookies could be good for me as long as i cannot update the port myself. (Even if i could, portrookies would be still good) But if print/lilypond-devel where imported, i (and the upstream authors) would gladly appreciate that in any case:) > I think, he meant they are changed and freshest versions can be found on > portrookies. Right. The PR is not complete, fixed some issues with configure for 4.9 REL. It bulds fine on current, though. Since for one no FreeBSD users use portrookies now (hope to change that with good documentation becoming available) and on the other hand committers may decide not to like portrookies, i'll continue filing diffs on the PR whatever committers decide. For Kris' very valid security reasons, i consider portrookies cvs non-authoritative, anyways. KK> >It's great to see enthusiasm for the new "portrookies" project, but at Thanks. :) > >the moment most committers are not using it I hope that in the near future many committers start use this as a testbed, too. TB> >I wonder what the view of "portrookies" is amongst the committers? This i wonder, too, and so i simply started to use it for a) `unstable` ports for cutting-edge users, (where lilypond-devel is quite stable and tested on the upstream though) b) for stable ports which are completely hosed on FreeBSD cvs and where there is no feedback on questions. (Maybe i am impatient, but i'd like to throttle down user's questions about not being able to build and when they manage, how to un-break their info(1) dir files and how to pkg_delete with an out of date plist) Currently i am forced (for simplicity) to send the users a tar-file with a working version of the ports skeleton. I hoped that a public version with web-cvs makes it easier to quick-check for committers what i am doing. 80kb diffs in bz2.uu format are not really usable for the short 'i'll take it' statement. :) TB> >Is it a good thing? Will it help or hinder After the commit-bit discussion (which i deliberately did not participate) i decided for myself, that commit-bits must be earned through work and simply started to play on portrookies. I welcome this new forum for there probably will be more motivated newbies and experienced committers with the time to care about each others (trivial) problems. It is no problem there to learn the ropes, and bento will not break on commit mistakes. Will it help or hinder? Mixed. On pkgsrc-wip i have the apprehension that if you don't bug NetBSD committers enough, the wip-ports stay where they are and never make it into the tree. At least when there are only very few end-users reporting success. [No offence, NetBSD, lilypond pkgsrc is not completely finished/optimized there.] imho Gnats will be required and very useful for new ports for quite a while. Time will tell. It definitely is a nice testbed for maintainers without commit-bit. At least for me i can satisfy my urge[:)] to produce usable contributions. It helps to improve the quality of my PR's. This, i think, is A Good Thing(tm). The major advantage against gnats and ports@ list is, that i can make quick fixes without making confusing PR's on PR's. Furthermore, i face the problem, that my port changes on cvs (for valid and good reasons) so my diffs fail to apply and i am not sure how to follow up on that using gnats. patch on the patch? I (mis)decided to make a complete new patchfile which fills up gnats and many mailboxes with large uuencoded files. (Herewith i apologize in shame) KK> >Dunno..I do have some security concerns about importing files from an > >open CVS repository directly into FreeBSD. Fully agreed. If portsrookies should live, there must be a policy/mechanism to ensure ports integrity. Worstcase - sf 0wNeD - disqualifies a merge from there. In all other cases, the port has to be verified somehow. For one by the maintainer before announcing stability and secondly by the committer as usual before mfr-ing (merge from rookies :) OE> >One idea that popped up was downloadable shar files/diffs and to post > >just the url to gnats, but hey, the project is one and a half day old... i'd like checksummed/signed files/diffs ... :) For my part i have the `original` port in my own cvs with one branch following the official ncvs and the head with my changes. Head is posted on public available service, using sf.net only for thoroughly pre-tested versions. Despite all testing i have fixups as new issues arise, by users or by using the port by myself. I gladly use my local sources to diff against official ports for merging (say filing PR's), thus making portrookies a `documentation an testing only` tree for now. Bottomline: for the start i may humbly suggest, that maintainers may play with portrookies, have there discussion and questions and test each others stuff. Then, when they feel that the port reaches _good_ usability (meaning does not break anything like `make index`, the upstream source is ok, the sources are not trojaned and somewhat audited for security stuff, the port actually builds, installs, does something more or less useful and deinstalls cleanly), they then file a good old PR with a (again) tested patch / shar. To motivate these maintainers, probably portsrookies-tested ports could be seen with a (little) more appreciation than 'simple' new ports. ? cheers, patrick -- regards, Patrick Atamaniuk