Thanks for the advice. Trying to make a contribution is why I'm here.
That's why I worry about version control systems. Last time I tried
to contribute to an open source project via a "semi-official
mirror" (this one actually run by a core developer) it did not work
and I ended up having to resubmit the work to CVS. I now have commit
permission on that project (pywin32) so it's no longer a problem.
Jacob seemed to be suggesting a single dvcs ("THE branch") so I
thought I would weigh in on the choice. Sorry I missed the discussion
two years ago.
Meanwhile, I suppose I must stick with svn if I expect to have my
work accepted, because my contribution will very likely be
controversial, and I prefer to only fight one battle at a time. On
the other hand, getting some test time in a less critical environment
would be a really good thing, and would increase the chances of my
work having a good examination by other developers.
Umm -- time to explain:
I am the principle maintainer of adodbapi on sourceforge. I have
spent the last little while making adodbapi django compatible. (The
new version allows the programmer to change 'paramstyle' at run time.)
The existing MS-SQL back end for django is a fork taken from the
adodbapi project *before* it was changed to be ready for Python 3 and/
or IronPython. The alpha-test version now running will operate in all
three environments -- and should be a real aide to both the IronPython
and Python 3 django integration projects which are now under way. It
should be a fairly minor change to the existing MS-SQL back end to use
the (new) trunk version of adodbapi rather than the fork.
That's not controversial -- here comes the controversy:
There is finally a solid release of IronPython 2.n available for
Linux. (Ubuntu Lucid). The existing adodbapi will not work there, due
to lack of a COM interface. I now have to put in genuine .NET calls
to reach the database. I started working on that project yesterday.
When I am done the result will be that django on IronPython (or Python
3?) will be able to use *only* MS-SQL or SQLite databases. Not a
pretty picture. In order to access other database engines, the engine
specific code for all of the other database engines will have to be
modified to fall back to ADO when their native adapters are not
present. That's a lot of fixing of things that are not broken. I
think the final result will be a version of django which is a lot more
flexible, but it's gonna be a hard sell.
--
Vernon
On Apr 19, 8:05 pm, "Sean O'Connor" <sean.b.ocon...@gmail.com> wrote:
> The DVCS conversation has been had many times over the last year or two on
> this list and in other places. I mention this not to say that you should
> know already as it isn't clearly documented, but as a suggestion that you
> should make sure that you are bringing something new and concrete to the
> discussion before starting it again.
>
> The current view of the core team is that the combination of a central,
> authoritative, Subversion server with semi-official mirrors for Git,
> Mercurial, and Bazaar is sufficient for the foreseeable future. All of the
> benefits of the distributed systems are available via the mirrors and
> there's no disruption to users who are used to the current
> workflow/infrastructure.
>
> If you would like to make a contribution to Django, you can work with
> whichever of the three most common DVCSs and there will be several core devs
> able to accept your changes without any problems.
>
> ____________________________
> Sean O'Connorhttp://seanoc.com
>
> P.S. I am not a core dev so any of the core devs should feel free to
> correct me on this. That being said this view has been clearly expressed
> several times on this list and in other venues.
>
>
>
> On Mon, Apr 19, 2010 at 8:35 PM, Jerome Leclanche <adys...@gmail.com> wrote:
> > If you contribute to open source projects, at one point you'll be
> > faced with the forced choice to use git. It is extremely popular (I
> > believe it's the most popular after svn), and unlike svn it's popular
> > for a good reason.
> > However, hg is decent as well; whatever the django team chooses, as
> > long as it's not cvs it can't really be worse than svn.
>
> > (bzr fan, personally, but I'd prefer it if django moved over to git)
>
> > J. Leclanche / Adys
>
> > On Tue, Apr 20, 2010 at 2:58 AM, VernonCole <vernondc...@gmail.com> wrote:
> > > Not to start a flame war --- but PLEASE! don't use git. I already
> > > have to use the other two leading DVCS's and all three are one too
> > > many.
> > > I personally prefer bazaar, but python itself and pywin32 are both
> > > committed to mercurial. I suspect that hg would be a better choice
> > > for most people.
> > > --
> > > Vernon Cole
>
> > > On Apr 19, 10:05 am, Dennis Kaarsemaker <den...@kaarsemaker.net>
> > > wrote:
> > >> On ma, 2010-04-19 at 15:47 +0000, Peter Landry wrote:
>
> > >> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> wrote:
>
> > >> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry <plan...@provplan.org>
> > wrote:
> > >> > >> One suggestion that jumped out at me (which I admittedly know very
> > little
> > >> > >> history about with regards to Django or other projects) was the
> > "trunk
> > >> > >> ready" branch(es) [1]. Perhaps an effort to outline what that
> > process might
> > >> > >> entail in detail, to determine if it would address any concerns?
>
> > >> > > FTR, I think this is a fine idea, and I think most (all?) of the
> > other
> > >> > > Django core developers do, too. It's just waiting on someone to Just
> > >> > > Do It.
>
> > >> > > Anyone -- preferably a group -- who wants to start such a branch
> > could
> > >> > > go ahead and start one using the DVCS tool of their choice (Django
> > has
> > >> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me
> > and
> > >> > > I'll start watching it; show some continued motion and I'll spend
> > some
> > >> > > time getting a buildbot going against the branch; show high quality
> > >> > > and I'll start pulling from it more and more frequently; show
> > >> > > incredibly quality and I'll suggest that the maintainer(s) get
> > commit.
>
> > >> > >> For my part, I see that it could be helpful to let some
> > patches/ideas get a
> > >> > >> shot at integration without having to endure the (necessarily) more
> > rigorous
> > >> > >> core commit trails.
>
> > >> > > Quality is important, and if this branch is created it needs to
> > >> > > maintain that quality. If this hypothetical branch is low-quality
> > it's
> > >> > > just a different tool for a queue of un-reviewed patches, and I've
> > >> > > already got one of those. I'm not willing to compromise on quality:
> > if
> > >> > > patches don't meet our standards, they don't go in.
>
> > >> > > Jacob
>
> > >> > I fully agree regarding quality, my point being that this branch
> > itself may
> > >> > not be "trunk ready" at any given time, but patches/pulls from it
> > would be;
> > >> > quality of patches would obviously need to meet existing standards.
> > Perhaps
> > >> > that distinction isn't helpful, necessary, or desirable.
>
> > >> I've been thinking of starting a proper contribution in django in a
> > >> similar way: a github repo with per-ticket branches that are trunk-ready
> > >> and regularly updated (rebased) against trunk until they are applied.
>
> > >> So far I've only done so for a pony of mine as a test, but as soon as
> > >> the ash cloud clears, I will look at existing tickets. Would this
> > >> approach be useful for core committers to pull patches from?
>
> > >> --
> > >> Dennis K.
>
> > >> They've gone to plaid!
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups "Django developers" group.
> > >> To post to this group, send email to django-developers@googlegroups.com
> > .
> > >> To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> > .
> > >> For more options, visit this group athttp://
> > groups.google.com/group/django-developers?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > > To post to this group, send email to django-develop...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group
> athttp://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
