Re: [python-win32] Bug reporting

[Bob Kline]

On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole  wrote:

> Sounds like a good plan.

As in, "yes, let's consolidate the project in one place (under pywin
on GitHub)"? Or did you mean "yes, I agree we should have the
discussion about whether we have to maintain the package in more than
one place"? If the former, I'll be happy to get the ball rolling by
starting the analysis for topping up the GitHub repo from the
SourceForge oledbapi repo. If the latter, I guess the first step in
that discussion would be for you to lay out the reason(s) why it
wouldn't work to maintain the project just on GitHub (under pywin). Or
perhaps you intended some third interpretation of "good plan."

Cheers,
Bob

>
> On Feb 19, 2018 04:57, "Bob Kline"  wrote:
>>
>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole 
>> 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:bkl...@rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

[Vernon D. Cole]

Sounds like a good plan.

On Feb 19, 2018 04:57, "Bob Kline"  wrote:

> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole 
> 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:bkl...@rksystems.com
>
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32