On Sat, 28 Oct 2006 01:04:05 +0400 "Andrew Pantyukhin" <[EMAIL PROTECTED]> wrote:
> On 10/28/06, Ion-Mihai IOnut Tetcu <[EMAIL PROTECTED]> wrote: > > On Fri, 27 Oct 2006 16:26:54 +0400 > > "Andrew Pantyukhin" <[EMAIL PROTECTED]> wrote: > > > > > On 10/27/06, Christopher Boumenot <[EMAIL PROTECTED]> wrote: > > > > Every time I upgrade a port I am usually left wondering what > > > > changed. > > > > > > Some other projects maintain special package-specific > > > ChangeLog files. Maybe VCS logs is not the best place > > > for documentation, because it's not as easily accessible > > > as a flat file would be. > > > > > > Moreover, I think porters don't document the hacks they > > > have to employ - just because there's nowhere to do that. > > > > You all might want to take a look at what I do in > > mail/dspam[-devel]/[Makefile|files/UPDATING] > > Yes, the idea is very bright. There's no rush however, so > let's look at how other people deal with it, among ports > committers and outside, before we set any standards in > stone. The biggest problem is that it requires [a lot of] work for the commiter/submitter. The problem with the OP's work is that some submitters/commiters think that the CVS commit message should document the _port_ changes while others think it should also document (or at least provide pointers) to the changes in the software itself (I fall in the second category). Since we don't have a standard for this, relaying only on the CVS logs might drive one into nasty problems. And yes, some standards, one way or the other, or somewhere in between, whatever, as long as we're all __consistent__ would be very useful. One would know what to expect and what not to expect o find out from reading the CVS logs or files/UPDATING or whatever. From my POV it would be very nice to be able to read everything important for a port update from inside our Ports Tree, w/out having to go to the WWW site, etc.. > [Wow, man, dspam ports is sure a place to learn many > things :-) Great job!] Thanks. I'm pretty sure I re-invented the wheel a few times there; but overall I consider it to be one of the most user-friendly ports we have. We could _optionally_ support that kind of UPDATING file in our framework; and we also could support the check-options-version. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" BOFH excuse #188: ..disk or the processor is on fire
signature.asc
Description: PGP signature