[python-win32] Bug reporting

[Bob Kline]

On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:

> I will try to clear this up as much as I can...

Thanks very much for your reply, Vernon.

> Adodbapi lives in two places, as a stand-alone project on Sourceforge, and
> integrated with PyWin32.

Well, I wouldn't go so far as saying it "lives" in the GitHub project;
more like it's on life support. :-) As far as I can tell, it's never
actually been usable from that repo, as the required apibase.py file
didn't make it to the party.

> The Sourceforge project is needed for Iron Python, and has more
> documentation, and, originally, a faster upgrade cycle.

I see, however, that the code to support IronPython is in both places,
documentation can easily be enhanced, and (as you acknowledge) the
upgrade cycle for the SourceForge project has gone walkabout. It would
seem ideal (if nothing else, from the perspective of the attempt to
attract more maintainers) if we didn't have to maintain two separate
code bases.

> The SF code was copied to pywin32 for easier installation and more
> convenience, but the file layout is slightly different. I did not have the
> capability to test the pywin32 installation so was unaware of the problem
> until too late. Then I went to work for another company which did not use
> Windows at all, so everything got kind of lost.
>
> The move of pywin32 to GitHub, along with improved testing there will help
> to fix things.  I am also building an SQL server test bench which I hope
> will be permanent. A patch has been submitted to fix the "missing file"
> problem, and I have changed my SF notifications to a different email address
> that I check more frequently.
>
> The python-win project is the preferred maintenance place.

Perhaps a note on the SourceForge page to that effect would be appropriate.

> Meanwhile ... I am not getting any younger and an active back-up maintainer
> for the home adodbapi project would be very welcome if someone were willing
> to help out. At the present moment the "bus size" is one -- which is a bad
> thing.

I'm happy to do what I can, though as I pointed out in an earlier
thread, you're younger than I am. :-)

If you provide instructions for getting the regression tests running,
I'll try to replicate them here.

Let's first decide the question of how many places we're going to
maintain the package. I vote for one (on GitHub). If (for whatever
reason) it's necessary to maintain it in two places, let's (a) decide
whether it's possible to keep the two places synchronized so they
don't drift into forks of each other; (b) figure out how such
synchronization will be accomplished; and most important (c) make it
very clear in both locations what the relationship is between the two
repositories, telling everyone which one should be used in which
situation, where to file issue tracking tickets, etc.

Thanks again for your willingness to bring this project back to life.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com