On Mar 18, 2007, at 07:55, Sbranzo wrote:

A new version of mutt-devel is available: http://trac.macports.org/projects/macports/ticket/11553

I received no response so far from the maintainer, can someone commit the (trivial) patch?

Had you already sent an email to the maintainer? If you only submitted the ticket, the maintainer may not have seen it yet; Trac does not send email unless you list the address in the CC field, which I have now done. I tried your patch and mutt-devel seemed to build for me, thought I don't use the software so I don't feel competent to verify that the new version works correctly.

On Mar 19, 2007, at 03:14, Boey Maun Suang wrote:

On 19/03/2007, at 11:13, Ryan Schmidt wrote:

...

If you only submitted the ticket, the maintainer may not have seen it yet; Trac does not send email unless you list the address in the CC field

Oh, I thought to the contrary, given this part of the page at http://trac.macosforge.org/projects/macports/wiki/TracTicketing :

<snip> Assign to:

Select the maintainer of the port as listed by the Portfile "maintainers" keyword. If the maintainer is _not_ on the list, place his/her email address in the Cc: field so they will be notified. [emphasis mine] </snip>

That explains the delay in the review of the tickets that I've submitted; thanks to Elias Pipping for trawling through them :-) Could the wiki be updated appropriately?

Did it! Thanks for reminding me.

On Mar 19, 2007, at 4:38 AM, Ryan Schmidt wrote:

...

That explains the delay in the review of the tickets that I've submitted; thanks to Elias Pipping for trawling through them :-) Could the wiki be updated appropriately?

Did it! Thanks for reminding me.

Hello Ryan! Could I please ask you to amend the TracTicketing Wiki entry again to list the new "Available Ports" & "New Ports" milestones in our roadmap? They still need polishing and I've called for feedback on them and on any new potential milestones developers and/or users might find appropriate, but my current idea is to keep a balance between enough milestones to allow for proper classification of our tickets but not too many to not spread things too thin (thus making it easy to get lost while searching for stuff). I'm thinking combining those two milestones with proper ticket "Short Summary" prefixes might work quite well: "NEW:" A new port submission These tickets would naturally fall into the "New Ports" milestone, so that particular prefix might be a bit unnecessary now; "BUG:" A problem - a port is not installing functioning as intended. "UPDATE:" A port update patch submission "RFE:" A request for enhancement - updates, new ports, or suggestions for how you'd like a port modified. All these tickets would be assigned to the "Existing Ports" milestone, so maybe these prefixes might still come in handy. Thoughts? Thanks in advance for your help! Regards,... -jmpp

On Mar 20, 2007, at 2:15 PM, Elias Pipping wrote:

There's basically these kinds of tickets out there

* general Macports-base-related tickets * minor annoyances * major feature requests

The way I see it, "base" tickets are of two subtypes: 1) bug reports, either minor or big; 2) feature requests (enhancements), either minor or big. They should go into either a version'd milestone (say, "MacPorts 1.5") or into the newly created "Needs developer review" milestone, depending on: *) Is it a feature request? Discussion on this list (and/or on the ticket, of course) and consensus should decide what future MacPorts release it belongs in, but otherwise it should go into "Needs dev review" until there's consensus; *) Is it a bug? Feel free to add it to a version'd milestone if you plan to work on it yourself and fix it; otherwise put it in "Needs dev review" and move it to a version'd milestone only after proper discussion here (yes, even if the bug is critical, for which we have the "Severity" and "Priority" ticket fields, along with good & loud ranting ;-) All in all, version'd milestones and "Needs dev review" should only carry tickets of the "base" component and none others (the only other two that currently make sense are "Infrastructure", which is for MacOSForge & hosting related issues, and "ports", which we discuss below).

* ports-related tickets * new ports

They now have their own milestone.

* bugs * updates * requests for new variants/changes to the port

Lets call the last "miscellaneous enhancements" (request for enhancement, RFE).

bugs, updates and feature-/variant-requests are all thrown together into available ports whereas new ports have a separate milestone. that should be changed, i believe. maybe four milestones for that is too many, maybe not.

Right, we're throwing three different ticket subtypes, all belonging to the "ports" component, into a single milestone, and what I would like to know is if that combined with proper summary prefixing ("BUG", "UPDATE" & "RFE", respectively) is enough and functional... or if separate milestones for each subtype are absolutely necessary. I don't want to sound like I'm adverse to creating them, I'm not; I just want to make sure we're making the right decision here 'cause, one, I don't want to spread things too thin (as previously stated) and, two, I wouldn't like to see any of us going through the hell of editing literally hundreds and hundreds of tickets to adapt to a new layout if we ever need to change our roadmap once these milestones are fully in use. As for filtering tickets in the combined "Available Ports" milestone, proper trac searching can be of great help: http://trac.macports.org/projects/macports/search?q=BUG&ticket=on http://trac.macports.org/projects/macports/search?q=UPDATE&ticket=on http://trac.macports.org/projects/macports/search?q=RFE&ticket=on To construct these all you need to do is browse to the Search module and deselect "Changesets" and "Wiki" and introduce the proper ticket prefix in the search field, but suffice it to say that the above URL's serve as static links to all the matching results in our database (going *all* the way back!). More complex searches (ticket open? closed? assigned? etc..) can be performed with the help of the Reports module and either an existing report or a custom query, but I readily realize the natural filters a roadmap milestone provides can easily be of greater help. Feedback people, feedback! :-P -jmpp

committed in r23005. http://trac.macports.org/projects/macports/changeset/23005 Regards, Elias Pipping On Mar 21, 2007, at 7:46 PM, Sbranzo wrote:

On 18/03/07 13:55, Sbranzo wrote:

...

A new version of mutt-devel is available: http://trac.macports.org/projects/macports/ticket/11553

I received no response so far from the maintainer, can someone commit the (trivial) patch?

ping :-)

Gufo _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

On 2007-03-21 20:21:26 +0100, Elias Pipping wrote:

committed in r23005.

http://trac.macports.org/projects/macports/changeset/23005

-depends_lib port:gettext port:libiconv +depends_lib port:gettext port:libiconv port:ncurses It should depend on ncursesw (used by default for UTF-8 support). You can check with "otool -L" that it is linked against libncursesw. BTW, when the next version is out, remember to remove the buffy variant: the compile-time option has been replaced by a runtime variable in the trunk: http://dev.mutt.org/hg/mutt/rev/b0172175cc89 -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)