Re: Process DEP for "official" non-core projects

[Andrew Godwin]

Good point. I'll get a proper DEP draft written up for next week and then
we can comment on it directly with more substance - it sounds like the idea
of having one is popular, though, which is what I mainly wanted to check!

Andrew

On Thu, May 12, 2016 at 12:52 PM, Marc Tamlyn  wrote:

> I'm a big fan of pulling things into github.com/django. One other point
> which has been raised when I've mentioned this before is the role of the
> django fellow(s) with regards to these projects. This should at least be
> touched on in the DEP.
>
> On 11 May 2016 at 20:34, William Hakizimana  wrote:
>
>> Just wanted to thank you so much for your hard work. The documentation is
>> really well written!
>>
>> On Wednesday, May 11, 2016, at 1:29:34 PM UTC-5, Andrew Godwin wrote:
>>>
>>>
>>>
>>> On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss 
>>> wrote:
>>>
 I like this, and +1 on your rough outline.

 There is one missing thing here though: I think we need to consider the
 process/policy for removing things if they're no longer maintained. Without
 clear maintainership forks happen, which is bad for pretty much everyone.
 So I think we should have a plan in place for what happens if the shepherd
 can no longer tend to their flock, and nobody else steps into the role.

 I'd suggest something like this: if a project goes stale, core calls
 for new maintainers. If none arrive within a reasonable period of time (3
 months?) we deprecate and remove the package from our org.


>>> That seems sensible to me; if the project is important enough to Django,
>>> I'm sure people will step up to take over, and if not, dropping it is
>>> probably the better option rather than letting it linger.
>>>
>>> I would be inclined to merely mark it as deprecated and not drop it from
>>> e.g. the GitHub org, though, as where would we move it *to*?
>>>
>>> Andrew
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/885bd485-341a-47ad-8766-7ef17df77ada%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1Hiu3uYr2if4JP%2BoVMhVef%3D_J57dFdko6%2BpTzoDGMerLA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uphmqTZL2a6S%3D_gsMJ4Qd1Mtt4%2BvX23qK3tSzO2YHC7Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Process DEP for "official" non-core projects

[Marc Tamlyn]

I'm a big fan of pulling things into github.com/django. One other point
which has been raised when I've mentioned this before is the role of the
django fellow(s) with regards to these projects. This should at least be
touched on in the DEP.

On 11 May 2016 at 20:34, William Hakizimana  wrote:

> Just wanted to thank you so much for your hard work. The documentation is
> really well written!
>
> On Wednesday, May 11, 2016, at 1:29:34 PM UTC-5, Andrew Godwin wrote:
>>
>>
>>
>> On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss 
>> wrote:
>>
>>> I like this, and +1 on your rough outline.
>>>
>>> There is one missing thing here though: I think we need to consider the
>>> process/policy for removing things if they're no longer maintained. Without
>>> clear maintainership forks happen, which is bad for pretty much everyone.
>>> So I think we should have a plan in place for what happens if the shepherd
>>> can no longer tend to their flock, and nobody else steps into the role.
>>>
>>> I'd suggest something like this: if a project goes stale, core calls for
>>> new maintainers. If none arrive within a reasonable period of time (3
>>> months?) we deprecate and remove the package from our org.
>>>
>>>
>> That seems sensible to me; if the project is important enough to Django,
>> I'm sure people will step up to take over, and if not, dropping it is
>> probably the better option rather than letting it linger.
>>
>> I would be inclined to merely mark it as deprecated and not drop it from
>> e.g. the GitHub org, though, as where would we move it *to*?
>>
>> Andrew
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/885bd485-341a-47ad-8766-7ef17df77ada%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Hiu3uYr2if4JP%2BoVMhVef%3D_J57dFdko6%2BpTzoDGMerLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Process DEP for "official" non-core projects

[William Hakizimana]

Just wanted to thank you so much for your hard work. The documentation is 
really well written!

On Wednesday, May 11, 2016, at 1:29:34 PM UTC-5, Andrew Godwin wrote:
>
>
>
> On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss  
> wrote:
>
>> I like this, and +1 on your rough outline.
>>
>> There is one missing thing here though: I think we need to consider the 
>> process/policy for removing things if they're no longer maintained. Without 
>> clear maintainership forks happen, which is bad for pretty much everyone. 
>> So I think we should have a plan in place for what happens if the shepherd 
>> can no longer tend to their flock, and nobody else steps into the role.
>>
>> I'd suggest something like this: if a project goes stale, core calls for 
>> new maintainers. If none arrive within a reasonable period of time (3 
>> months?) we deprecate and remove the package from our org.
>>
>>
> That seems sensible to me; if the project is important enough to Django, 
> I'm sure people will step up to take over, and if not, dropping it is 
> probably the better option rather than letting it linger.
>
> I would be inclined to merely mark it as deprecated and not drop it from 
> e.g. the GitHub org, though, as where would we move it *to*? 
>
> Andrew 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/885bd485-341a-47ad-8766-7ef17df77ada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Process DEP for "official" non-core projects

