Re: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Tobias McNulty 
On Mon, Aug 16, 2010 at 12:23 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> My apologies -- I haven't watched the video for a while, so I forgot
> that detail. I'm not sure adopting that policy would help Django,
> though; we have enough of a bottleneck with committers without
> exacerbating the problem.


Sure, I just happened to be watching it right then, so I thought I'd put it
in textual form where people can see it without spending 30 minutes listing
to the talk. :-)

I'm certainly not arguing that we should adopt such a policy, but it is a
neat idea.  Like you've been saying, Django trunk does a pretty good job of
staying stable as it is and things seem to get fairly well tested on an
ongoing basis, so I'm not sure it's an issue.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

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

Re: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Russell Keith-Magee 
On Mon, Aug 16, 2010 at 10:50 AM, Tobias McNulty  wrote:
> On Sun, Aug 15, 2010 at 10:31 PM, Russell Keith-Magee
>  wrote:
>>
>> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli 
>> wrote:
>> >  - punish dev's who don't fix their bugs quickly after api lock
>> >
>> > (The presentation lacks specifics on the last point. ;)
>>
>> Which is a big omission. When you're not paying anyone, and you
>> already have a problem getting contributions, you have limited options
>> for punishment. I'd be very interested to hear what constitutes
>> "punishment" in this approach.
>
> For the record, it is mentioned.  The punishment they tried for a few
> releases was denying commits from the developers who did not do their fair
> share of testing for 2 weeks after the tree was unlocked for everyone else.

My apologies -- I haven't watched the video for a while, so I forgot
that detail. I'm not sure adopting that policy would help Django,
though; we have enough of a bottleneck with committers without
exacerbating the problem.

Yours,
Russ Magee %-)

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

Re: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Russell Keith-Magee 
On Mon, Aug 16, 2010 at 11:08 AM, Mark Bucciarelli  wrote:
> On Mon, Aug 16, 2010 at 10:31:11AM +0800, Russell Keith-Magee wrote:
>> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli  wrote:
>>
>> > ?- random api lock (people tend towards complacency)
>>
>> I'm not entirely certain I understand this point -- or, at least,
>> how it would apply to Django.
>>
>
> So the interface between backend and object model is one.  I suppose
> there is an equivalent interface on the template side.
>
> One example that tripped me up: in 1.2, the signature of
> BaseDatabaseWrapper __init__() changed.
>
> In 1.1, I had
>
>        def __init__(self, settings_dict):
>
> and in 1.2 I needed
>
>        def __init__(self, *args, **kwargs):
>
>>
>> Our APIs are always locked, since we don't allow backwards incompatible
>> API changes.
>>
>
> My 1.1 version must have been wrong then.

A point of clarification on my part: we don't allow backwards
incompatible API changes in APIs declared as stable. The API for
database backends isn't currently on that list [1].

[1] http://docs.djangoproject.com/en/1.2/misc/api-stability/

Whether we should promote the backed interface to a stable interface
is a separate issue, but certainly one worth discussion (especially
given that there are a number of external database backends emerging
in the community).

>> > Also, hackathons are a great idea. ?A room full of core developers can
>> > get a hell of a lot done in a week.
>>
>> You won't get any argument from me on this one.
>>
>
> I wonder if you ran a really targetting fund-raising campaign how much
> would come in.  I know when the use is specific, it's easier to raise
> money.  Sounds like if you raised $12k it would get you pretty close.

An interesting idea, and one where the Django Foundation could play a
big role. However, this doesn't address the 'getting a week off work'
issue

Yours,
Russ Magee %-)

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

Re: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Mark Bucciarelli 
On Mon, Aug 16, 2010 at 10:31:11AM +0800, Russell Keith-Magee wrote:
> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli  wrote:
> 
> > ?- random api lock (people tend towards complacency)
> 
> I'm not entirely certain I understand this point -- or, at least,
> how it would apply to Django.
>

So the interface between backend and object model is one.  I suppose 
there is an equivalent interface on the template side.

One example that tripped me up: in 1.2, the signature of
BaseDatabaseWrapper __init__() changed.

In 1.1, I had 

def __init__(self, settings_dict):

and in 1.2 I needed

def __init__(self, *args, **kwargs):

>
> Our APIs are always locked, since we don't allow backwards incompatible
> API changes.
>

My 1.1 version must have been wrong then.

>
> > ?- punish dev's who don't fix their bugs quickly after api lock
> >
> > (The presentation lacks specifics on the last point. ;)
> 
> Which is a big omission. 
>

I'm not a dev there, so I don't know.  I'm a regular lurker on the
mailing lists though, so it either happens off-list or on-list but
very infrequently.

