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
signature.asc
Description: PGP signature
_______________________________________________ Calypso mailing list Calypso@keithp.com http://keithp.com/mailman/listinfo/calypso