[Jacob Kaplan-Moss]

On Wed, May 11, 2016 at 2:29 PM, Andrew Godwin  wrote:

> I would be inclined to merely mark it as deprecated and not drop it from
> e.g. the GitHub org, though, as where would we move it *to*?
>

Sure, that's fine with me too. The key point is just that we're not
(implicitly or explicitly) offering support where there is none.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAK8PqJFscgUw-xi9%3DodhUa63EeFMGsffdzeUjgm%3D-Wy4WBHNFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Process DEP for "official" non-core projects

[Andrew Godwin]

On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss 
wrote:

> I like this, and +1 on your rough outline.
>
> There is one missing thing here though: I think we need to consider the
> process/policy for removing things if they're no longer maintained. Without
> clear maintainership forks happen, which is bad for pretty much everyone.
> So I think we should have a plan in place for what happens if the shepherd
> can no longer tend to their flock, and nobody else steps into the role.
>
> I'd suggest something like this: if a project goes stale, core calls for
> new maintainers. If none arrive within a reasonable period of time (3
> months?) we deprecate and remove the package from our org.
>
>
That seems sensible to me; if the project is important enough to Django,
I'm sure people will step up to take over, and if not, dropping it is
probably the better option rather than letting it linger.

I would be inclined to merely mark it as deprecated and not drop it from
e.g. the GitHub org, though, as where would we move it *to*?

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1upAzHryXTZF0BnDQbzhoQp_tC7Nu2RnvjjoY7vNv-Mt9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Process DEP for "official" non-core projects

[Andrew Godwin]

On Wed, May 11, 2016 at 10:06 AM, Carl Meyer  wrote:

>
> I'm not quite sure what this means. By "major release" here, you mean
> "major release of the adopted project," not "major release of Django"?
> So this means that security fixes for the adopted project will be
> provided as patch releases on its current major release, but won't be
> backported beyond that?
>

Yes, my intention was of major releases for the non-core project. We could
always extend this to have the same level of coverage as Django; the
question is if we treat non-core projects as things that are provisionally
going into core and still maturing, or if we treat them as full projects in
their own right where the goal is not core integration (which might be
good).


>
> All of those points seem sensible to me, but I'd be interested in
> hearing from people who've already been actively involved in localflavor
> maintenance.
>

Me too - I'm not entirely clear what the state of maintenance and releasing
is like for it at the moment.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1upcp2zrHrv9njmFvmqZ9KP89CzE6nDyR6Rs6BCmTJ65hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Process DEP for "official" non-core projects

[Jacob Kaplan-Moss]

I like this, and +1 on your rough outline.

There is one missing thing here though: I think we need to consider the
process/policy for removing things if they're no longer maintained. Without
clear maintainership forks happen, which is bad for pretty much everyone.
So I think we should have a plan in place for what happens if the shepherd
can no longer tend to their flock, and nobody else steps into the role.

I'd suggest something like this: if a project goes stale, core calls for
new maintainers. If none arrive within a reasonable period of time (3
months?) we deprecate and remove the package from our org.

Jacob

On Tue, May 10, 2016 at 10:58 PM, Andrew Godwin  wrote:

> Hi everyone,
>
> Following my decision to move Channels away from a 1.10 merge and towards
> an existence as a separate app for a bit while it matures, I would like to
> write up a process DEP for how we achieve this - specifically, what it
> takes to be adopted as a non-core app, what that means for the Django
> organisation, and what its goals should be.
>
> Given recent events, I feel having a process that's agreed upon and
> specified is a good move for this, especially if we do it with something
> else again in future.
>
> My rough outline is as follows:
>
>  - A non-core project can be moved under the governance of the Django
> project if it is deemed an important feature that's in our interests to
> maintain and grow
>
>  - We should be relatively convinced that it represents the best
> implementation of the feature that there is, that it is matured and has a
> stable release, and that there aren't competing implementations at a
> similar level
>
>  - The decision-making structure is similar to that of a DEP, in that
> there must be a core "shepherd" who is the go-to person for it and makes
> sure it crosses the basic test, and a technical board vote on inclusion.
>
>  - A project under Django governance will fall under the Django umbrella
> for security-related reports and fixes, and will maintain the Django
> security policy on the current major release only.
>
>  - Release schedule will not be fixed to Django's and no LTS pattern will
> be forced on it, and a limited backwards-compatibility policy of only "at
> least one major version" will be maintained.
>
> I think it's worth working out how the whole thing is going to run if
> we're going to do it properly, and the DEP system seems like the best place
> for something like this. If we do go down the path of starting to split out
> Django into more packages, as well, it could provide a useful base for that
> to structure around (though we'd want to beef up security/backwards-compat
> timelines).
>
> It's also probably sensible that whatever we come up with covers
> localflavor, as well, since that's sort of in this state already.
>
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFwN1ur%3D-RAxA72vTxT2bq5-QVDLcdnOiXK_HnvyjwZHpi_izw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAK8PqJHTX2kYR8CpNGz_rOJGGaKf0Z3seXA_LTLHtbNnMyjh5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Process DEP for "official" non-core projects

