DBD::Oracle 1.29
Yanick
I'm beginning to filter through the RT bugs and see how can pan out
for the future. But before we can address the far future, there's the
upcoming 1.29 release.
From what I understand, Martin and John are well on their way to
finish the RC for that release. Do any of you gentlemen have an idea
of how much work need to be done before we can cut the first RC?
Joy,
`/anick
Martin J. Evans
From my side I am snowed under with a lot of work in other areas $work
and other open source work. I've got a load of pod fixes and reworking
but I'm waiting for John to merge his many TAF changes etc into trunk
then I'll apply them (just to minimise his work as he has done the bulk
of the changes since the last release).
I also have applied the patch in
https://rt.cpan.org/Public/Bug/Display.html?id=67942 into my branch and
it does not seem to hurt.
John has already commented on
https://rt.cpan.org/Public/Bug/Display.html?id=13865 but I'm not sure
where we are with it right now.
https://rt.cpan.org/Public/Bug/Display.html?id=56824 will be fixed if
the META.yml is regenerated in the next release as I've already applied
the fix.
https://rt.cpan.org/Public/Bug/Display.html?id=67315 can probably be
closed as it is reported as a DBI issue now.
https://rt.cpan.org/Public/Bug/Display.html?id=67272 should be fixed in
the next release if the META.yml is generated properly.
I know John has many changes in his branch including TAF support.
I feel very strongly that a development 1.29_1 release should be done to
CPAN when this work is completed. That may lead to a few other
development releases but ultimately to a final 1.30 official release. I
cannot comment as to when we could release 1.29_1 as the stuff I have
could be applied in less than an hour but John has much more work. I'd
also like to suggest any development/official release is circulated
amongst us before uploading to CPAN.
As an aside, I'm not that bothered about using the google group for
DBD::Oracle. Any Oracle-specific issues which are of no dbi-dev interest
can happily be circulated between ourselves but anything else is better
on dbi-dev AFAIAC as a) there is a wider, knowledgeable audience on it
and b) it is pretty low volume anyway.
I have no basic objection to github but the level of patches received is
so low I doubt there is much to gain from it. If you are working on
something like DBIx::Class with dozens of contributors it helps but that
isn't really the case with DBD::Oracle.
I have to admit that right now I've got a lot of irons in the fire and
no much time to allocate to DBD::Oracle but I'm always happy to watch
the rt queue and test any potential changes with the various Oracles we
have here.
Martin
--
Martin J. Evans
Wetherby, UK
Yanick Champoux
On 05/06/11 14:20, Martin J. Evans wrote:
> From my side I am snowed under with a lot of work in other areas $work
> and other open source work.
Heh. I think I can relate to that. :-)
> I've got a load of pod fixes and reworking but I'm waiting for John to
> merge his many TAF changes etc into trunk then I'll apply them (just
> to minimise his work as he has done the bulk of the changes since the
> last release).
Gotcha.
> I also have applied the patch in
> https://rt.cpan.org/Public/Bug/Display.html?id=67942 into my branch
> and it does not seem to hurt.
Ah, excellent. I'll update the ticket with the info. I was playing
with it myself. It's indeed a small one with a low probability of
backfiring. :-)
>
> John has already commented on
> https://rt.cpan.org/Public/Bug/Display.html?id=13865 but I'm not sure
> where we are with it right now.
Actually, that was me. I've looked at the code, and the patch
shouldn't be too esoteric. I just have to confirm with peeps with more
Oracle insight if the change makes sense.
>
> https://rt.cpan.org/Public/Bug/Display.html?id=56824 will be fixed if
> the META.yml is regenerated in the next release as I've already
> applied the fix.
Yup, that's going to be a freebie.
>
> https://rt.cpan.org/Public/Bug/Display.html?id=67315 can probably be
> closed as it is reported as a DBI issue now.
I'll keep it open until DBI is fixed, just so that we can re-test
it and make sure the dragon is indeed slain.
>
> https://rt.cpan.org/Public/Bug/Display.html?id=67272 should be fixed
> in the next release if the META.yml is generated properly.
Yup. Excellent.
> I feel very strongly that a development 1.29_1 release should be done
> to CPAN when this work is completed. That may lead to a few other
> development releases but ultimately to a final 1.30 official release.
> I cannot comment as to when we could release 1.29_1 as the stuff I
> have could be applied in less than an hour but John has much more work.
Okay. We'll wait for John's saying on his side of things. If
possible, I want a to set a predictable and consistent release cycle so
that we can keep the small fixes flowing, and still don't drive
ourselves mad with the bigger features.
> I'd also like to suggest any development/official release is
> circulated amongst us before uploading to CPAN.
Absolutely. Not only we all need the peer reviews, but we can use
all the DBD::Oracle test installs we can get. ;-)
> As an aside, I'm not that bothered about using the google group for
> DBD::Oracle. Any Oracle-specific issues which are of no dbi-dev
> interest can happily be circulated between ourselves but anything else
> is better on dbi-dev AFAIAC as a) there is a wider, knowledgeable
> audience on it and b) it is pretty low volume anyway.
True, and anything of greater general interest should absolutely be
discussed on dbi-dev. But there are a few keen potential new
contributors who are very good with all things Oracle, but are fairly
new to Perl and/or VCSes. So instead of polluting the greater mailing
list with "how do I create a svn branch", I went ahead and preemptively
created this list. And yes, there are enough of them to justify having
a mailing list instead of merely cc'ing the whole group.
> I have no basic objection to github but the level of patches received
> is so low I doubt there is much to gain from it.
From my experience, lowering the hurdle to create patches has
always attracted a few useful contributions to projects. And since the
conversion to Git was already pretty much for free as I use Git as my
svn client anyway, I didn't see any downside to doing it either.
> I have to admit that right now I've got a lot of irons in the fire and
> no much time to allocate to DBD::Oracle but I'm always happy to watch
> the rt queue and test any potential changes with the various Oracles
> we have here.
Well, as I said above, that's more than fair enough. :-)
Joy,
`/anick