Le 25 janv. 2013 à 11:59, Abdullah Esmail <[email protected]> a écrit :

> I realize that it's hard to follow a release schedule like this especially 
> for open source software, but I believe it's very doable.


I agree that it should be doable in theory, and I strongly support predictable 
schedules. Obviously, in practice, in spite of the core team's efforts, it 
doesn't happen.

There isn't any corporate backing behind Django and no one gets paid to make 
releases happens. Besides, active contributors are comfortable with running on 
master. As a consequence, the incentive for taking the responsibility of making 
a release on a given date is low. Solving that problem might to more harm than 
good!



Le 27 janv. 2013 à 17:47, Carlos Ribeiro <[email protected]> a écrit :

> Of course, there are numerous problems which you point out, but I believe 
> that many of them could be solved with improvements in coordination and 
> discipline**. Of course, people are volunteers, and managing a schedule is 
> hard. But it would be nice to do something in this regard.

FYI I tried to do exactly that for 1.4 and 1.5 and I failed. Someone else is 
welcome to try again for 1.6.

One thing I haven't attempted is to extend the "coordination and discipline" 
beyond the core team to the entire community.

As a very long time user of Django, how much testing are you giving to alpha / 
beta / RC releases within two weeks? How many regressions have you reported? 
How many patches for release blockers have you written? What could increase 
your contributions?

> The main problem for me is modularity. If something isn't ready by release 
> date, it has to be removed - and for this to be possible, the base code has 
> to be very modular. Features should be isolated in such a way that they could 
> be turned on & off at will. That has implications too, nothing is easy 
> (there's no free lunch).


I'm not sure this can work. You cannot simply rollback the fix for a data loss 
bug, because that's considered a release blocker; and such fixes often create 
subtle regressions. For a more extreme example, you cannot rollback the 
unicode_literals patch that was the first step to Python 3 support but created 
half a dozen regressions (which is impressively few considering the scope and 
the size of that patch).

Best regards,

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to