Hi there, I'm sorry for the delay, I was somewhat busy the last two days :-). Anyway, here are my notes from the last IRC meeting: - The new start time seems to be good; it has the advantage that those in europe are typically less tired when Lucas joins in Various Pkgfile things: - we define that they must be 7-bit ASCII for now; this was the de-facto standard already; we can always move to UTF-8 later - we discussed the "maintainer" vs. "arch maintainer" confusion a user might face; we believe that the proper solution is to document this properly; the original maintainer should stay in the Pkgfile, since changes in the port per se (bug fixes, security issues etc.) should go to him (preferably both to him and the arch maintainer) see http://git.die.net.au/cgit/crux/ports/core-x86_64/tree/gcc/Pkgfile Tree management: - Lucas wrote some scripts to simplify the maintenance of arch trees: http://nipul.die.net.au/sync_tools/ Please check them out and comment if you have time - For now, we'll consider x86 as the master tree; once x86_64 becomes official (hopefully either with 2.5 or 2.6), we'll allow "master ports" in either arch Handling outdated ports: - We have a new bug status "Work in progress" - We want to encourage users to use flyspray (either directly or via a to be written web interface) to report outdated bugs - if a maintainer doesn't change the new report to "Work in progress": a) security updates, critical bugs and broken urls should be looked at after three days b) other reports should be looked at at the casual meetings; in general, we should wait for at least one week - review: - for md5sum identical source=() changes, no ACK is needed - for the rest, another maintainer has to ack the change in in FS (maybe we'll have to take that to the mailing list as well) To those devs that we're at the meeting: please comment whether this sounds reasonable to you! Bug tracking: - we need to write a proper document on reporting bugs for outdated ports, as we've typically recommended to use direct mail so far - Lucas has written a very cool script to interface Flyspray. There are a couple of uses for that besides what he already suggested: - writing a simpler web interface to report outdated bugs - automating the review cycle, think: $ git-diff .|review-commit - > submits a patch to flyspray, maybe adding crux-devel to the list of addresses that get notified Finally, current open task: - move "Main" pages to "Wiki"; I guess we could do that next tuesday - write user _and_ developer docs on handling outdated ports; I'd suggest we wait with both to see whether there's any feedback from the other devs on the process I think this is about it :-) Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch