[Scons-dev] Repo not wiki for tools and add-ons

Russel Winder russel at winder.org.uk
Sun Jul 5 14:57:40 EDT 2015


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:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150705/7e16fc1f/attachment.pgp>


More information about the Scons-dev mailing list