[Calypso] calypso projecet organization

[chrysn]

ad commit styles:

On Sat, Jan 30, 2016 at 09:50:05PM +0100, Guido Günther wrote:
> Personally I'm a fan of either mailing lists or gerrit (the later
> supports your above workflow nicely plus running tests).
>
> That said your style is also doable with one mail per commit (which
> is nice for reviewing things) since it only applies to patches from
> people without commit access that can easily be imported to git with
> e.g. mutt in one go.

seems like i just need to brush up on my mutt+git skills. (the way you
talk about it gives me the impression i'm just doing things in a
cumbersome fashion so far.)


ad bts:

> I always (implicitly) assumed we'd use the Debian BTS for that.

fine, i'll make sure to have this in a how-to-contribute section on the
webpage.

On Sun, Jan 31, 2016 at 12:14:29PM +0100, Petter Reinholdtsen wrote:
> I believe the Debian BTS should be used, but it only make sense if the
> Debian version and the alioth git version are close to each other.

i don't think that this is a hinderance. `reportbug` might want to
dissuade you from filing a bug report if you don't have the package
installed, but in general, bts accepts a report without an attached
version.

we can mark bugs as "pending" when they are fixed in master, and they
get closed by uploading a version to debian.


ad web page:

On Sat, Jan 30, 2016 at 09:50:05PM +0100, Guido Günther wrote:
> That's perfect, even more if we keep it in a repo on alioth too and
> generate it from e.g. markdown (e.g. using ikiwki). I have this on
> my todo list since quiet some time. Same goes for creating a commit
> mailing list on alioth and setting up the hooks.

On Sun, Jan 31, 2016 at 11:40:40AM +1100, Keith Packard wrote:
> I've been doing a pile of docs in asciidoc  these days; it generates
> html quite easily, and if you're cautious, the source can remain
> readable.

and my restructured-text. (wait, is this not the plain text markup
shootout? oups, wrong mailing list...)

more seriously: any of that will do as long as it's only README and
maybe CONTRIBUTING, INSTALL and a fleshed-out user guide.

i don't expect that we'll have much documentation generated from the
code (that's where ReST would shine, library documentation with sphinx).


ad python-vobject:

On Sun, Jan 31, 2016 at 03:16:35PM +0000, Jelmer Vernooij wrote:
> It would be nice to keep it as a separate Python package so others can
> use it (rather than e.g. embedding in calypso), but taking it under
> the calypso umbrella seems like a good idea to me.

sure, separate package and api and everything, just shared project
infrastructure.


ad releases:

On Sun, Jan 31, 2016 at 11:40:40AM +1100, Keith Packard wrote:
> I think the only remaining issue is how to manage releases; I'm afraid I
> don't have the time to deal with that myself.

i'd suggest we use a similar process as for patches, just with more
required "+1"s.

as the project is rather debian heavy, i figure that uploads to
experimental make good ways of publishing release candidates.


On Sun, Jan 31, 2016 at 12:14:29PM +0100, Petter Reinholdtsen wrote:
> So I would suggest to drop the patch review process on the mailing list,
> allow the core developers (the current project admins, perhaps?) to
> commit directly and make sure all commits result in an email to a
> commits mailing list.

unless participation in the project dies down significantly, i think we
should stick to it -- apart from plain code quality, i fear that calypso
could otherwise be prone to feature creep.


best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://keithp.com/pipermail/calypso/attachments/20160203/11c975e6/attachment.sig>