On Wed, Jan 29, 2014 at 11:12 AM, Fernando Apesteguía <fernando.apesteg...@gmail.com> wrote: > On Wed, Jan 29, 2014 at 10:27 AM, Kurt Jaeger <li...@opsec.eu> wrote: > >> Hi! >> >> > Unfortunately, nothing is happening. I expected to hear some voices about >> > certain ideas that have popped up, like: >> > >> > * can we cut off old and 'unloved' PR's in order to reduce the amount of >> > work and make reassessment of that amount >> >> There is the other view of this which says "PRs do not eat hay, closing >> them does not really fix anything". I think this one is still open >> for debate. >> >> > * can we use people who volunteered to work on the PR's >> >> There are people submitting PRs, and those committing changes, >> and in between them those people that check/confirm PRs. >> >> They could do that before and they can still do it now, if they want to. >> >> So besides *doing* this there is not much "push" that can help here. >> >> > * can we incorporate automation in the PR workflow, for example, the one >> > provided by redports >> >> I've read through the thread and would like to hear more about >> this. Can anybody with knowledge about it please remind us of the >> details to this idea ?
The idea is pretty simple. redports.org is able to build various "patches" on top of the FreeBSD portstree already. So all that is missing is just a small script that runs periodically and fetches the patches from GNATS and commits them to the redports repository to trigger automated builds. The resulting buildlogs can be send to the GNATS database as a followup to nform the submitter about failures. Well the code for that has been written in large parts a year ago already. So all it needs is a consensus that this is a good thing and some cleanup to get it ready for automatic operation. > redports is a great service to check ports. I use it after testing my > changes in local (with port test and such). Then I upload the changes to > redports and wait for it to compile in multiple groups (different archs and > releases). Once it's compiled succesfully I add the proper log to my PR > submission. This way the commiter (or whoever is looking at it) would save > _a lot of time_ instead of trying to compile again the port just to see if > it is fine. He/She could even try it again in his/her redports account! > > I think sending the redports log along with the PR should be kind of > mandatory. And, although I don't know the infrastructure details, it should > be possible to send the redports commit reference, and retrieve the patch > automatically. That would save time. Yeah I am working on some scripts that help with that and also allow to work more efficient with port PRs. Right now all people I know have written their own set of scripts to kind of optimize their workflow but most of them are quite simple and don't work for more than one person. With redports.org being the central place where more people work in a similar fashion I think it makes sense to write some tools that help with the usual tasks. The result is rptools which is still quite rough so don't use it yet please unless you want to help developing it: https://redports.org/browser/decke/ports-mgmt/rptools https://github.com/decke/rptools -- Bernhard Froehlich http://www.bluelife.at/ _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
