[PATCH 1/2] retag: Don't use BaseCommand's stdin/stdout wrappers

Finucane, Stephen stephen.finucane at intel.com
Tue Nov 10 02:53:43 AEDT 2015


> On Mon, Nov 09, 2015 at 03:39:09PM +0000, Finucane, Stephen wrote:
> > > On Mon, Nov 09, 2015 at 03:33:18PM +0000, Finucane, Stephen wrote:
> > > > PS: Since we're talking, if you have time to address the remaining
> > > comments
> > > > on the 'series' series it would be appreciated. I don't want to just
> do
> > > the
> > > > rework without you input in case I miss something. It's one of three
> > > blockers
> > > > for a 2.0 release, along with the Django 1.6 migrations (:() and
> > > interface
> > > > integration of series (Web UI and XML-RPC, until we get REST sorted).
> I'm
> > > > hoping 2.0 should be widely deployed, so it would be a nice kick to
> get
> > > this
> > > > feature in.
> > >
> > > Sorry, I don't have time to look at it.
> >
> > OK. Are you happy for me to rework as appropriate, including notes and
> > sign-offs in commit messages?
> 
> I'd rather you don't change my commits but work on top of them, changing
> details in the db is also going to break compatibility, it'd be best not
> to do it.

I agree and the feature is too important to drop, but I do have concerns. The
only way to address such concerns and still get the feature in is to discuss
them with the contributor or go and fix them myself. They will have to be fixed
in one commit to avoid the additional migration, which is more difficult for us
due to the Django 1.6 support requirement :(

If my points are valid, compatibility should be addressable on your end via a
migration, which will be easier for your fork as you don't need to worry about
Django 1.6? If you can squeeze in time to discuss then please do so. If not,
I'll have to assume my concerns are valid, make the changes myself and break
compatibility to ensure the feature makes it in. The latter option is rather
undesirable, IMO.

Stephen


More information about the Patchwork mailing list