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-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.

Reply via email to