> 
> > Also, hackathons are a great idea. ?A room full of core developers can
> > get a hell of a lot done in a week.
> 
> You won't get any argument from me on this one. 
>

I wonder if you ran a really targetting fund-raising campaign how much
would come in.  I know when the use is specific, it's easier to raise
money.  Sounds like if you raised $12k it would get you pretty close.

m 

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

Re: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Tobias McNulty 
On Sun, Aug 15, 2010 at 10:31 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli 
> wrote:
> >  - punish dev's who don't fix their bugs quickly after api lock
> >
> > (The presentation lacks specifics on the last point. ;)
>
> Which is a big omission. When you're not paying anyone, and you
> already have a problem getting contributions, you have limited options
> for punishment. I'd be very interested to hear what constitutes
> "punishment" in this approach.


For the record, it is mentioned.  The punishment they tried for a few
releases was denying commits from the developers who did not do their fair
share of testing for 2 weeks after the tree was unlocked for everyone else.

Cheers,
Tobias

-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

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

Re: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Russell Keith-Magee 
On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli  wrote:
> On Sat, Aug 14, 2010 at 03:03:27PM +0800, Russell Keith-Magee wrote:
>>
>> If you have suggestions on how we can improve Django's development
>> process and address these issues, we're happy to hear them.
>>
>
> You may find this interesting:
>
>        http://openbsd.org/papers/asiabsdcon2009-release_engineering/
>
> (There's also a video of the presentation on YouTube.)

I've seen the video before; I didn't know the slide deck was
available. Thanks for the link.

My take on this is that we're reasonably close to OpenBSD's
development process. The only significant difference is that we have
the 'feature discussion' period where very little gets done on the
tree, and major features are committed once that discussion period has
lapsed.

If you look at the 1.2 cycle, most of the major features were
committed in December, just prior to the alpha release. If you dropped
the 'feature discussion' period from the 1.2 timeline, you would end
up with a development cycle that matches fairly closely to OpenBSD's.

We have the feature development phase for a very good reason -- we
have extremely limited resources (based on the charts in that slide
deck, *much* lower than OpenBSD), and we want to focus those
resources. If we continued to discuss new features while we were
trying to get a release out the door, it becomes even harder to meet
deadlines, because resources that would be dedicated to finding and
fixing bugs (both core team resources and general community resources)
are diverted into developing new code.

> Tenets:
>
>  - all development on trunk (no $ for QA team in free software)

We already do this.

>  - daily snapshots (eat your own dogfood)

In an era where you can pip install from a git/hg/svn repository, this
isn't as important as it once was (or as important as it is for system
software like OpenBSD). However, I agree that it would be good to
automate this process somewhat (if only because we have a very low bus
factor when it comes to release management).

>  - random api lock (people tend towards complacency)

I'm not entirely certain I understand this point -- or, at least, how
it would apply to Django. Our APIs are always locked, since we don't
allow backwards incompatible API changes. Major new features don't get
added to trunk until we're happy with their API, so new features
aren't subject to API changes, either.

>  - punish dev's who don't fix their bugs quickly after api lock
>
> (The presentation lacks specifics on the last point. ;)

Which is a big omission. When you're not paying anyone, and you
already have a problem getting contributions, you have limited options
for punishment. I'd be very interested to hear what constitutes
"punishment" in this approach.

> Also, hackathons are a great idea.  A room full of core developers can
> get a hell of a lot done in a week.

You won't get any argument from me on this one. The complication is
geography, and the resultant cost. I'm based in Western Australia, so
it costs around $3000 to get me in a room with the other core
developers somewhere in the US. That number is slightly less for
Malcolm, because he's based on the east coast of Australia. Luke and
Jannis both have to cross the Atlantic. And this completely avoids the
question of how we find the time out of our work schedules to
contribute a week of development effort.

Any suggestions on how to overcome these limitations will be
gratefully received:-)

Yours,
Russ Magee %-)

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

dev process [was: #11834: colorized debug page]

2010-08-15 Thread Mark Bucciarelli 
On Sat, Aug 14, 2010 at 03:03:27PM +0800, Russell Keith-Magee wrote:
> 
> If you have suggestions on how we can improve Django's development
> process and address these issues, we're happy to hear them.
> 

You may find this interesting:

http://openbsd.org/papers/asiabsdcon2009-release_engineering/

(There's also a video of the presentation on YouTube.)

Tenets:

  - all development on trunk (no $ for QA team in free software)

  - daily snapshots (eat your own dogfood)

  - random api lock (people tend towards complacency)

  - punish dev's who don't fix their bugs quickly after api lock

(The presentation lacks specifics on the last point. ;)

Also, hackathons are a great idea.  A room full of core developers can
get a hell of a lot done in a week.

m

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