Re: [Scons-dev] Repo not wiki for tools and add-ons
+1 on using SCons test framework for any contrib tool tests. On Sun, Jul 5, 2015 at 2:58 PM, Russel Winder wrote: > On Sun, 2015-07-05 at 13:17 -0400, William Blevins wrote: > > > […] > > Most of the wiki tools are rather simple. I'm not sure I see the > > harm in > > going from scons-contrib -> SCons core directly provided there are > > tests. > > Though that brings up another question. Since all the SCons test > > framework > > only exists in the core repo, in what form should tests for > > contributed > > code exist? > […] > > Dirk created a test framework for standalone tools, so I think we > demand that be used. > > -- > Russel. > > = > Dr Russel Winder t: +44 20 7585 2200 voip: > sip:russel.win...@ekiga.net > 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Repo not wiki for tools and add-ons
On Sun, 2015-07-05 at 13:17 -0400, William Blevins wrote: > […] > Most of the wiki tools are rather simple. I'm not sure I see the > harm in > going from scons-contrib -> SCons core directly provided there are > tests. > Though that brings up another question. Since all the SCons test > framework > only exists in the core repo, in what form should tests for > contributed > code exist? […] Dirk created a test framework for standalone tools, so I think we demand that be used. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk 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 Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Repo not wiki for tools and add-ons
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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk 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 Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Repo not wiki for tools and add-ons
On Sun, Jul 5, 2015 at 5:22 AM, Dirk Bächle wrote: > Hi, > > On 04.07.2015 20:46, Russel Winder wrote: > >> On Sat, 2015-07-04 at 13:17 -0400, Bill Deegan wrote: >> >>> Russel, >>> >>> I've created: >>> >>> https://bitbucket.org/scons/scons-contrib/admin/access >>> >>> > thanks a lot for creating this Bill. > > >> [...] >> >> Would it be worth having 3 base dirs: >>> tools >>> scripts >>> docs >>> ? >>> >>> > 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... > > Or just have tools live in the root of the repo? >>> >> >> I think idea of having tools as a sub-heirarchy is fitting and gives >> most flexibility. Indeed I wonder if we go with this, we have had >> sufficient debate on structure to begin to act. >> >> We do perhaps need to have criteria for accepting new tools, and >> ejecting current tools. I have a few Mercurial repositories on >> BitBucket that are immediate candidates, but the question is whether >> they are ready or whether they would be better staying separate for >> now. Clearly I could put them all in but would that be the right thing >> to do just now? >> > > 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: > > Wiki snippet -> scons-contrib -> external Tool (own repo) -> SCons core > > > Most of the wiki tools are rather simple. I'm not sure I see the harm in going from scons-contrib -> SCons core directly provided there are tests. Though that brings up another question. Since all the SCons test framework only exists in the core repo, in what form should tests for contributed code exist? > 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. > > Just my 2 cents. > > Best regards, > > Dirk > > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Repo not wiki for tools and add-ons
Hi, On 04.07.2015 20:46, Russel Winder wrote: On Sat, 2015-07-04 at 13:17 -0400, Bill Deegan wrote: Russel, I've created: https://bitbucket.org/scons/scons-contrib/admin/access thanks a lot for creating this Bill. [...] Would it be worth having 3 base dirs: tools scripts docs ? 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... Or just have tools live in the root of the repo? I think idea of having tools as a sub-heirarchy is fitting and gives most flexibility. Indeed I wonder if we go with this, we have had sufficient debate on structure to begin to act. We do perhaps need to have criteria for accepting new tools, and ejecting current tools. I have a few Mercurial repositories on BitBucket that are immediate candidates, but the question is whether they are ready or whether they would be better staying separate for now. Clearly I could put them all in but would that be the right thing to do just now? 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: Wiki snippet -> scons-contrib -> external Tool (own repo) -> SCons core 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. Just my 2 cents. Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
