On 30.11.13 00:43, Richard Tew wrote:
I agree. Restricting changes to the Stackless patch, and backports
that are as original as possible, helps make additional future
backporting easier.
I think we should just keep it simple. Perhaps the following
guidelines incorporating your ideas will do?
1. Someone suggests a backport on the list (with mainline issue number).
2. If the backport is approved, a Stackless issue can be created. At
this point, this just means there's an issue tagging this feature as
approved for future merging given a good merge candidate.
3. Either the person who suggested the backport, or someone with the
time and interest, can pick up an approved backport issue to work on.
Once done, they can submit a push request. If the patch gets reviewed
successfully or a list okay or whatever, then it gets merged.
When it comes to bringing in indirectly related changes in the same
files, common sense should be used. Any approach other than this,
gets a "please follow the process" request. Ill request threads on
the mailing list, should be addressed clearly, then ignored if they
continue.
Cheers,
Richard.
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
I am happy with your answer.
Hopefully, this will serve us in the same way.
For sure, it will not, but I have said what I thought I should mention.
- chris
--
Christian Tismer :^) <mailto:[email protected]>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
