cclib-devel Mailing List for cclib (Page 9)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On Dec 31 2013, Noel O'Boyle wrote:
> Great.
> 
> Good idea about the data files. It will highlight their existence if
> we put them on github. Will there be any problem with the size of the
> repo though?

Not at this point: https://help.github.com/articles/what-is-my-disk-quota
Also, I uncompressed all the files, since their then easier to work with,
and git compresses the files anyway. The whole repo is still about 260MB now,
which is well below the 1GB limit github set. I don't expect this to grow
too quickly. It's not too often that a really large file is needed to reproduce
a parsing error.

> I guess that rather than using wget, we should use "git pull" to keep
> in synch. I was going to suggest that the data files be a submodule (I
> don't have any experience with these though) but it's probably better
> not to force people to download 100s of MB of data just to contribute
> to the project. Or is it? I'll leave it to you - we can review this
> down the line when we see how it works.

Definitely this should always be in a separate repository, so that we can
keep the core of cclib manageable. Also, we can always delete cclib-data
and recreate it from scratch if things get realy bad.

I have experience with git submodules as well subtrees, but I don't think
any are really needed here. We just need to put 'git clone/pull' in a script,
as you suggest, and the appropriate paths in gitignore.

- Karol

> On 31 December 2013 14:12, Karol M. Langner <kar...@gm...> wrote:
> > OK, I'm on board with that. Accordingly, I restricted read access to admins, too. We should
> > probably put up some sort of message that points to github.
> >
> > It would also make sense to move the regression files. I craeted a cclib-data repository for
> > that and will add the files to that (but need to update the test scripts a bit, I think).
> >
> > Cheers,
> > Karol
> >
> > On Dec 31 2013, Noel O'Boyle wrote:
> >> I'm all for a clean break. Down with the old, and up with the new. The
> >> web (and people) will soon route around the change. If you leave
> >> anything there of the old, I think it actually makes the transition
> >> slower.
> >>
> >> - Noel
> >>
> >> On 30 December 2013 23:14, Karol M. Langner <kar...@gm...> wrote:
> >> > Yes, of course. My only concern is that people that already use cclib
> >> > will go to the SVN and not see any future commits.
> >> >
> >> > On Dec 30 2013, Adam Tenderholt wrote:
> >> >> I don't see any reason to maintain the SVN repo. Anyone comfortable enough
> >> >> with SVN has probably heard about github at this point.
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Dec 30, 2013 at 9:26 AM, Noel O'Boyle <bao...@gm...> wrote:
> >> >>
> >> >> > I'm not crazy about maintaining the original repo. We want to point
> >> >> > people to github rather than subversion, but maintaining the old repo
> >> >> > will divide attention don't you think?
> >> >> >
> >> >> > - Noel
> >> >> >
> >> >> > On 30 December 2013 14:26, Karol M. Langner <kar...@gm...>
> >> >> > wrote:
> >> >> > > Thanks Noel! I guess you covered all the active branches... the others
> >> >> > ones were deleted (I thought)
> >> >> > > after merging into trunk.
> >> >> > >
> >> >> > > I think it would be nice to automatically push new commits (at least on
> >> >> > master) back to trunk at sourceforge,
> >> >> > > in a hook or something. Do you know whether git-svn works for that sort
> >> >> > of thing?
> >> >> > >
> >> >> > > - Karol
> >> >> > >
> >> >> > > On Dec 30 2013, Noel O'Boyle wrote:
> >> >> > >> I've svn2gitted everything. It seemed to work okay. The only question
> >> >> > >> is which dev branches do we need:
> >> >> > >>
> >> >> > >>   cbridge
> >> >> > >>   cclib-0.5-prerelease
> >> >> > >>   cclib-0.6
> >> >> > >>   cclib-0.7
> >> >> > >>   cclib-0.8
> >> >> > >>   cclib-0.9
> >> >> > >>   cclib-1.0.1
> >> >> > >>   cclib-1.0b
> >> >> > >>   cclib-1.1
> >> >> > >>   handlezip
> >> >> > >> * master
> >> >> > >>   molcas
> >> >> > >>   molpro
> >> >> > >>   nwchem
> >> >> > >>   orca
> >> >> > >>   parser-refactoring
> >> >> > >>   python2
> >> >> > >>   python3
> >> >> > >>   turbomoleparser
> >> >> > >>
> >> >> > >> I've moved the following to git: master, cbridge, cclib-1.1, molcas,
> >> >> > >> molpro, nwchem, python2, turbomoleparser.
> >> >> > >>
> >> >> > >> Let me know if you want me to copy another branch over.
> >> >> > >>
> >> >> > >> Regarding workflow, the tidiest way would be to do all your work on a
> >> >> > >> branch of your own fork of the repo, then click on github to send a
> >> >> > >> pull request, and then either merge it yourself on github, or email
> >> >> > >> the list asking for a code review. What do you think? We should all
> >> >> > >> get an email when the pull request arrives, and if you want you can
> >> >> > >> wait a day or two to see whether someone else leaves a comment before
> >> >> > >> merging.
> >> >> > >>
> >> >> > >> - Noel
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> On 30 December 2013 01:13, Karol M. Langner <kar...@gm...>
> >> >> > wrote:
> >> >> > >> > For the interim I removed all write permissions on Sourceforge.
> >> >> > >> >
> >> >> > >> > On Dec 29 2013, Adam Tenderholt wrote:
> >> >> > >> >> Hi Noel and others,
> >> >> > >> >>
> >> >> > >> >> I think moving cclib development to Github is a great idea. Let me
> >> >> > know if
> >> >> > >> >> there is anything I can do to help.
> >> >> > >> >>
> >> >> > >> >> Adam
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> >> On Sun, Dec 29, 2013 at 1:42 PM, Noel O'Boyle <bao...@gm...>
> >> >> > wrote:
> >> >> > >> >>
> >> >> > >> >> > Let's move to git on github. Adam are you okay with this?
> >> >> > >> >> >
> >> >> > >> >> > Moving to github for Open Babel has meant a lot more commits from
> >> >> > 3rd
> >> >> > >> >> > parties. I think cclib might benefit here also as it's so easy for
> >> >> > >> >> > someone just to patch their fork and send a pull request. I'm on
> >> >> > the
> >> >> > >> >> > record as not liking using git too much, but if I can survive
> >> >> > doing it
> >> >> > >> >> > for Open Babel I can do it for cclib too.
> >> >> > >> >> >
> >> >> > >> >> > I will set up a cclib organisation there with all of us on it, and
> >> >> > see
> >> >> > >> >> > whether I can import everything with full history. If this works
> >> >> > out,
> >> >> > >> >> > Karol, you should probably delete your current cclib repo and fork
> >> >> > >> >> > this instead.
> >> >> > >> >> >
> >> >> > >> >> > Regarding one of your points, it's github not just git that is key
> >> >> > >> >> > here, so I don't think SF's git is really an option. Regarding the
> >> >> > >> >> > other points on SF versus github, let's think about those later as
> >> >> > >> >> > this move is largely independent (apart from the bug tracker).
> >> >> > >> >> >
> >> >> > >> >> > - Noel
> >> >> > >> >> >
> >> >> > >> >> > On 29 December 2013 05:58, Karol M. Langner <
> >> >> > kar...@gm...>
> >> >> > >> >> > wrote:
> >> >> > >> >> > > Hi Noel,
> >> >> > >> >> > >
> >> >> > >> >> > > It seems that Sourceforge actually now supports git
> >> >> > repositories, if we
> >> >> > >> >> > wanted to convert and stay there.
> >> >> > >> >> > > The way to do it is to 'add' a git repository by adding the
> >> >> > appropriate
> >> >> > >> >> > 'app' in the admin panel,
> >> >> > >> >> > > which creates an empty repository. The svn tree can then be
> >> >> > converted to
> >> >> > >> >> > git and pushed to that.
> >> >> > >> >> > >
> >> >> > >> >> > > I don't think we could resaonably use both repositories for
> >> >> > development,
> >> >> > >> >> > so one would need to be
> >> >> > >> >> > > read-only, and I think we should keep the svn repo online for
> >> >> > users that
> >> >> > >> >> > have that set up.
> >> >> > >> >> > >
> >> >> > >> >> > > Meanwhile, to start off I pushed the trunk to a repostiory on
> >> >> > github:
> >> >> > >> >> > https://github.com/langner/cclib
> >> >> > >> >> > > I will keep this up to date and would be in favor of moving
> >> >> > mostly to
> >> >> > >> >> > github in the future.
> >> >> > >> >> > > If we went that route, I suppose the sf repo would be read-only.
> >> >> > >> >> > Additional things things to consider:
> >> >> > >> >> > > - what to do with current wiki / web page
> >> >> > >> >> > > - what to do with current branches
> >> >> > >> >> > > - what to do with previous releases/tags
> >> >> > >> >> > > - what to do with current and old issues in the tracker
> >> >> > >> >> > > - what to do with mailing lists
> >> >> > >> >> > >
> >> >> > >> >> > > What do you think? I believe you did something similar for
> >> >> > OpenBabel at
> >> >> > >> >> > some point. How did that work?
> >> >> > >> >> > >
> >> >> > >> >> > > Cheers,
> >> >> > >> >> > > Karol
> >> >> > >> >> > >
> >> >> > >> >> > > On Nov 08 2013, Karol M. Langner wrote:
> >> >> > >> >> > >> Hi guys,
> >> >> > >> >> > >>
> >> >> > >> >> > >> Nice to see this. And Clyde -- nice project!
> >> >> > >> >> > >>
> >> >> > >> >> > >> Noel, how recently have you looked at the github interface for
> >> >> > Windows?
> >> >> > >> >> > If I rememeber
> >> >> > >> >> > >> correctly, several weeks ago they made some significant
> >> >> > improvements.
> >> >> > >> >> > >>
> >> >> > >> >> > >> I don't know about mercurial, but they do support svn now.
> >> >> > >> >> > >>
> >> >> > >> >> > >> Before moving to github, however, we could set up an "official"
> >> >> > fork --
> >> >> > >> >> > I'd be happy to do it,
> >> >> > >> >> > >> and try to suck in Clyde's contribution via that. BTW, I'm +1
> >> >> > on moving
> >> >> > >> >> > to git. I always struggle
> >> >> > >> >> > >> with the sourceforge svn tools.
> >> >> > >> >> > >>
> >> >> > >> >> > >> - Karol
> >> >> > >> >> > >>
> >> >> > >> >> > >> On Nov 08 2013, Noel O'Boyle wrote:
> >> >> > >> >> > >> > (ccing to the list)
> >> >> > >> >> > >> >
> >> >> > >> >> > >> > Hi Clyde,
> >> >> > >> >> > >> >
> >> >> > >> >> > >> > Thanks for letting me know. You're free to do this of course
> >> >> > - might
> >> >> > >> >> > >> > be good to make it clear that this is an "unofficial" fork
> >> >> > though.
> >> >> > >> >> > >> > Just to save people contacting us asking about ASE.
> >> >> > >> >> > >> >
> >> >> > >> >> > >> > Naturally for us we would prefer if you contribute any fixes
> >> >> > directly
> >> >> > >> >> > >> > to cclib. In this case, if any of our units are incorrect we
> >> >> > would
> >> >> > >> >> > >> > like to fix our source.
> >> >> > >> >> > >> >
> >> >> > >> >> > >> > This might be the push we need to consider moving to Github.
> >> >> > Git on
> >> >> > >> >> > >> > Windows though is a joke. The interface is not a lot better
> >> >> > than the
> >> >> > >> >> > >> > old CVS one (you probably don't remember this) which also
> >> >> > used to call
> >> >> > >> >> > >> > out to the command line. If only Github ran mercurial...:-/
> >> >> > >> >> > >> >
> >> >> > >> >> > >> > - Noel
> >> >> > >> >> > >> >
> >> >> > >> >> > >> >
> >> >> > >> >> > >> >
> >> >> > >> >> > >> > On 7 November 2013 15:05, Clyde Fare <cly...@gm...>
> >> >> > wrote:
> >> >> > >> >> > >> > > Hi Noel
> >> >> > >> >> > >> > >
> >> >> > >> >> > >> > > I've got a git repository with cclib in it because I am
> >> >> > faffing
> >> >> > >> >> > about trying
> >> >> > >> >> > >> > > to put together a bunch of python of tools associated with
> >> >> > quantum
> >> >> > >> >> > chemistry
> >> >> > >> >> > >> > > to use with the ipython notebook. In my version I've
> >> >> > changed the
> >> >> > >> >> > units that
> >> >> > >> >> > >> > > cclib uses in it's conversions because I want the various
> >> >> > parsers I
> >> >> > >> >> > use to
> >> >> > >> >> > >> > > all use the same units.
> >> >> > >> >> > >> > >
> >> >> > >> >> > >> > > As I wanted an easy way of loading the package into
> >> >> > Anaconda I've
> >> >> > >> >> > put the
> >> >> > >> >> > >> > > result on github here:
> >> >> > >> >> > >> > > https://github.com/Clyde-fare/cclib
> >> >> > >> >> > >> > >
> >> >> > >> >> > >> > > Github  have a very fork-me friendly mentality but it
> >> >> > occurred to
> >> >> > >> >> > me that
> >> >> > >> >> > >> > > you might not be so happy that I'd done this so just wanted
> >> >> > to
> >> >> > >> >> > check in with
> >> >> > >> >> > >> > > you - I could write a version that means the units used are
> >> >> > chosen
> >> >> > >> >> > based on
> >> >> > >> >> > >> > > some flag (and your initial units are the default) which
> >> >> > would mean
> >> >> > >> >> > I could
> >> >> > >> >> > >> > > keep my version synced with yours if that's something you
> >> >> > would
> >> >> > >> >> > prefer.
> >> >> > >> >> > >> > >
> >> >> > >> >> > >> > > Cheers
> >> >> > >> >> > >> > >
> >> >> > >> >> > >> > > Clyde
> >> >> > >> >> > >> > >
> >> >> > >> >> > >> >
> >> >> > >> >> > >> >
> >> >> > >> >> >
> >> >> > ------------------------------------------------------------------------------
> >> >> > >> >> > >> > November Webinars for C, C++, Fortran Developers
> >> >> > >> >> > >> > Accelerate application performance with scalable programming
> >> >> > models.
> >> >> > >> >> > Explore
> >> >> > >> >> > >> > techniques for threading, error checking, porting, and
> >> >> > tuning. Get
> >> >> > >> >> > the most
> >> >> > >> >> > >> > from the latest Intel processors and coprocessors. See
> >> >> > abstracts and
> >> >> > >> >> > register
> >> >> > >> >> > >> >
> >> >> > >> >> >
> >> >> > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> >> >> > >> >> > >> > _______________________________________________
> >> >> > >> >> > >> > cclib-devel mailing list
> >> >> > >> >> > >> > ccl...@li...
> >> >> > >> >> > >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >> >> > >> >> > >>
> >> >> > >> >> > >> --
> >> >> > >> >> > >> written by Karol M. Langner
> >> >> > >> >> > >> Fri Nov  8 15:32:34 EST 2013
> >> >> > >> >> > >
> >> >> > >> >> > > --
> >> >> > >> >> > > written by Karol M. Langner
> >> >> > >> >> > > Sun Dec 29 00:39:40 EST 2013
> >> >> > >> >> >
> >> >> > >> >
> >> >> > >> > --
> >> >> > >> > written by Karol M. Langner
> >> >> > >> > Sun Dec 29 20:13:07 EST 2013
> >> >> > >
> >> >> > > --
> >> >> > > written by Karol M. Langner
> >> >> > > Mon Dec 30 09:22:49 EST 2013
> >> >> >
> >> >
> >> > --
> >> > written by Karol M. Langner
> >> > Mon Dec 30 18:10:46 EST 2013
> >
> > --
> > written by Karol M. Langner
> > Tue Dec 31 09:08:17 EST 2013

-- 
written by Karol M. Langner
Tue Dec 31 11:48:53 EST 2013

2006	Jan	Feb	Mar (7)	Apr (30)	May (42)	Jun (24)	Jul (17)	Aug (11)	Sep (37)	Oct (39)	Nov (17)	Dec (10)
2007	Jan (64)	Feb (90)	Mar (89)	Apr (24)	May (23)	Jun (44)	Jul (74)	Aug (40)	Sep (32)	Oct (31)	Nov (27)	Dec
2008	Jan	Feb (7)	Mar (10)	Apr (7)	May (16)	Jun (4)	Jul (8)	Aug	Sep (13)	Oct (6)	Nov	Dec
2009	Jan (1)	Feb (9)	Mar (5)	Apr (6)	May (5)	Jun (13)	Jul (11)	Aug (17)	Sep (3)	Oct (11)	Nov (9)	Dec (15)
2010	Jan (14)	Feb (15)	Mar (10)	Apr (14)	May	Jun (10)	Jul	Aug (12)	Sep (4)	Oct (3)	Nov	Dec (3)
2011	Jan (20)	Feb (7)	Mar (22)	Apr (14)	May (2)	Jun	Jul (13)	Aug (4)	Sep (1)	Oct	Nov (6)	Dec (3)
2012	Jan (7)	Feb (5)	Mar (7)	Apr (23)	May	Jun	Jul (5)	Aug	Sep (2)	Oct (12)	Nov (13)	Dec (3)
2013	Jan (8)	Feb (17)	Mar (3)	Apr	May	Jun	Jul (2)	Aug (5)	Sep (6)	Oct (9)	Nov (5)	Dec (22)
2014	Jan (4)	Feb	Mar	Apr (2)	May	Jun (3)	Jul	Aug (15)	Sep (3)	Oct (1)	Nov (18)	Dec
2015	Jan	Feb	Mar (2)	Apr	May (1)	Jun (1)	Jul	Aug	Sep (7)	Oct	Nov (1)	Dec (1)
2016	Jan (1)	Feb (2)	Mar (3)	Apr (5)	May (3)	Jun (1)	Jul (3)	Aug (1)	Sep	Oct (3)	Nov (11)	Dec (12)
2017	Jan (4)	Feb (7)	Mar	Apr (5)	May (5)	Jun	Jul	Aug (5)	Sep (2)	Oct (3)	Nov (2)	Dec (1)
2018	Jan (1)	Feb (6)	Mar (17)	Apr (8)	May	Jun	Jul (2)	Aug (1)	Sep (1)	Oct	Nov (1)	Dec
2019	Jan (2)	Feb (5)	Mar (18)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb (1)	Mar (2)	Apr	May	Jun (1)	Jul	Aug	Sep	Oct (1)	Nov (1)	Dec
2021	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

cclib-devel Mailing List for cclib (Page 9)

cclib-devel — Developer's mailing list