> 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. _______________________________________________ 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"
