Re: postorius, v2
On 17-02-02 21:28:29, ng0 wrote: > > Hartmut Goebel writes: > > > Hi, > > > > I just found that I did not verify the inputs carefully enough. Sorry. > > Here are my comments: > > > > * python-defusedxml: okay > > * python-openid: okay > > * python-django-allauth: > > o openid, request-oauthlib requests ought to be propagated inputs > > o mock is native, okay, but only required for the python2 variant > > o Why is django a native input? See below for discussion > > * python-django-gravatar2, may be okay, see below for discussion. > > * python-django-mailman3 > > o All "inputs" except django need to be propagated inputs. > > o Regarding django: see below > > * * postorius: okay (this is an application, so no propagated inputs > > are required) > > > > > > And as we just learned about the licenses: python-django-mailman3 should > > be gpl3+ > > > > > > I'm unsure about the correct handling of django in django-XXX. Can we > > find rules for this to make future packager's life easier? > > > > Should django be a "normal" input or a "native" one? What does this > > depend on? > > > > For now I will go with (input) and not (native-input). If that's > not okay, we can still fix it afterwards? > I will send the new patchseries tomorrow. > > Thanks! I will send the rebased series tomorrow afternoon. I will not be in the position to answer very much next week, so if no one else replies to the django issue, you could decide on what's the best approach practically. Changes to individual packages can still be applied afterwards. > > Clear is: django-XXX should not "propagate" django: > > > > * django is a framework, django-XXX is an extension for this framework. > > * If some application is using django-XXX, I'd expect it to have > > django specified as "input", too, since primary it is a django > > application. Maybe even djangoXXX is an optional component > > > > > > Just for the records: > > > > * django-XXX should propagate other django extension it requires. > > o If some application is using django-XXX, if should not care > > about other django extensions django-XXX requires. This is the > > same like as it does not have to care about other python > > packages django-XXX requires. > > > -- > ng0 . https://www.inventati.org/patternsinthechaos/ > -- ng0 -- https://www.inventati.org/patternsinthechaos/
Re: postorius, v2
Hartmut Goebel writes: > Hi, > > I just found that I did not verify the inputs carefully enough. Sorry. > Here are my comments: > > * python-defusedxml: okay > * python-openid: okay > * python-django-allauth: > o openid, request-oauthlib requests ought to be propagated inputs > o mock is native, okay, but only required for the python2 variant > o Why is django a native input? See below for discussion > * python-django-gravatar2, may be okay, see below for discussion. > * python-django-mailman3 > o All "inputs" except django need to be propagated inputs. > o Regarding django: see below > * * postorius: okay (this is an application, so no propagated inputs > are required) > > > And as we just learned about the licenses: python-django-mailman3 should > be gpl3+ > > > I'm unsure about the correct handling of django in django-XXX. Can we > find rules for this to make future packager's life easier? > > Should django be a "normal" input or a "native" one? What does this > depend on? > For now I will go with (input) and not (native-input). If that's not okay, we can still fix it afterwards? I will send the new patchseries tomorrow. Thanks! > Clear is: django-XXX should not "propagate" django: > > * django is a framework, django-XXX is an extension for this framework. > * If some application is using django-XXX, I'd expect it to have > django specified as "input", too, since primary it is a django > application. Maybe even djangoXXX is an optional component > > > Just for the records: > > * django-XXX should propagate other django extension it requires. > o If some application is using django-XXX, if should not care > about other django extensions django-XXX requires. This is the > same like as it does not have to care about other python > packages django-XXX requires. -- ng0 . https://www.inventati.org/patternsinthechaos/
Re: postorius, v2
Hartmut Goebel writes: > Hi, > > I just found that I did not verify the inputs carefully enough. Sorry. > Here are my comments: No problem. Thanks for checking again, I have no previous experience with django. > * python-defusedxml: okay > * python-openid: okay > * python-django-allauth: > o openid, request-oauthlib requests ought to be propagated inputs > o mock is native, okay, but only required for the python2 variant > o Why is django a native input? See below for discussion > * python-django-gravatar2, may be okay, see below for discussion. > * python-django-mailman3 > o All "inputs" except django need to be propagated inputs. > o Regarding django: see below > * * postorius: okay (this is an application, so no propagated inputs > are required) > > > And as we just learned about the licenses: python-django-mailman3 should > be gpl3+ Ok. > > I'm unsure about the correct handling of django in django-XXX. Can we > find rules for this to make future packager's life easier? > > Should django be a "normal" input or a "native" one? What does this > depend on? > > > Clear is: django-XXX should not "propagate" django: > > * django is a framework, django-XXX is an extension for this framework. > * If some application is using django-XXX, I'd expect it to have > django specified as "input", too, since primary it is a django > application. Maybe even djangoXXX is an optional component > > > Just for the records: > > * django-XXX should propagate other django extension it requires. > o If some application is using django-XXX, if should not care > about other django extensions django-XXX requires. This is the > same like as it does not have to care about other python > packages django-XXX requires. I'm waiting for further input on the django-XXX issue, then I will rebase and send updated patches. This will be important for the next step, hyperkitty, too. Thanks! -- ng0 . https://www.inventati.org/patternsinthechaos/
Re: postorius, v2
Hi, I just found that I did not verify the inputs carefully enough. Sorry. Here are my comments: * python-defusedxml: okay * python-openid: okay * python-django-allauth: o openid, request-oauthlib requests ought to be propagated inputs o mock is native, okay, but only required for the python2 variant o Why is django a native input? See below for discussion * python-django-gravatar2, may be okay, see below for discussion. * python-django-mailman3 o All "inputs" except django need to be propagated inputs. o Regarding django: see below * * postorius: okay (this is an application, so no propagated inputs are required) And as we just learned about the licenses: python-django-mailman3 should be gpl3+ I'm unsure about the correct handling of django in django-XXX. Can we find rules for this to make future packager's life easier? Should django be a "normal" input or a "native" one? What does this depend on? Clear is: django-XXX should not "propagate" django: * django is a framework, django-XXX is an extension for this framework. * If some application is using django-XXX, I'd expect it to have django specified as "input", too, since primary it is a django application. Maybe even djangoXXX is an optional component Just for the records: * django-XXX should propagate other django extension it requires. o If some application is using django-XXX, if should not care about other django extensions django-XXX requires. This is the same like as it does not have to care about other python packages django-XXX requires. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: postorius, v2
Am 30.01.2017 um 12:22 schrieb contact@cryptolab.net: > Changes: > > Applied what has been previously pointed out by Harmut. > Changed copyright headers. > > LGTM -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |