I'd like to try to reboot the discussion that's been going on about
Django's development process.
I'm finding the current thread incredibly demoralizing: there's a
bunch of frustration being expressed, and I hear that, but I'm having
trouble finding any concrete suggestions. Instead, the thread has
devolved into just going around in circles on the same small handful
of issues.
So: here's your chance. You have suggestions about Django's
development process? Make them. I'm listening.
Jacob
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On 4/19/10 10:19 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> wrote:
> Hi folks --
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
> Jacob
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?
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.
I'm not really comfortable suggesting any concrete plans for how that might
happen though. A single almost-trunk branch? A branch per
lieutenant/component? I'm wary of adding too much bureaucracy and overhead.
I think it's pretty clear that the core Django process is successful, and
this seems like a low impact (though potentially high effort?) way to
involve more of the community.
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
I think that there is frustration on the part of the core dev team because people are (intentionally or not) demanding more and more of their time in the form of feature requests without understanding what the costs are and what resources exist.
There is frustration on the part of some Django users who would like to contribute but feel that anyone not in the core dev team is a third-class citizen with a tiny voice, and think that spending any time working on a ticket is slightly less likely to be worthwhile than writing an iPhone app and hoping Apple approves it for the App Store.
In my opinion, the problem lies not at either end, but in the middle. The way Trac is currently being used allows anyone at all to give tickets a status that the individual may not actually have the understanding to judge. To compensate for this, the core developers are each forced to rely on one another and their own small circle of lieutenants (as Linus does) to know whose code to actually take the time to evaluate.
Ideally, people who want to contribute to Django should be able to adopt any open ticket in the bug tracker, work on it (with any necessary communication with this list), and see their work accepted if it's done well. At present this is not the case.
A potential solution is to treat bug tracker permissions a bit more like the "commit bit," where accepting bugs would be limited to people who understand both the process and the direction/vision of Django. This would cost time, but could alleviate the frustration on both sides and ultimately result in more work getting done, not least because more people would be encouraged to participate.
These are just my thoughts based mostly on the demoralizing thread Jacob is addressing with this one. I have also found it demoralizing, because it makes me feel like it's not worth aspiring to contribute to Django because there are too many obstacles. Some of Russell's comments do counter that sentiment, but it still seems like there is no way to have any confidence about what to work on without having the insight of a core developer. Again, this is all my opinion and I could be way off.
Shawn
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 3:54 PM, Peter Landry <plan...@provplan.org> wrote:
> On 4/19/10 10:19 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> wrote:
>> Hi folks --
>> I'd like to try to reboot the discussion that's been going on about
>> Django's development process.
>> I'm finding the current thread incredibly demoralizing: there's a
>> bunch of frustration being expressed, and I hear that, but I'm having
>> trouble finding any concrete suggestions. Instead, the thread has
>> devolved into just going around in circles on the same small handful
>> of issues.
>> So: here's your chance. You have suggestions about Django's
>> development process? Make them. I'm listening.
>> Jacob
> 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?
> 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.
> I'm not really comfortable suggesting any concrete plans for how that might
> happen though. A single almost-trunk branch? A branch per
> lieutenant/component? I'm wary of adding too much bureaucracy and overhead.
> I think it's pretty clear that the core Django process is successful, and
> this seems like a low impact (though potentially high effort?) way to
> involve more of the community.
People only talk about a trunk-ready branch if they treat trunk as
some sort of continually updated, always correct, release branch. IMHO
trunk is where you commit features you want to be released, and you
deal with fallout on trunk - you can always revert changes.
An example of something that should have been committed to trunk
already (immediately following release of django 1.1 imo) is custom
FilterSpecs, #5833. This has been pushed from releases for 3 years,
first from 1.0, then 1.1, now 1.2 - all for a feature that should be
available in the admin.
This is a ticket that displays a lot of the issues discussed in the
other thread. The patch is feature complete, and community members
have been updating it to recent versions of django for 3 years. It has
comments of (seemingly) approval from core comitters, but lacks
documentation and tests, and so sits, dead in the water, missing
another release.
A system that works on other projects is a mentorship system. I'm sure
you have had lots of applicants to take part in GSoC - how about
recruiting some of the rejected proposals and have them work through
tickets like this, triaging and polishing to a committable state, at
which point they coordinate with their mentor to have it committed.
Obviously, they'd have to want to do this for free...
One thing is true, the status quo doesn't seem to be resolving these
forgotten tickets.
Cheers
Tom
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 10:19 AM, orokusaki <flashdesign...@gmail.com> wrote:
> The release of Django 1.0 comes with a promise of API stability and
> forwards-compatibility. In a nutshell, this means that code you
> develop against Django 1.0 will continue to work against 1.1
> unchanged, and you should need to make only minor changes for the 1.2
> release.
So you're proposing that 1.2 be the last backwards-compatible release,
and that 1.3 be incompatible (if necessary) with 1.2?
Jacob
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Apr 19, 2010 at 10:19 AM, orokusaki <flashdesign...@gmail.com> wrote:
>> The release of Django 1.0 comes with a promise of API stability and
>> forwards-compatibility. In a nutshell, this means that code you
>> develop against Django 1.0 will continue to work against 1.1
>> unchanged, and you should need to make only minor changes for the 1.2
>> release.
> So you're proposing that 1.2 be the last backwards-compatible release,
> and that 1.3 be incompatible (if necessary) with 1.2?
I think he's saying that 1.3 will work with 1.2 but not (necessarily)
with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0.
The specific number of point releases to remain compatible with can
probably be quibbled over, but I think the point is that maintaining
across the entirety of 1.x releases when point releases take this long
can be untenable for good forward momentum.
-- dz
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki <flashdesign...@gmail.com> wrote:
> >> The release of Django 1.0 comes with a promise of API stability and
> >> forwards-compatibility. In a nutshell, this means that code you
> >> develop against Django 1.0 will continue to work against 1.1
> >> unchanged, and you should need to make only minor changes for the 1.2
> >> release.
> > So you're proposing that 1.2 be the last backwards-compatible release,
> > and that 1.3 be incompatible (if necessary) with 1.2?
> I think he's saying that 1.3 will work with 1.2 but not (necessarily)
> with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0.
> The specific number of point releases to remain compatible with can
> probably be quibbled over, but I think the point is that maintaining
> across the entirety of 1.x releases when point releases take this long
> can be untenable for good forward momentum.
> -- dz
> --
> 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+unsubscribe@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-developers@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> 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.
Peter
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 11:05 AM, Dennis Kaarsemaker
<den...@kaarsemaker.net> wrote:
> 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?
If the quality's good, yes -- very much so.
Jacob
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 10:38 AM, David Zhou <da...@nodnod.net> wrote:
> The specific number of point releases to remain compatible with can
> probably be quibbled over, but I think the point is that maintaining
> across the entirety of 1.x releases when point releases take this long
> can be untenable for good forward momentum.
I'm pretty annoyed that you think that the policy is to maintain
backwards compatibility "across the entirety of 1.x releases" because,
well, that's not the policy. This is documented; see
http://docs.djangoproject.com/en/dev/internals/release-process/.
Quoting from there:
"""
Minor release (1.1, 1.2, etc.) [...] will contain new features,
improvements to existing features, and such. A minor release may
deprecate certain features from previous releases. If a feature in
version A.B is deprecated, it will continue to work in version A.B+1.
In version A.B+2, use of the feature will raise a DeprecationWarning
but will continue to work. Version A.B+3 will remove the feature
entirely.
So, for example, if we decided to remove a function that existed in Django 1.0:
Django 1.1 will contain a backwards-compatible replica of the function
which will raise a PendingDeprecationWarning. This warning is silent
by default; you need to explicitly turn on display of these warnings.
Django 1.2 will contain the backwards-compatible replica, but the
warning will be promoted to a full-fledged DeprecationWarning. This
warning is loud by default, and will likely be quite annoying.
Django 1.3 will remove the feature outright.
"""
So, yes, we're really *are* just quibbling over the specific number of
releases that Django will be compatible with. A few people want just
one stable release, but the core committers want two.
So here's where I put on by BDFL hat: Django's backwards-compability
policy will remain as quoted above.
You think I'm wrong, and that's fine, and I don't expect to convince
you otherwise. But ultimately it's my decision to make, and I'm making
it.
But for the record, I will explain why I feel so strongly about this:
The best part of my job is that I get to talk to and meet so many
people who're using Django. These folks span the glove, and they also
span the gamut of software developers. In the last year, I've spoken
to design agencies, data visualization companies, cloud computing
experts, Enterprise IT developers, web 2.0 developers, web 1.0
developers, new media, old media, startups, Fortune 500 CTOs, venture
capitalists, angel investors, bankers, attorneys, financial advisors,
firemen, and more.
The recurring theme -- the thing I hear over, and over, and over again
-- is how much they love Django's stability and predictability. Over
and over again I hear that software maintenance is a pain in the ass,
and that Django makes it easier. If upgrades from 1.1 to 1.2 aren't
easy, these developers tell me, then they won't be able to take
advantage of new features.
My evidence goes beyond anecdotal. Studies have shown that as much as
80% of software work is in maintenance, and, further, that much of
that maintenance work is non-corrective (i.e. adding features).
When software changes dramatically between releases, people get stuck
on old versions, and this means they're unable to develop the features
they need.
So, once again, the policy will not change unless you can demonstrate
overwhelming evidence that I am wrong.
Jacob
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Apr 19, 2010 at 10:38 AM, David Zhou <da...@nodnod.net> wrote:
>> The specific number of point releases to remain compatible with can
>> probably be quibbled over, but I think the point is that maintaining
>> across the entirety of 1.x releases when point releases take this long
>> can be untenable for good forward momentum.
> I'm pretty annoyed that you think that the policy is to maintain
> backwards compatibility "across the entirety of 1.x releases" because,
> well, that's not the policy. This is documented; see
> http://docs.djangoproject.com/en/dev/internals/release-process/.
You're right, of course, and I should've fact checked orokusaki's
assertion that that was the current policy. So I'll retract my
previous statements -- those are only applicable given the policy
stated in orokusaki's email.
-- dz
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 12:09 PM, orokusaki <flashdesign...@gmail.com> wrote:
> Firstly, thanks to Jacob for the highly hostile nature of his bedside
> manor.
Please, just stop. This doesn't help.
> Secondly, I didn't assert anything. I merely referenced the docs (I
> suppose this will be another case where you simply adjust the docs to
> mirror your recent assertion)
Now you're trolling - we've never done this. The documentation is in
SVN and there's a complete historical record. Point to one instance
where we've done this.
This is your last warning. Keep this up and I'm going to have no
choice but to kick you off this list.
Jacob
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 12:09 PM, orokusaki <flashdesign...@gmail.com> wrote:
> Firstly, thanks to Jacob for the highly hostile nature of his bedside
> manor.
> Secondly, I didn't assert anything. I merely referenced the docs (I
> suppose this will be another case where you simply adjust the docs to
> mirror your recent assertion)
Be thankful that America's national pastime allows for three strikes,
because if I weren't a baseball fan I'd be all for you being out
already.
-- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 12:24 PM, orokusaki <flashdesign...@gmail.com> wrote:
> Jacob, I just refreshed. Please don't kick me. I'm trying to have a
> dialogue, and I'm not trolling. Django is my life, and I want to help.
Then prove it.
Ball's in your court.
Jacob
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 12:23 PM, orokusaki <flashdesign...@gmail.com> wrote:
> -- No matter what industry you're in, or what your title is, your
> real job is "Sales Person". Your second job is "Customer Service", and
> finally your third job is "[Insert Job Title Here]".
Dammit, this isn't my job -- it's my fucking hobby.
The only way anything gets done here is if people volunteer and do it.
> I'm not saying that the core developers should think of their free,
> public contributions as a paying client, but it might be good to
> exercise a little restraint when you feel "annoyed".
You have absolutely no idea the level of restraint I'm showing.
> If I didn't feel
> so pushed back by the core team, I'd become a big contributor, but
> instead of writing code, I spend all of my free time arguing,
Than STOP ARGUING AND WRITE SOME CODE!
Jacob
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
My understanding is that write access to triage stage and tickets
details is granted to everybody (even to anonymous users), and
everybody can change everything, thus making this data not 100%
reliable.
Having an additional field{s} in the ticket, only accessible to core
developers, where they would put the "official" (as in: approved by a
core developer) triage status of the ticket, could improve the
efficency of the tickets review.
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Before I even say anything: I think the core team does a great job,
they're as fair as humanly possible in their decisions, and Django's
stability is amazing.
My disclaimer out of the way, I'd like to share my own experience of
being a new contributor just to add another perspective.
I only started submitting patches during the 1.2 release cycle, so I'm
still a relative newbie. In 4 months I've learned *a lot* about
Django's process and the history of thought behind many of the issues
in both the codebase and the development process. But that knowledge
wasn't easy to come by.
I read the contributing docs twice before I even opened my first
ticket. Twice more before I submitted a single patch.
When I finally did submit my first patch, I was terrified of getting
it wrong and having it rejected. I'd seen it happen on other tickets.
It wasn't until I got *more involved* and started keeping up with the
trac timeline--watching the ebb and flow of tickets--that I started to
understand how the tone on trac had a reason. Until you get that
perspective, it's hard to know what's right or wrong, and easy to take
things personally. The core devs can seem imposing or scary simply
because you don't know them.
Even after reading the contributing docs and all the internals several
times, there was still a large portion of knowledge that I found only
existed outside those docs. Spending hours reading through this list's
history and through the #django-dev IRC logs have answered a lot more
of my questions. While it might seem obvious to say "go add that
information to the docs" the truth is that a lot of what new
contributors need to learn is subjective, and may not belong in
official documentation.
I did find that the ambiguity of ticket statuses in trac made it hard
to dive right in and understand what was going on. But that's been
discussed at length. When someone has an idea for a solution there,
I'll be the first to jump in and work on it.
If anything, my point is that getting started as a Django contributor
*can* be difficult, and the core team just being aware of that fact is
a good thing.
That said, I have no sympathy for the malcontents. I would really
rather have seen 1.2 get released than 80+ messages on these two
threads. If complaints were patches, we'd be halfway to 1.3 by now.
Divisiveness and ill-willed argument is stifling to creativity and
progress. I hope this post doesn't contribute to it.
I'll close with Benjamin Franklin: "We must hang together or assuredly
we shall hang separately."
- Gabriel
On Apr 19, 7:19 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
> Jacob
> --
> 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+unsubscribe@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-developers@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Apr 19, 10:19 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> Hi folks --
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
I'm new in Django so you can just ignore my opinion but probably due
to
a fresh eye I think I see _one_ important reason why such discussions
pop up over and over again.
For the project of such exposure as Django the number of _active_ core
members that actually do work on trunk and are participating in the
decision making process is extremely small. Quick and dirty statistic
on
trunk commits shows that more than 75% of the work in _trunk_ is done
by just 4 developers [1] and from this list it seems that not much
more are
really involved into design decision making either.
At the same time the requirements for any new proposal are extremely
high. You and Russ have explained them many times on this list. in
short
it should be perfect from the core view to be included.
I'm not saying it is good or bad. No judgment at all. Just pure
observation.
These two things simply mean that for the core team it is just
_physically_
impossible to cope with the rising flow of requests/patches/bug
reports.
IMHO there are two ways out of this :
1. Share responsibility and ownership with more developers even if
their
views are not exactly match yours.
2. Just ignore such discussions, they are inevitable, unless you'll
make
this list moderated.
Regards,
Mike
[1] Number of commits and changed lines per developer for the
trunk@13001:
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
I have to agree with Gabriel here as I to have only recently been trying to
actively participate in the growing experience that is Django. Though I
haven't quite yet made the jump into actually contributing code yet as I'm
still coming to terms with understanding the internals of both the code and
the community. Though I am not a contributor to Django I watch the mailing
lists closely and try to use the discussions to help me build up my own
knowledge of the internals of both how the community works as well as how
Django itself evolves. This may be a developers discussion list but there
are some of us actively watching these threads who find it quite scary when
a 'policy change' discussion becomes a main focus on a framework that holds
a lot of peoples futures in the balance. My 2 cents.
I too will close with the very same Benjamin Franklin quote that Gabriel
previously posted, as it is a very relevant situation:
"We must hang together or assuredly we shall hang separately.""
On Mon, Apr 19, 2010 at 1:34 PM, Gabriel Hurley <gab...@gmail.com> wrote:
> Before I even say anything: I think the core team does a great job,
> they're as fair as humanly possible in their decisions, and Django's
> stability is amazing.
> My disclaimer out of the way, I'd like to share my own experience of
> being a new contributor just to add another perspective.
> I only started submitting patches during the 1.2 release cycle, so I'm
> still a relative newbie. In 4 months I've learned *a lot* about
> Django's process and the history of thought behind many of the issues
> in both the codebase and the development process. But that knowledge
> wasn't easy to come by.
> I read the contributing docs twice before I even opened my first
> ticket. Twice more before I submitted a single patch.
> When I finally did submit my first patch, I was terrified of getting
> it wrong and having it rejected. I'd seen it happen on other tickets.
> It wasn't until I got *more involved* and started keeping up with the
> trac timeline--watching the ebb and flow of tickets--that I started to
> understand how the tone on trac had a reason. Until you get that
> perspective, it's hard to know what's right or wrong, and easy to take
> things personally. The core devs can seem imposing or scary simply
> because you don't know them.
> Even after reading the contributing docs and all the internals several
> times, there was still a large portion of knowledge that I found only
> existed outside those docs. Spending hours reading through this list's
> history and through the #django-dev IRC logs have answered a lot more
> of my questions. While it might seem obvious to say "go add that
> information to the docs" the truth is that a lot of what new
> contributors need to learn is subjective, and may not belong in
> official documentation.
> I did find that the ambiguity of ticket statuses in trac made it hard
> to dive right in and understand what was going on. But that's been
> discussed at length. When someone has an idea for a solution there,
> I'll be the first to jump in and work on it.
> If anything, my point is that getting started as a Django contributor
> *can* be difficult, and the core team just being aware of that fact is
> a good thing.
> That said, I have no sympathy for the malcontents. I would really
> rather have seen 1.2 get released than 80+ messages on these two
> threads. If complaints were patches, we'd be halfway to 1.3 by now.
> Divisiveness and ill-willed argument is stifling to creativity and
> progress. I hope this post doesn't contribute to it.
> I'll close with Benjamin Franklin: "We must hang together or assuredly
> we shall hang separately."
> - Gabriel
> On Apr 19, 7:19 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> > Hi folks --
> > I'd like to try to reboot the discussion that's been going on about
> > Django's development process.
> > I'm finding the current thread incredibly demoralizing: there's a
> > bunch of frustration being expressed, and I hear that, but I'm having
> > trouble finding any concrete suggestions. Instead, the thread has
> > devolved into just going around in circles on the same small handful
> > of issues.
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
> > Jacob
> > --
> > 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+unsubscribe@googlegroups.com<django-developers%2Bunsubscr ibe@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-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscribe@googlegroups.com<django-developers%2Bunsubscr ibe@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-developers@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Once I understand what I am doing I would have no problem putting together
an "ebb and flow" diagram with pointers to code....something like...Step 1
Request Made--When a request is made the first thing that happens is def
AutoStart is activated, next, def SecondStart is fired (with pictures).
On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta <gcio...@gmail.com> wrote:
> On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss <ja...@jacobian.org>
> wrote:
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
> My understanding is that write access to triage stage and tickets
> details is granted to everybody (even to anonymous users), and
> everybody can change everything, thus making this data not 100%
> reliable.
> Having an additional field{s} in the ticket, only accessible to core
> developers, where they would put the "official" (as in: approved by a
> core developer) triage status of the ticket, could improve the
> efficency of the tickets review.
> --
> 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+unsubscribe@googlegroups.com<django-developers%2Bunsubscr ibe@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-developers@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> For the project of such exposure as Django the number of _active_ core
> members that actually do work on trunk and are participating in the
> decision making process is extremely small. Quick and dirty statistic
> on
> trunk commits shows that more than 75% of the work in _trunk_ is done
> by just 4 developers [1] and from this list it seems that not much
> more are
> really involved into design decision making either.
It does appear true that we're a little light on active core devs right now. Can I propose Alex Gaynor for commit bit? Seriously, why hasn't someone else proposed this already? :)
George
-- 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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+unsubscribe@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-developers@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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)
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+unsubscribe@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-developers@googlegroups.com.
> To unsubscribe from this group, send email to django-developers+unsubscribe@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-developers@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
