On Wed, 27 Apr 2011 09:17:46 -0400 Steven Kreuzer <skreu...@freebsd.org> articulated:
> > Personally, I believe that the current system, if not partially > > broken, is far from ideal. > > Speaking as a ports committer, I do agree with you that the current > workflow that we have in place is less then ideal for the size of the > ports tree as well as the number of patches that we receive. > > When the current workflow was first developed, the ports tree was much > smaller and > easier to work with. It has grown to over 23,000 ports and we are > starting to see scaling issues. > > However, these issues have been known for quite some time. Behind the > scenes, numerous ideas have been kicked around on how to better deal > with contributions from > independent developers, how to accept and review patches quicker and > how to generally > streamline our workflow. > > Unfortunately, the problem really becomes that unless we want to > severely disrupt what > we currently have in place for an extended period of time, we can > really only make small > gradual changes and hope that eventually we end up in a better > position then when we > started. > > > I would prefer to see a system where each submitted > > PR is assigned a specific number (I believe it is actually) and then > > assigned in numeric order to the next available committer. That > > committer would then be responsible for either committing the > > PR/Port/Whatever within a preset time frame, or informing the > > original submitter why the said article was not/could not be > > approved at the present time. Allowing a submitter to languish > > while pondering what has become of their document certainly does > > seem justified. > > The problem with this system is that certain developers sometimes only > work on a certain > subset of the tree. Your fifo system does not take that into account > > For example, I maintain quite a few perl modules and often > grab PRs for perl related things. This is mainly because I have an > interest in keeping > the perl stuff in good shape because I use it every day. I generally > never deal with > any PR that deals with ruby since I don't use ruby. As a result, I am > not familiar with > the ruby specific knobs in the ports tree. I would rather let another > developer who is > familiar with those and has an interest in keeping ruby well > maintained deal with those > PRs. Unfortunately, from time to time, the person who deals with the > ruby stuff could be > swamped with work or family issues and is unable to attend to it as > quickly as I may have > been able to. Would you prefer to wait a little while longer for that > person to grab the PR, or > would you rather have me commit the patch and possibly break your > application running in > production? > > Also, with your fifo system, what would happen if I don't commit an > update within the allotted > time frame? > > Perhaps the happy medium is that if you submit a PR and it doesn't get > assigned for a few days, > maybe ask in #bsdports on irc if someone could take a look at the PR. > If you submit a patch > and it does get assigned but a few days goes by and it doesn't get > committed, we could update the > PR to let you know that we haven't had a chance to look at it but hope > to have a little bit of time in > the next few days to take care of it. Thank you. A well thought out reply and one that I can agree with in most aspects. I think that 'UPDATING' the PR to let the submitter know that he/she has not been forgotten and to keep them aware of any problems with the PR is certainly a welcome suggestion. Unfortunately, that is rarely presently done. Certainly, we should all be able to come to some consensus as to what constitutes a reasonable time frame. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ _______________________________________________ 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"