[Carl Meyer]

On 05/10/2016 08:58 PM, Andrew Godwin wrote:
> Following my decision to move Channels away from a 1.10 merge and
> towards an existence as a separate app for a bit while it matures, I
> would like to write up a process DEP for how we achieve this -
> specifically, what it takes to be adopted as a non-core app, what that
> means for the Django organisation, and what its goals should be.
> 
> Given recent events, I feel having a process that's agreed upon and
> specified is a good move for this, especially if we do it with something
> else again in future.

Makes sense to me.

> My rough outline is as follows:
> 
>  - A non-core project can be moved under the governance of the Django
> project if it is deemed an important feature that's in our interests to
> maintain and grow
> 
>  - We should be relatively convinced that it represents the best
> implementation of the feature that there is, that it is matured and has
> a stable release, and that there aren't competing implementations at a
> similar level
> 
>  - The decision-making structure is similar to that of a DEP, in that
> there must be a core "shepherd" who is the go-to person for it and makes
> sure it crosses the basic test, and a technical board vote on inclusion.
> 
>  - A project under Django governance will fall under the Django umbrella
> for security-related reports and fixes, and will maintain the Django
> security policy on the current major release only.

I'm not quite sure what this means. By "major release" here, you mean
"major release of the adopted project," not "major release of Django"?
So this means that security fixes for the adopted project will be
provided as patch releases on its current major release, but won't be
backported beyond that?

>  - Release schedule will not be fixed to Django's and no LTS pattern
> will be forced on it, and a limited backwards-compatibility policy of
> only "at least one major version" will be maintained.
> 
> I think it's worth working out how the whole thing is going to run if
> we're going to do it properly, and the DEP system seems like the best
> place for something like this. If we do go down the path of starting to
> split out Django into more packages, as well, it could provide a useful
> base for that to structure around (though we'd want to beef up
> security/backwards-compat timelines).
> 
> It's also probably sensible that whatever we come up with covers
> localflavor, as well, since that's sort of in this state already.

All of those points seem sensible to me, but I'd be interested in
hearing from people who've already been actively involved in localflavor
maintenance.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573366A9.5020706%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Process DEP for "official" non-core projects

[Andrew Godwin]

Hi everyone,

Following my decision to move Channels away from a 1.10 merge and towards
an existence as a separate app for a bit while it matures, I would like to
write up a process DEP for how we achieve this - specifically, what it
takes to be adopted as a non-core app, what that means for the Django
organisation, and what its goals should be.

Given recent events, I feel having a process that's agreed upon and
specified is a good move for this, especially if we do it with something
else again in future.

My rough outline is as follows:

 - A non-core project can be moved under the governance of the Django
project if it is deemed an important feature that's in our interests to
maintain and grow

 - We should be relatively convinced that it represents the best
implementation of the feature that there is, that it is matured and has a
stable release, and that there aren't competing implementations at a
similar level

 - The decision-making structure is similar to that of a DEP, in that there
must be a core "shepherd" who is the go-to person for it and makes sure it
crosses the basic test, and a technical board vote on inclusion.

 - A project under Django governance will fall under the Django umbrella
for security-related reports and fixes, and will maintain the Django
security policy on the current major release only.

 - Release schedule will not be fixed to Django's and no LTS pattern will
be forced on it, and a limited backwards-compatibility policy of only "at
least one major version" will be maintained.

I think it's worth working out how the whole thing is going to run if we're
going to do it properly, and the DEP system seems like the best place for
something like this. If we do go down the path of starting to split out
Django into more packages, as well, it could provide a useful base for that
to structure around (though we'd want to beef up security/backwards-compat
timelines).

It's also probably sensible that whatever we come up with covers
localflavor, as well, since that's sort of in this state already.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1ur%3D-RAxA72vTxT2bq5-QVDLcdnOiXK_HnvyjwZHpi_izw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.