Distributed Development Process (was Re: Development Practices (Proposal Progress))
On Thu, Jan 13, 2011 at 9:15 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Jan 11, 2011 at 10:36 AM, Dave Abrahams <dave@boostpro.com> wrote:
Create a new one... I don't think we want to tweak "the process." I think we want to create an alternative process for people who are interested in following a more modern, decoupled development model. Eventually, if it works, the other one will die of underuse. The thing is that you have to make sure that your proposal doesn't clash with the way we do things now: for example, it can't create significant new work for the release managers.
tl; dr; -- feedback on https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess would be very much appreciated!
Excellent points!
For example, I'd very much like to move both the libraries I maintain and my release management work to Git. I've been using it for a while now on various projects, including one very small (three contributors) distributed project, and find Git preferable by a wide margin. But others will want to stick with SVN at least for awhile. Because Git can track a Subversion repository, it is probably possible to use both without undue trouble.
I have the same experience -- and I've worked with larger teams that have been using Git exclusively with wonderful results. It's the difference between a concurrent lock-free queue and one that has a critical section on all the member functions. One invites a lot less friction and enables more fluid workflows while the other, not so much.
While I'm leery of anything that would "create significant new work for the release managers" on an ongoing basis, I am willing to put in some extra work during a transition.
Cool. :)
Areas where I personally don't want any big changes yet are the Boost build and regression testing systems. Alternatives for either of these systems don't appear anywhere near ready for prime time WRT Boost.
Right, I haven't gotten thinking about that part yet, but I think others are already working on that front. :)
The formal review system needs a drastic rework to make it more parallel and remove bottlenecks, but I don't have anything beyond vague feelings about how to do that.
Yes and I intend to address that in this document: https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess I haven't gotten to the part on the specifics yet but I think it would be good to get feedback on what's already there. :) -- Dean Michael Berris about.me/deanberris
I have read this document: https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess There is a lot of good suggestions, and one of them is: "We want to enable the Boost project to scale up to have more than one distribution. As it is at the moment there is only one Boost C++ Library distribution which contains all the accepted libraries." IMHO, it's very good idea. But if we have several Boost distributions - what if library A depends on library B, but A and B placed in *different* distributions? - Denis
"We want to enable the Boost project to scale up to have more than one distribution. As it is at the moment there is only one Boost C++ Library distribution which contains all the accepted libraries."
IMHO, it's very good idea. But if we have several Boost distributions - what if library A depends on library B, but A and B placed in *different* distributions?
- Denis
Isn't it the problem that Ryppl (for a concrete example) tries to solve?
On Wed, Jan 19, 2011 at 3:18 AM, Denis Shevchenko <for.dshevchenko@gmail.com> wrote:
I have read this document:
https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess
Thanks for taking the time to read the document! :)
There is a lot of good suggestions, and one of them is:
"We want to enable the Boost project to scale up to have more than one distribution. As it is at the moment there is only one Boost C++ Library distribution which contains all the accepted libraries."
IMHO, it's very good idea. But if we have several Boost distributions - what if library A depends on library B, but A and B placed in *different* distributions?
I think once the document is more complete, it would amount to basically saying: all distributions that have the same release version, will be parts of one whole boost distribution. So then you can pick which distributions you want, and install them in the same location, each one over-writing the parts that are common, and there's basically not going to be any difference. If you do this with all the available distributions, you get in the end a single distribution that contains all the accepted libraries. The reasoning for this is so that there can be more release managers that manage just part of the whole Boost library. This alludes to the similarity with Linux subsystems where you have maintainers that basically ensure that the subsystems they maintain are up to snuff. This allows us to have more release managers, as well as limit the amount of work that release managers need to do for the specific distributions they manage. So in Boost's case, the union of all distributions is the single boost distribution that we have now. If you want all the Boost libraries, you get the monolithic distribution (like Linux installers) or if you just want to get for example Spirit and all the libraries it depends on and extensions that build upon Spirit only, then you get that distribution. This would be made easier once all the libraries are in their own repositories where there are only tags/branches indicating which version of that library is for general availability. :D I hope this makes sense. :) -- Dean Michael Berris about.me/deanberris
19.01.2011 11:50, Dean Michael Berris пишет:
The reasoning for this is so that there can be more release managers that manage just part of the whole Boost library. This alludes to the similarity with Linux subsystems where you have maintainers that basically ensure that the subsystems they maintain are up to snuff. +1. I think, it's very good idea. ...if you just want to get for example Spirit and all the libraries it depends on and extensions that build upon Spirit only, then you get that distribution. Okay. And how much distributions we'll have?
- Denis
On Wed, Jan 19, 2011 at 4:01 PM, Denis Shevchenko <for.dshevchenko@gmail.com> wrote:
19.01.2011 11:50, Dean Michael Berris пишет:
The reasoning for this is so that there can be more release managers that manage just part of the whole Boost library. This alludes to the similarity with Linux subsystems where you have maintainers that basically ensure that the subsystems they maintain are up to snuff.
+1. I think, it's very good idea.
...if you just want to get for example Spirit and all the libraries it depends on and extensions that build upon Spirit only, then you get that distribution.
Okay. And how much distributions we'll have?
I don't think there should be an artificial limit -- the beauty of this approach is that whenever people step up to want to maintain distributions, it can be as simple as getting some Library Maintainers or Contributors to get together and have someone be a Trusted Release Manager -- by having two existing Trusted Release Managers sign with high trust the key of either a Contributor or a Library Maintainer. Or, the easier way would be to have a Trusted Release Manager start that distribution, get some Contributors/Library Maintainers into the mix, and promote some of them to be Release Managers for a distribution. This three-level hierarchy can grow broad and flat allowing eventually not just a single tree but a forest of hierarchies. I can see a Boost.Algorithms distribution that can contain multiple libraries and be a self-contained effort to release just a distribution that contains algorithms. The point is the number of distributions scale to the number of people willing and able to contribute -- this time it's not the process that will get in the way. :) HTH -- Dean Michael Berris about.me/deanberris
Update: There is more information on the Wiki page now, pertaining to a few more definitions and the beginnings of the process discussion. Please see: https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess You may have to refresh the page to get the latest version. Basically, the changes there now include: - Definition for the role of a Review Manager - Definition for the role of a Review Manager Assistant (lifted from Joachim's suggestion) - Definition for the "Boost Community" - The definition of a lower barrier to entry style Acceptance Review process - The hint of a Maintenance Review process Feedback on the contents -- both old and new -- would be most appreciated. Thanks in advance and I hope to hear from the community soon! -- Dean Michael Berris about.me/deanberris
I have a question about updated document "DistributedDevelopmentProcess": " A Candidate Library is a library being considered or developed for inclusion in Boost. The criteria for Candidate Libraries are: ... The library has been explicitly posted to be considered a Candidate Boost Library to the following venues: - The Boost Users Mailing List - The Boost Developers Mailing List " But on the page http://lists.boost.org/mailman/listinfo.cgi/boost-users I read this: "If your interest is in library submission, development, or review, please subscribe to the Boost developer list." Question: author of Candidate Library must post information about library in *both* lists, or will be enough "Boost Developers Mailing List"? Thanks. - Denis
On Thu, Jan 20, 2011 at 2:29 AM, Denis Shevchenko <for.dshevchenko@gmail.com> wrote:
I have a question about updated document "DistributedDevelopmentProcess":
" A Candidate Library is a library being considered or developed for inclusion in Boost. The criteria for Candidate Libraries are: ... The library has been explicitly posted to be considered a Candidate Boost Library to the following venues: - The Boost Users Mailing List - The Boost Developers Mailing List "
But on the page http://lists.boost.org/mailman/listinfo.cgi/boost-users I read this:
"If your interest is in library submission, development, or review, please subscribe to the Boost developer list."
Question: author of Candidate Library must post information about library in *both* lists, or will be enough "Boost Developers Mailing List"?
In my view, I think it should be both. Availability of a potentially useful library would be welcome in the users list where there are potentially a lot more people looking who might want to try new libraries out. The nitty gritty details of what's going on in the library can and probably should be discussed in developers mailing list, but otherwise, just announcing the availability of a candidate library for review until acceptance should be encouraged in both lists.
Thanks.
Thank you too, I hope this helps. :) -- Dean Michael Berris about.me/deanberris
participants (3)
-
Dean Michael Berris -
Denis Shevchenko -
Klaim