On Fri, 2017-03-24 at 21:36 +0800, Jeremy Kerr wrote:
> Hi Stephen,
>
> > I'd like to move pwclient into its own project/repo/possibly
> > mailing
> > list. There are a couple of reasons for doing this:
>
> I have no specific objections to this (aside from splitting the
> mailing
> list - I think it'd be a mistake to split the potential community
> there), but:
Yeah, I'm not sure about mailing list. I'd rather keep them together,
but I wasn't sure if you could/should use Patchwork for two projects on
the same mailing list?
> > - I want to be able to package this up for PyPi to allow
> > installation
> > with pip
>
> Makes sense; I have very little experience with PyPi, but does that
> mean
> we need separate repos?
I probably should have stressed this more. We don't _need_ separate
repos but the tooling I tend towards makes extensive use of Git for
versioning (pbr for packaging, reno for release notes, pbr+Sphinx for
docs). Being able to bump versions for pwclient independently of
Patchwork would be super helpful.
> > - I want to be able to release new pwclient features to everyone
> > without waiting for their patchwork admin to bump the Patchwork
> > version
>
> I don't see why that needs an update? There should be separate
> channels
> for each of these.
Ah, I was comparing the way we currently expose pwclient (our channel)
with the instance itself (i.e. as a single-file download) to exporting
it via pip. In this scenario, users of a given instance who want the
latest version need to get their instance upgraded or find another, up-
to-date instance. Using pip would provide the separate channel you
speak of.
> > - I want to be able to provide more comprehensive documentation for
> > pwclient, as it slowly morphs into a VCS-independent, general-
> > purpose
> > Patchwork CLI tool
>
> That sounds awesome, but doesn't mean we need a separate repo.
True.
> > - (stretch goal) I'd like to create deb/rpm packages for Fedora,
> > Ubuntu, etc.
>
> Distros should have no issue with producing multiple (installable)
> binary packages from one source package.
Also true. Versioning might be an issue though?
> Overall, I'm not convinced that this is a good idea, but I'm
> certainly not the deciding factor in this :)
I guess the main issue I have with the current setup is that, by
design, Patchwork and pwclient are really separate projects with
different requirements. Not only do they not share code or
documentation, but they have different goals and it is possible to use
different versions of pwclient with different versions of Patchwork and
there's no reason to tie the versioning of each. In the OpenStack
world, this would justify two repos. I don't know how the kernel world
works, but I'd imagine the iproute2 utilities, for example, are kept
separate from the kernel itself?
I was on the fence about another mailing list/Patchwork project and had
to no good technical reason to separate them. Splitting the community
would be a good reason _not_ to, so I think this should not happen.
Separating the repos, however, does make life easier for me and has a
few advantages. Conversely, I'm not aware of any reason not to do this?
Does anything come to mind for you? If not, perhaps we could just split
the repo but keep working off the same list?
Thanks for the input :)
Stephen
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
