Re: [Boost-maint] Community Maintenance Team and neglected libraries
On Tue, Apr 22, 2014 at 12:10 PM, Andrey Semashev wrote: > On Wednesday 23 April 2014 00:29:17 Ben Pope wrote: > > In case you haven't heard of the CMT: > > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > > > I'm also interested in getting the test results less yellow and more > > green, I don't have a lot of time, I'm sure I'm not alone. > > > > There are quite a few places where the library code is probably fine, > > but the failure is in the test itself, the fix is often simple and > > uncontroversial. > > > > These easy fixes should just happen; make a pull request, ticket with > > patch, whatever; commit goes in; reminder when tests have cycled; merged > > to master; profit. > > This is a recurring topic and unfortunately the problem still stands. CMT > was > a step forward, but to my mind this is not enough. With SVN we had commit > rights everywhere, and such simple fixes went in much easier. After > modularization some libraries were left effectively unmaintained and > inaccessible. CMT does have rights to push to some libraries but not all > and > therefore does not fix the problem completely. > We've been discussing such issues in steering committee, release management, and community maintenance sessions at C++Now this week, with a couple of more sessions scheduled that will address library review concerns. The details will evolve over time, but the CMT is gaining more responsibility and is being given authority to respond to pull requests to any library when the maintainer isn't available to respond. As procedures evolve, that will expand to cover more situations - pull requests are just the starting point for a general need to be responsive to various kinds of requests. > > To my mind CMT should have access to all libraries, maintained or not. If a > given library is actively maintained then CMT doesn't need to intervene. > However, if the maintainer goes silent for considerable time, CMT has the > ability to apply such fixes. > Yes, that's more or less the approach that has gained support. The actual mechanism will be to continue to limit the CMT write permissions to CMT maintained libraries, but have small group of senior developers within the CMT who have write permissions to all libraries. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
Re: [Boost-maint] Community Maintenance Team and neglected libraries
> -Original Message- > From: Boost-maint [mailto:boost-maint-boun...@lists.boost.org] On Behalf Of > Andrey Semashev > Sent: 22 April 2014 19:10 > To: boost-maint@lists.boost.org > Subject: Re: [Boost-maint] Community Maintenance Team and neglected libraries > > On Wednesday 23 April 2014 00:29:17 Ben Pope wrote: > > In case you haven't heard of the CMT: > > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > > > I'm also interested in getting the test results less yellow and more > > green, I don't have a lot of time, I'm sure I'm not alone. > > > > There are quite a few places where the library code is probably fine, > > but the failure is in the test itself, the fix is often simple and > > uncontroversial. > > > > These easy fixes should just happen; make a pull request, ticket with > > patch, whatever; commit goes in; reminder when tests have cycled; > > merged to master; profit. > > This is a recurring topic and unfortunately the problem still stands. CMT was a step > forward, but to my mind this is not enough. With SVN we had commit rights > everywhere, and such simple fixes went in much easier. After modularization some > libraries were left effectively unmaintained and inaccessible. CMT does have rights > to push to some libraries but not all and therefore does not fix the problem > completely. > > To my mind CMT should have access to all libraries, maintained or not. If a given > library is actively maintained then CMT doesn't need to intervene. > However, if the maintainer goes silent for considerable time, CMT has the ability to > apply such fixes. +1 I'd go so far as to suggest that we go back to the previous SVN arrangements where all library authors had write access to everything. I don't remember it causing trouble - rather that it was felt so ill-mannered to change someone else's library that changes were not made when it would have much better if they had! Where I feel a finer grained control is useful is to allow write access just to experimental branches from develop. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
Re: [Boost-maint] Community Maintenance Team and neglected libraries
On Wednesday 23 April 2014 00:29:17 Ben Pope wrote: > In case you haven't heard of the CMT: > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > I'm also interested in getting the test results less yellow and more > green, I don't have a lot of time, I'm sure I'm not alone. > > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > > These easy fixes should just happen; make a pull request, ticket with > patch, whatever; commit goes in; reminder when tests have cycled; merged > to master; profit. This is a recurring topic and unfortunately the problem still stands. CMT was a step forward, but to my mind this is not enough. With SVN we had commit rights everywhere, and such simple fixes went in much easier. After modularization some libraries were left effectively unmaintained and inaccessible. CMT does have rights to push to some libraries but not all and therefore does not fix the problem completely. To my mind CMT should have access to all libraries, maintained or not. If a given library is actively maintained then CMT doesn't need to intervene. However, if the maintainer goes silent for considerable time, CMT has the ability to apply such fixes. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
[Boost-maint] Community Maintenance Team and neglected libraries
In case you haven't heard of the CMT: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance I'm also interested in getting the test results less yellow and more green, I don't have a lot of time, I'm sure I'm not alone. There are quite a few places where the library code is probably fine, but the failure is in the test itself, the fix is often simple and uncontroversial. Without picking on any particular library or author, here are some examples: * Link the tests with boost::system http://thread.gmane.org/gmane.comp.lib.boost.maint/92 * Merge existing fixes in develop to master http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 * Fight with casts http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 * Disambiguate a type https://svn.boost.org/trac/boost/ticket/9540 The responses have been frustrating to say the least, we really need a way to move forward on this. These easy fixes should just happen; make a pull request, ticket with patch, whatever; commit goes in; reminder when tests have cycled; merged to master; profit. The impact is clear: the test results are a mess -> spotting regressions is hard -> regressions are not spotted -> the tests results are a mess... And that says nothing of the unfair and unrepresentative impression of Boost that such a test matrix gives to potential users. The most frustrating part is that people that are willing to help cannot. As far as I can tell, the libraries that the maintenance team have commit privileges over are looking fantastic; I don't know if that is coincidence, but congratulations anyway. How can they help further? Nobody wants their code trampled all over, but some of these easy fixes are ignored for far too long. If you are a library author who has failing tests and my title offends you, I succeeded :P. Seriously though, I really have no interest in attacking any particular library or author here. Failing tests affect everybody and we need a way to get them fixed without causing undue offence. Discuss. Ben ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
