Re: [OpenBabel-Devel] Release Schedule

[Maciek Wójcikowski]

Hi all,

Unfortunately I'm on holiday for the next two weeks, and away from any
laptop, so I can't help. After September 20th I'm all in for the new
release, if you need help then.


Pozdrawiam,  |  Best regards,
Maciek Wójcikowski
mac...@wojcikowski.pl


pt., 6 wrz 2019 o 20:35 Geoffrey Hutchison 
napisał(a):

> With this in mind, I'm going to suggest that we feature freeze and focus
> on release blockers. We shouldn't be dogmatic (e.g. I note that I have
> already agreed to review/merge David Koes mega PR) but we should try to
> avoid making the documentation out-of-date during the release procedure. If
> everything gets super automated, it will not be difficult to do another
> point release in 3 or 6 months so no-one should panic that their work will
> have to wait for another 3 years.
>
>
> This point is critical. While much of the work in 3.0 by Noel involved
> API-breaking changes, we have a large number of new contributions in the
> works - and should start to build a 6 month release schedule. I don't
> advocate moving to dated versions, but September / October and March /
> April are often good months.
>
> So if people want to help we will need testers for the conda packages, the
> snap packages, the Python binaries, etc., etc. Does it build on Ubuntu?
> Does it build on Arch? Help updating the documentation would be much
> appreciated - you can do this directly on the github repo. If you want to
> help but don't know how/where, just email the list - there are many things
> that we would do if we had more time, so don't hold back.
>
>
> Two things that people can help work on:
> - Tips for migrating Python and C++ code (
> https://open-babel.readthedocs.io/en/latest/UseTheLibrary/migration.html)
> - Release documentation (
> https://open-babel.readthedocs.io/en/latest/ReleaseNotes/ob300.html)
>
> In particular, if you've migrated code or scripts and encountered things,
> please add comments or examples to the migration list.
>
> If you've added something that should be a "headline" component of the
> release notes (e.g., the new fragment-based 3D coordinate generation) those
> would be good to highlight too.
>
> The docs are on GitHub;
> https://github.com/openbabel/documentation
>
> -Geoff
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Release Schedule

[Geoffrey Hutchison]

> With this in mind, I'm going to suggest that we feature freeze and focus on 
> release blockers. We shouldn't be dogmatic (e.g. I note that I have already 
> agreed to review/merge David Koes mega PR) but we should try to avoid making 
> the documentation out-of-date during the release procedure. If everything 
> gets super automated, it will not be difficult to do another point release in 
> 3 or 6 months so no-one should panic that their work will have to wait for 
> another 3 years.

This point is critical. While much of the work in 3.0 by Noel involved 
API-breaking changes, we have a large number of new contributions in the works 
- and should start to build a 6 month release schedule. I don't advocate moving 
to dated versions, but September / October and March / April are often good 
months.

> So if people want to help we will need testers for the conda packages, the 
> snap packages, the Python binaries, etc., etc. Does it build on Ubuntu? Does 
> it build on Arch? Help updating the documentation would be much appreciated - 
> you can do this directly on the github repo. If you want to help but don't 
> know how/where, just email the list - there are many things that we would do 
> if we had more time, so don't hold back.

Two things that people can help work on:
- Tips for migrating Python and C++ code 
(https://open-babel.readthedocs.io/en/latest/UseTheLibrary/migration.html 
)
- Release documentation 
(https://open-babel.readthedocs.io/en/latest/ReleaseNotes/ob300.html 
)

In particular, if you've migrated code or scripts and encountered things, 
please add comments or examples to the migration list.

If you've added something that should be a "headline" component of the release 
notes (e.g., the new fragment-based 3D coordinate generation) those would be 
good to highlight too.

The docs are on GitHub;
https://github.com/openbabel/documentation 


-Geoff___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Release Schedule

[Geoffrey Hutchison]

> Hi Noel - I'd be happy to put together some Docker recipes for the most 
> important platforms and all their versions OpenBabel is supposed to support.  
> If that's done then anyone with docker installed on their machine could just 
> run single commands to confirm that OpenBabel builds and tests pass on each 
> platform with the appropriate dependencies.  Does that sound like something 
> you'd be interested in?

That would be great. GitHub seems to be pushing their new "actions" 
infrastructure which would use Docker to build / test on Mac, Windows, and 
Linux distros.

There's also some benefit towards being able to generate release packages for 
multiple platforms.

Thanks!
-Geoff

___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Release Schedule

[Noel O'Boyle]

Absolutely. That'd be great. I'll make a new repo for all distribution (and
maintenance) related scripts/recipes (if there isn't already one) so that
we have them all in one place.

On Fri, 6 Sep 2019 at 14:53, Patrick Lorton  wrote:

> Hi Noel - I'd be happy to put together some Docker recipes for the most
> important platforms and all their versions OpenBabel is supposed to
> support.  If that's done then anyone with docker installed on their machine
> could just run single commands to confirm that OpenBabel builds and tests
> pass on each platform with the appropriate dependencies.  Does that sound
> like something you'd be interested in?
>
> As an example, I have a recipe here for RDKit+GPUSim on Ubuntu with Cuda
> drivers:
> https://github.com/schrodinger/gpusimilarity/blob/master/docker/Dockerfile
>
> That pulls down RDKit and builds it on Ubuntu - in this case to be used
> with GPUSim, but you can see it'd be trivial to just run the tests at the
> end.  This is how I guarantee my changes on GPUSim are working on Ubuntu
> (the most popular platform for it) even when I do all my dev on Arch.
>
> Pat
>
> On Fri, Sep 6, 2019 at 9:27 AM Noel O'Boyle  wrote:
>
>> Hi all,
>>
>> Geoff asked me to bring up the discussion of a release schedule for OB
>> 3.0. It's been so long since the last release, that it's become painful for
>> us to do a release, which is a bit of a vicious cycle as you can imagine.
>> So
>>
>> I have some time to do this now (with help I hope!) so I'm going to
>> randomly suggest that every Friday until finished, we do a release. Every
>> Monday morning, I'll bump the version and tag that git revision, and
>> between then and end of Friday we'll try and get all parts of the release
>> done.
>>
>> So next Friday we do a release - it might be 3.0a, and the release notes
>> out of date, Python 2 unsupported and conda only working on Linux. And the
>> following Friday - it might be 3.0a2, but most parts of the release have
>> been automated and updated. And so on, until we have 3.0 - the goal is the
>> last Friday of September.
>>
>> The reason we need to do this is that we need to start oiling our release
>> procedures, and get things automated (as much as possible). Get release
>> scripts together - check them in somewhere - and make it so that creating a
>> release is not painful. Frequent releases are a great spur to doing this
>> even if only alpha releases.
>>
>> With this in mind, I'm going to suggest that we feature freeze and focus
>> on release blockers. We shouldn't be dogmatic (e.g. I note that I have
>> already agreed to review/merge David Koes mega PR) but we should try to
>> avoid making the documentation out-of-date during the release procedure. If
>> everything gets super automated, it will not be difficult to do another
>> point release in 3 or 6 months so no-one should panic that their work will
>> have to wait for another 3 years.
>>
>> So if people want to help we will need testers for the conda packages,
>> the snap packages, the Python binaries, etc., etc. Does it build on Ubuntu?
>> Does it build on Arch? Help updating the documentation would be much
>> appreciated - you can do this directly on the github repo. If you want to
>> help but don't know how/where, just email the list - there are many things
>> that we would do if we had more time, so don't hold back.
>>
>> Geoff - does this sound reasonable? I can send to openbabel-discuss also
>> if it's okay.
>>
>> Regards,
>>Noel
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Release Schedule

[Patrick Lorton]

Hi Noel - I'd be happy to put together some Docker recipes for the most
important platforms and all their versions OpenBabel is supposed to
support.  If that's done then anyone with docker installed on their machine
could just run single commands to confirm that OpenBabel builds and tests
pass on each platform with the appropriate dependencies.  Does that sound
like something you'd be interested in?

As an example, I have a recipe here for RDKit+GPUSim on Ubuntu with Cuda
drivers:
https://github.com/schrodinger/gpusimilarity/blob/master/docker/Dockerfile

That pulls down RDKit and builds it on Ubuntu - in this case to be used
with GPUSim, but you can see it'd be trivial to just run the tests at the
end.  This is how I guarantee my changes on GPUSim are working on Ubuntu
(the most popular platform for it) even when I do all my dev on Arch.

Pat

On Fri, Sep 6, 2019 at 9:27 AM Noel O'Boyle  wrote:

> Hi all,
>
> Geoff asked me to bring up the discussion of a release schedule for OB
> 3.0. It's been so long since the last release, that it's become painful for
> us to do a release, which is a bit of a vicious cycle as you can imagine.
> So
>
> I have some time to do this now (with help I hope!) so I'm going to
> randomly suggest that every Friday until finished, we do a release. Every
> Monday morning, I'll bump the version and tag that git revision, and
> between then and end of Friday we'll try and get all parts of the release
> done.
>
> So next Friday we do a release - it might be 3.0a, and the release notes
> out of date, Python 2 unsupported and conda only working on Linux. And the
> following Friday - it might be 3.0a2, but most parts of the release have
> been automated and updated. And so on, until we have 3.0 - the goal is the
> last Friday of September.
>
> The reason we need to do this is that we need to start oiling our release
> procedures, and get things automated (as much as possible). Get release
> scripts together - check them in somewhere - and make it so that creating a
> release is not painful. Frequent releases are a great spur to doing this
> even if only alpha releases.
>
> With this in mind, I'm going to suggest that we feature freeze and focus
> on release blockers. We shouldn't be dogmatic (e.g. I note that I have
> already agreed to review/merge David Koes mega PR) but we should try to
> avoid making the documentation out-of-date during the release procedure. If
> everything gets super automated, it will not be difficult to do another
> point release in 3 or 6 months so no-one should panic that their work will
> have to wait for another 3 years.
>
> So if people want to help we will need testers for the conda packages, the
> snap packages, the Python binaries, etc., etc. Does it build on Ubuntu?
> Does it build on Arch? Help updating the documentation would be much
> appreciated - you can do this directly on the github repo. If you want to
> help but don't know how/where, just email the list - there are many things
> that we would do if we had more time, so don't hold back.
>
> Geoff - does this sound reasonable? I can send to openbabel-discuss also
> if it's okay.
>
> Regards,
>Noel
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Release Schedule

[Noel O'Boyle]

Hi all,

Geoff asked me to bring up the discussion of a release schedule for OB 3.0.
It's been so long since the last release, that it's become painful for us
to do a release, which is a bit of a vicious cycle as you can imagine.
So

I have some time to do this now (with help I hope!) so I'm going to
randomly suggest that every Friday until finished, we do a release. Every
Monday morning, I'll bump the version and tag that git revision, and
between then and end of Friday we'll try and get all parts of the release
done.

So next Friday we do a release - it might be 3.0a, and the release notes
out of date, Python 2 unsupported and conda only working on Linux. And the
following Friday - it might be 3.0a2, but most parts of the release have
been automated and updated. And so on, until we have 3.0 - the goal is the
last Friday of September.

The reason we need to do this is that we need to start oiling our release
procedures, and get things automated (as much as possible). Get release
scripts together - check them in somewhere - and make it so that creating a
release is not painful. Frequent releases are a great spur to doing this
even if only alpha releases.

With this in mind, I'm going to suggest that we feature freeze and focus on
release blockers. We shouldn't be dogmatic (e.g. I note that I have already
agreed to review/merge David Koes mega PR) but we should try to avoid
making the documentation out-of-date during the release procedure. If
everything gets super automated, it will not be difficult to do another
point release in 3 or 6 months so no-one should panic that their work will
have to wait for another 3 years.

So if people want to help we will need testers for the conda packages, the
snap packages, the Python binaries, etc., etc. Does it build on Ubuntu?
Does it build on Arch? Help updating the documentation would be much
appreciated - you can do this directly on the github repo. If you want to
help but don't know how/where, just email the list - there are many things
that we would do if we had more time, so don't hold back.

Geoff - does this sound reasonable? I can send to openbabel-discuss also if
it's okay.

Regards,
   Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel