[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