Patchwork v2 and beyond

Stephen Finucane stephen at
Wed Jun 28 21:40:04 AEST 2017

On Wed, 2017-06-28 at 12:17 +1000, Daniel Axtens wrote:
> Hi Stephen,
> > Yes and no. We're on RC4 already, which is kind of mad. If you look at the
> > RCs we've been releasing, most of them have been more about adding features
> > to fill holes or oversights than fixing bugs. I'm concerned that if we
> > continue on this trajectory, new features will keep coming in and we'll
> > never get the release out. To be honest, at this point I want to just merge
> > the "single patch as series feature" and, barring any serious issues from
> > the below, release a final version. We're not Debian, but we've done a lot
> > of real world testing with popular mailing lists and found very few issues.
> > If we do encounter some later, I'm more than happy to make PATCH releases
> > as required. I'll hang on for the fuzzing results, but after that I really
> > want to cut this and move on to getting it deployed and used in the real
> > world.
> Yeah, I understand that and I think we'll probably get away with it this
> time without any major issues. In hindsight, I think we probably needed
> to call a feature-freeze explicitly. I kind of assumed the rc process
> would do that because that is how it works in kernel land, but that
> hasn't been what ended up happening. In hindsight, I probably should
> have kicked off this discussion before the start of the rc process.

Hmm, I'm not sure think a feature freeze was necessarily the solution, as most
of the changes that have gone affected the API responses/behaviour and could
not be merged in a separate release (at least, not without immediately bumping
the MAJOR version of the API in the next release and making folks write clients
to handle both). However, the significance of the changes between rc1 and rc4
(and soon, rc5) suggest that "release candidate" was the wrong messaging. Maybe
alpha and beta tags would be a more appropriate solution next time we're making
a MAJOR release like this?

> > ** REST support for pwclient
> > 
> >    See notes above. It's worth mentioning that I've already started work on
> > separating out pwclient into its own Git repo, but I plan to continue to
> > use
> > the same mailing list for patch, bugs, etc. This leads us to...
> It would be nice to make it pip install capable and/or putting it in a
> PPA on launchpad so people can apt-get install it. Happy to help with
> that.

Yup, that's the plan, and my wish to use Git metadata for versioning is a
primary driver of the split. I've already got the name registered on PyPi so we
can do this in the near future.


More information about the Patchwork mailing list