On Wed, Dec 11, 2013 at 10:20 AM, Andrey Semashev wrote:

Maybe Boost.Utility should be revised as a collection of tools with none but the very basic dependencies, like Config and Preprocessor (this list is just my initial guess, it can be amended). Everything else could be extracted to distinct libraries.

To be more specific: call_traits.hpp -> Boost.TypeTraits generator_iterator.hpp -> Boost.Iterator current_function.hpp -> Boost.Config or just leave in Boost.Utility identity_type.hpp -> Boost.TypeTraits, not sure about this one in_place_factory.hpp, typed_in_place_factory.hpp -> Boost.Optional exception.hpp -> delete Extract to new submodules: compressed_pair.hpp -> Boost.CompressedPair operators.hpp -> Boost.Operators base_from_member.hpp -> Boost.BaseFromMember result_of.hpp -> Boost.ResultOf string_ref.hpp -> Boost.StringRef value_init.hpp -> Boost.ValueInitialization, if it's still needed ref.hpp -> Boost.Ref The rest is left in Boost.Utility. If I'm not missing anything, Boost.Utility then only depends on Boost.Config and Boost.Preprocessor.

Bjorn Reese wrote:

On 12/11/2013 08:00 AM, Andrey Semashev wrote:

...

compressed_pair.hpp -> Boost.CompressedPair

Or Boost.Tuple.

This doesn't look correct from a dependency perspective.

Andrey Semashev wrote:

I'm not sure moving ref.hpp to Boost.Bind and checked_delete.hpp to Boost.SmartPtr would result in better dependencies. boost::ref is used in many libraries, some arguably don't currently depend on Boost.Bind (I'm thinking of Boost.Phoenix, there may be others). Moving boost::ref to Boost.Bind would add a dependency but may not remove one (Boost.Phoenix would still depend on boost::result_of at least).

Yes, I agree. Extracting it as Boost.Ref makes more sense.

boost::checked_deleter is often used with Boost.Intrusive containers, and that code may not necessarily need smart pointers.

Currently Utility depends on SmartPtr anyway, although you are correct that checked_delete has nothing to do with SmartPtr in principle.

It is also not clear why current_function.hpp belongs in Boost.Assert and not e.g. Boost.Config.

The only reason is historical. I wrote it when I wrote assert.hpp. It could go into Config, if John wants to maintain it (which shouldn't be hard as it doesn't change much and the changes are generally trivial.)

Maybe Boost.Utility should be revised as a collection of tools with none but the very basic dependencies, like Config and Preprocessor (this list is just my initial guess, it can be amended).

Maybe. This was once the case. The problem is ensuring that it stays that way. Every utility component gets put into Utility because, well, where else? And so it grows (as does the list of maintainers that need access to it, which was another problem I was trying to address).

John Maddock wrote:

Well no I don't want to maintain it.... but logically a few of those headers could be moved into config and their authors could become part of the Config "team". Plus Boost.Config has mostly maintained itself recently, I'm hoping that all the folks who have helped with that will join the Config team and continue the good work ;-) Or else the much talked about "community" team can have access to Config etc.

Well... I know that teamwork is regarded as a Good Thing but I have my doubts about letting a "community" team maintain a core library (the corest of the core, in this case). I'd rather have you as the sole maintainer of Config. Even if - with GitHub - the only thing you do is press a button.

Alexander Lamaison wrote:

It's not the same thing as giving the whole world commit rights.

Yeah, I know. In Boost parlance though, "maintainer" does mean "commit rights", and therefore "community maintenance" does mean "giving the community commit rights". Even if the only thing you do is press the "Merge Pull Request" button from time to time, you're still the maintainer. That's not because only you can work on the code; it's because (a) if something goes wrong, it's your responsibility to fix it and (b) you're supposed to be familiar with the the decisions underlying the design of the library and the history behind them, and therefore can evaluate the merits of a proposed change and the risk of it breaking the world.

Alexander Lamaison wrote:

What part of that means only one person is qualified to make those decisions?

