Hi, I've added a few additional features to Jay's script to merge the httpup repos for our new 'contrib' collection. It's available at http://jw.tks6.net/files/crux/prtsync-jw/ I did some testing today, and am pretty happy with it. The next logical step would be to do an testing with some interested repo maintainers, but there's one question I think we should discuss first: on IRC we've come to the conclusion that it might be a good idea to explicitely select ports in your httpup repository which should be considered for 'contrib'. We realized this using a tag file, called '.sync'. So in order to publish $port, you just do a 'touch $port/.sync && httpup-repgen'. This means that if you subscribe to an httpup repository directly, you'll get .sync files during a ports -u. I think I can live with that for now, and am confident that if that's a problem, we'll find a solution. Still I'd like to hear opinions on that. If there are no objections, let's start testing ASAP. Should we spam clc-devel with notifications, or use a dedicated list? Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 03/12/05 17:03 Johannes Winkelmann wrote:
I've added a few additional features to Jay's script to merge the httpup repos for our new 'contrib' collection. It's available at http://jw.tks6.net/files/crux/prtsync-jw/
I did some testing today, and am pretty happy with it. The next logical step would be to do an testing with some interested repo maintainers,
We could as well temporarily 'adopt' some 3rd party repo, one for each clc member interested in testing, and test them internally. This could bring to quicker response times and/or better understanding of potential issues. Just an idea, I'm also fine with recruiting some victim, ahem, volunteer within httpup repo maintainers
but there's one question I think we should discuss first: on IRC we've come to the conclusion that it might be a good idea to explicitely select ports in your httpup repository which should be considered for 'contrib'. We realized this using a tag file, called '.sync'. So in order to publish $port, you just do a 'touch $port/.sync && httpup-repgen'. This means that if you subscribe to an httpup repository directly, you'll get .sync files during a ports -u. I think I can live with that for now, and am confident that if that's a problem, we'll find a solution. Still I'd like to hear opinions on that.
If I understand well this is a way of excluding stuff you don't want to publish: temp or custom ports, dups, etc. Ideally I'd prefer to avoid (if possible) ad-hoc solutions that would differentiate a standard port from a CLC / CRUX one, but I have no idea on how to treat this issue (apart from separating the public and custom repository, but this is surely a pain for the contributor).
If there are no objections, let's start testing ASAP. Should we spam clc-devel with notifications, or use a dedicated list?
I think a new list, specifically for the new contrib members would be a good idea and a perfect place for these initial tests. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
participants (2)
-
Johannes Winkelmann
-
Simone Rota