Re: enhance release experience

Gil Forcada Codinachs <[email protected]>
Newsgroups gmane.comp.web.zope.plone.devel
Message-ID <CAKSaQ19_MmeT4Bfr88pUx=-9=k1b8hYshey4rSaDEx2WXXwyAA@mail.gmail.com>
2014-11-19 12:07 GMT+01:00 Jens W. Klein <jens-/[email protected]>:

> On 2014-11-18 00:24, Jens W. Klein wrote:
> [...]
> > 2)
> > use a MANIFEST.in. Seriously. It seems we just do NOT need it at all.
> > Delete it. Current setuptools seems to work fine w/o, includes all
> > files, given a release is done from a tag checkout (as we do with
> > zestreleaser, jarn.mkrelease, ...). Just add only files meant for
> > release in git, manage your .gitignore careful. Then -  using
> > include_package_data=True, all is in.
> > see also https://twitter.com/narocz/status/534404233827983360
>
> So it seems we have different opinions around here - so boths (using vs
> skipping) have it pros and cons.
>
> MANIFEST.in it is fine if some rules apply. In past I used it for all of
> our packages and its fine. Otoh it is the source of brown bag releases.
> We may consider adding a manifest/ package install check into the
> zestreleaser chain.
>
> It is always a good idea to keep structures simple and follow some
> conventions, so a MANIFEST.in in plone.* must look the same everywhere.
>
> Next I see sometimes a mix between README.rst and documentation. Having
> a docs directory is fine, as long as theres documentation in. I dont see
> the point to put the magic triple of README, CHANGES and LICENCE file in
> there. Having those in the root on your fingertips does not only save
> one click, since the amount of files on root level is small, it also
> doent not reduce the package overview.
>
> So long I propose to keep things simple. Even in cases where /docs
> contains real (sphinx) configuration I'am the opinion that a
> documentation title page has a different target group than a package
> README. So DRY does not apply


So let's write some docs (on plone.api/documentation?) about packaging
layout,
as one can imagine, I'm also really interested in making things as obvious
and as
consistent as possible across the board (i.e. in all core packages) and to
have that
written down so whoever comes later on has a handle and some information
about why
things where done in that way or how to do it on its own.

Cheers,
Gil



> Jens
> --
> Klein & Partner KG, member of BlueDynamics Alliance
>
>
>

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.