Re: [27700] trunk/dports/devel/distract/Portfile
On Aug 12, 2007, at 05:59, source_changes@macosforge.org wrote:
Revision: 27700 http://trac.macosforge.org/projects/macports/changeset/27700 Author: gwright@macports.org Date: 2007-08-12 03:59:12 -0700 (Sun, 12 Aug 2007)
Log Message: ----------- Add dependency on monotone and update other dependencies.
You also: * Updated the port version * Reformatted all the whitespace * Changed the long description * Changed the destroot phase * Changed the master_sites URL * Removed the Id header (I put it back in r27760) * Did not indicate who authored these changes You may wish to amend your commit message with: $ svn propedit --revprop -r 27700 svn:log http://svn.macosforge.org/ repository/macports/trunk At the very least, you should describe everything you do in your commit messages, but it would be better in the future to separate these into several logically-grouped commits. In particular, whitespace changes should be made on their own, with no functional changes made at the same time. Otherwise it becomes very difficult to tell by glancing at a diff what functional changes have been made in a given revision. Mark, I'm afraid I haven't read most of the new guide yet, but if there's nothing in there yet about this, it would be useful to add.
Modified Paths: -------------- trunk/dports/devel/distract/Portfile
Modified: trunk/dports/devel/distract/Portfile =================================================================== --- trunk/dports/devel/distract/Portfile 2007-08-12 10:34:35 UTC (rev 27699) +++ trunk/dports/devel/distract/Portfile 2007-08-12 10:59:12 UTC (rev 27700) @@ -1,24 +1,24 @@ -# $Id$ - PortSystem 1.0 -name DisTract -description A distributed bug tracking system based on monotone -long_description DisTract is a distributed bug tracking system. It uses \ - Firefox as frontend for the user and the monotone version \ - control system as backend, which provides data storage and \ - network synchronization. -version 0.2.3 -homepage http://www.distract.wellquite.org -master_sites ${homepage}/downloads/ -categories devel -maintainers me@thomaskeller.biz -checksums md5 07d098c51755433ef11f886923d16cec +name DisTract +version 0.2.5 +categories devel +maintainers me@thomaskeller.biz +description A distributed bug tracking system based on monotone +long_description \ + DisTract is a distributed bug tracking system. It uses \ + the Firefox browser as frontend for user interaction and \ + the monotone version control system as backend, which \ + provides data storage and network services.
-depends_build port:ghc\ - port:haskell-chunks\ - port:haskell-hinstaller\ - port:haskell-parsedate +homepage http://www.distract.wellquite.org/ +master_sites http://www.distract.wellquite.org/downloads/ +checksums md5 c806002ec1f73bf860bbb3164e2042dd
+depends_build port:ghc \ + port:hs-chunks \ + port:hs-hinstaller +depends_run port:monotone + configure { cd ${worksrcpath}/haskell system "runghc Setup.hs configure" @@ -30,7 +30,7 @@ }
destroot { - cd ${worksrcpath}/haskell/dist/build/DisTractInstaller - system "cp DisTractInstaller ${destroot}/${prefix}/bin" + cd ${worksrcpath}/haskell + system "runghc Setup copy --copy-prefix=${destroot}${prefix}" }
Ryan Schmidt <ryandesign@macports.org> writes:
At the very least, you should describe everything you do in your commit messages, but it would be better in the future to separate these into several logically-grouped commits. In particular, whitespace changes should be made on their own, with no functional changes made at the same time. Otherwise it becomes very difficult to tell by glancing at a diff what functional changes have been made in a given revision.
Mark, I'm afraid I haven't read most of the new guide yet, but if there's nothing in there yet about this, it would be useful to add.
I'm afraid that I haven't given much thought to committer docs yet. I suppose it might fit okay in the MacPorts Project section, but I'm not completely sure it belongs in the guide and not on the Wiki. I'm not sure I like that in the guide, but as I said I haven't really thought about it much. I can't recall whether there was any discussion on this in the past. Mark
On 14/08/2007, at 12:28, markd@macports.org wrote:
I'm afraid that I haven't given much thought to committer docs yet. I suppose it might fit okay in the MacPorts Project section, but I'm not completely sure it belongs in the guide and not on the Wiki. I'm not sure I like that in the guide, but as I said I haven't really thought about it much. I can't recall whether there was any discussion on this in the past.
In my opinion, the fundamental committer documentation should not be on the wiki, as it should be just as stable and "official" as the user documentation. I don't mind, however, if we have it separated from the user guide. As for discussion of this, I'm pretty sure there has been, but I haven't the time just now to look at it. As I'm supposed to be helping you lead the documentation project, Mark, I'd be happy for you to leave leading committer documentation to me. (I haven't made many commits recently partly because of business, and partly because you're working on it faster than I could and I've been quite happy with what I've seen!) Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org
Boey Maun Suang <boeyms@macports.org> writes:
I'm afraid that I haven't given much thought to committer docs yet. I suppose it might fit okay in the MacPorts Project section, but I'm not completely sure it belongs in the guide and not on the Wiki. I'm not sure I like that in the guide, but as I said I haven't really thought about it much. I can't recall whether there was any discussion on this in the past.
In my opinion, the fundamental committer documentation should not be on the wiki, as it should be just as stable and "official" as the user documentation. I don't mind, however, if we have it separated from the user guide.
As for discussion of this, I'm pretty sure there has been, but I haven't the time just now to look at it.
Yeah that makes sense, I just hadn't thought about it yet. Sounds fine in the guide unless you think it better external.
As I'm supposed to be helping you lead the documentation project, Mark, I'd be happy for you to leave leading committer documentation to me. (I haven't made many commits recently partly because of business, and partly because you're working on it faster than I could and I've been quite happy with what I've seen!)
If you want to do committer stuff that'd be great whenever you get time. I don't think I have enough knowledge to do that part anyway; I just use the few basic subversion commands I know. And I don't think there is any rush. I just feel rushed to get the guide parts I'm working on now substantially complete while I have it in mind. I've been moving faster than I ever anticipated, so don't feel bad. A rare burst of energy on my part. Though I've wanted to do it for a long time, I never anticipated even starting when I did. I think that is the nature of work on open source projects, since we all have real jobs. And thanks for the kiind words of encouragement! Mark
On Aug 13, 2007, at 11:52 PM, markd@macports.org wrote:
Boey Maun Suang <boeyms@macports.org> writes:
I'm afraid that I haven't given much thought to committer docs yet. I suppose it might fit okay in the MacPorts Project section, but I'm not completely sure it belongs in the guide and not on the Wiki. I'm not sure I like that in the guide, but as I said I haven't really thought about it much. I can't recall whether there was any discussion on this in the past.
In my opinion, the fundamental committer documentation should not be on the wiki, as it should be just as stable and "official" as the user documentation. I don't mind, however, if we have it separated from the user guide.
As for discussion of this, I'm pretty sure there has been, but I haven't the time just now to look at it.
Yeah that makes sense, I just hadn't thought about it yet. Sounds fine in the guide unless you think it better external.
IIRC, we had agreed that committer documentation (comprising everything from portfile writing guidelines --taking advice from the existing portfile(7) man page-- to miscellaneous stuff like best subversion practices --some of which should be coded into pre/post- commit hooks to make them mandatory, like svn properties--) would make it into the new guide in some sort of "Advanced" section. Regards,... -jmpp
participants (4)
-
Boey Maun Suang
-
Juan Manuel Palacios
-
markd＠macports.org
-
Ryan Schmidt