On Sun, 2015-07-05 at 11:22 +0200, Dirk Bächle wrote: > […] > > > https://bitbucket.org/scons/scons-contrib/admin/access > > > > > thanks a lot for creating this Bill.
Indeed, I think we can get some capital out of this initiative. > > […] > I would like to see another folder here for contributed "config" > snippets (automake-like checks for libs n' stuff). > Ideally, the "tools/config" folders have the same name for the SCons > core distribution and the "contrib" package, such that we can > easily blend them together via "import" at runtime... Mayhap we should iterate over a diagram of this structure rather than just words. I think you are suggesting: . +- tools | +- config +- scripts +- docs *- config But I am not sure I see why. (Probably me me slow.) […] > > The question here is: What is the "scons-contrib" supposed to do? So > far I got the impression it's a replacement for all the code > snippets in the Wiki that haven't found a place in their own repo > yet. This would clearly exclude the already existing Tools (see > ToolsIndex) from this list, and we don't move them to "scons-contrib" > but let them stay where they are. > Then the regular restrictions for moving directly into the core would > still hold (requires docs and tests). The evolution chain > would be: I think this is exactly what it is for: things that people haven't go the energy to create a repository for, but which the community think worth having. Or things for which having a separate repository is no longer appropriate. I think some of the tools with a separate existence should actually end up in this repository. Many of those I created I only created to get stuff out of the wiki, I am not using them and nor am I maintaining them myself. I think we should dispense with the "batteries included" attitude and get stuff out of core rather than putting more in the core. Creating an attitude of using DVCS strikes me a s a good move forward. Go and Rust are pushing this line, so why not SCons? > Wiki snippet -> scons-contrib -> external Tool (own repo) -> SCons > core Except the last bit. > If you're aiming for a "contains-all-external-tools-and-snippets" > repo, yes, we would need to have some clear criteria for accepting > them. In my opinion, it's all about the user here. He expects a > certain degree of maturity for the Tools and add-ons we provide, > such that they work out-of-the-box for him. Another difficult task > would be to find a single (!) maintainer for organizing this > whole bunch of loose ends. He, she, or not specified! I think any tool should have tests. So for me, no tests means no possibility of entry into this new repository. I would have used this rather than separate repositories for most of the tools I created by extracting stuff from the wiki. I caused this to happen. I guess I indirectly volunteered to be the official maintainer. This doesn't mean actively working on things, it means being the curator. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