Nothing theoretically precludes the number of people qualified to make those decisions from being 118. In practice, however, the average hovers somewhere below one.

The community maintenance idea just means that that responsibility is shared between members of a team.

Yeah, I know that too. You're talking theory. I'm talking practice and history. You're not convinced, I know. Still, I ought to be allowed to express a personal preference for Config maintained by John Maddock over a Config maintained by a community. So I do.

On 11 December 2013 23:41, Alexander Lamaison wrote:

"Peter Dimov" writes:

...

Alexander Lamaison wrote:

...

What part of that means only one person is qualified to make those decisions?

Nothing theoretically precludes the number of people qualified to make those decisions from being 118. In practice, however, the average hovers somewhere below one.

...

The community maintenance idea just means that that responsibility is shared between members of a team.

Yeah, I know that too. You're talking theory. I'm talking practice and history.

Countless open-source projects successfully run this way aren't just a theory. Not to mention commercial software developers who maintain code together in teams every day.

Most successful open source projects are very picky about who has commit access. It seems unlikely that this community team would consist of people who have sufficiently proven themselves in the boost community to maintain core components. The "many eyes" theory doesn't require commit access to work.

On 12 December 2013 00:24, Alexander Lamaison wrote:

...

It seems unlikely that this community team would consist of people who have sufficiently proven themselves in the boost community to maintain core components.

I'm sure there's more than one person who understands the core components. Having it otherwise would put Boost in a vulnerable posistion. There's a good reason that companies make sure no important component is understood by just one developer.

Just because someone isn't given commit access doesn't mean that they don't understand the component. You're conflating different issues.

Date: Thu, 12 Dec 2013 00:38:33 +0000 From: daniel@calamity.org.uk To: boost@lists.boost.org Subject: Re: [boost] Splitting/rearranging Boost.Utility

On 12 December 2013 00:24, Alexander Lamaison wrote:

...

...

It seems unlikely that this community team would consist of people who have sufficiently proven themselves in the boost community to maintain core components.

I'm sure there's more than one person who understands the core components. Having it otherwise would put Boost in a vulnerable posistion. There's a good reason that companies make sure no important component is understood by just one developer.

Just because someone isn't given commit access doesn't mean that they don't understand the component. You're conflating different issues.

Perhaps we could get back to using this thread to talk about the future of Utility? I think there are other threads with the community team discussion going on.

OK. Is there a consensus on at least a part of the suggested changes, what is the procedure of creating new repositories and moving files from one repository to another, and what can I do to expedite the process? To recap, the dependencies I consider critical are assert.hpp (and current_function.hpp), ref.hpp, addressof.hpp, checked_delete.hpp.

On Sat, Dec 14, 2013 at 7:54 AM, Beman Dawes wrote:

On Fri, Dec 13, 2013 at 11:10 AM, Peter Dimov wrote:

...

OK. Is there a consensus on at least a part of the suggested changes, what is the procedure of creating new repositories and moving files from one repository to another, and what can I do to expedite the process?

Once the Community Maintenance Team gets approved by the steering committee (which is in process of voting now) and is up and running this sort of request can be handled by them. In the meantime, it falls in the release manager's collective laps.

I've polled the other release managers, and hopefully will have a response real soon now.

OK, the release managers are agreed - Peter will get the necessary permissions and he now has the necessary authority to do what ever is needed. Daniel James commented: "As for moving the files to a different repo, I think it depends on whether he wants to preserve the file history. If he doesn't then just copy the file. If he does, then I think he needs to use 'git filter-branch' to create a new history with just the appropriate file's history and then merge that into the other repo, or maybe use it as the basis of a new repo. Or perhaps he could create a branch, delete all the other files and then merge that into the other repo. I haven't got any experience of this, so I might be wrong. It might be best to start a new thread for others' opinions." I googled "git move file to another repository with history", and it looks like history preserving moves are frequently asked, and been covered in blogs, stackoverflow, etd. See http://gbayer.com/development/moving-files-from-one-git-repository-to-anothe... --Beman