Development Practices (Proposal Progress)
Hi Everyone, I was looking around at the Trac wiki and saw that there's a page called "ImprovingPractices". It's https://svn.boost.org/trac/boost/wiki/ImprovingPractices if you want to look. The Objectives stated on the page are definitely the same ones I am looking to address with a proposal I was thinking of writing from scratch. A quick read through definitely seems to me that there is significant overlap between what I had in mind and what's already in this document. One thing that doesn't seem to be in this document, is how to get new libraries into a Boost distribution. I'm not sure if this part should be in the same document either, but I really do think that somehow the continuity between the development of a library for inclusion into Boost and the release procedure should be in-tune. The document also assumes that the development of a library happens in the same repository -- mainly because it assumes that subversion is going to be used exclusively. That's understandable, but in the case of a proposal to support Git-based libraries as well I wonder whether it's alright if I edit this document for the proposed enhancements. So my question would be: - What would be the best way for me to solicit feedback on a proposal that tweaks the current process? Is editing this wiki page the way or should I create a new one? - Because there a number of parts of the proposal I'm going to write that deal with things on the front-end of the process (the interest-gathering, development (collaborative or otherwise), and review/inclusion part) as well as the back-end of the process (distribution maintenance, bug fixing / patching, and release management / packaging) is it better if these areas are described in different Wiki pages or should one page with different sections suffice? - Is the Wiki the best place to put this? Would others be more comfortable in a different means of looking at and commenting on a complete proposal? Thanks in advance and I definitely look forward to feedback and guidance. -- Dean Michael Berris about.me/deanberris
At Tue, 4 Jan 2011 05:24:56 +0800, Dean Michael Berris wrote:
So my question would be:
- What would be the best way for me to solicit feedback on a proposal that tweaks the current process? Is editing this wiki page the way or should I create a new one?
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. my 2c -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Jan 11, 2011 at 11:36 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Tue, 4 Jan 2011 05:24:56 +0800, Dean Michael Berris wrote:
So my question would be:
- What would be the best way for me to solicit feedback on a proposal that tweaks the current process? Is editing this wiki page the way or should I create a new one?
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.
Alright, I'll do that. Thanks for the feedback Dave. -- Dean Michael Berris about.me/deanberris
On Tue, Jan 11, 2011 at 10:36 AM, Dave Abrahams <dave@boostpro.com> wrote:
At Tue, 4 Jan 2011 05:24:56 +0800, Dean Michael Berris wrote:
So my question would be:
- What would be the best way for me to solicit feedback on a proposal that tweaks the current process? Is editing this wiki page the way or should I create a new one?
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.
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. 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. 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. 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. --Beman
participants (3)
-
Beman Dawes -
Dave Abrahams -
Dean Michael Berris