[Calypso] calypso projecet organization
chrysn
chrysn at fsfe.org
Sat Jan 30 08:57:39 PST 2016
hello callypso list,
i'm delighted that the calypso project is seeing more activity, and i've
finally found the time to read up on what has been posted here, and
getting an overview of the current branches again.
in parallel to polishing up on my patches, where petter has already
started good work, i'd like to discuss a few general-direction things
about how to keep developing calypso:
* committ access: it seems to have become common practice for even
people who do have commit access (right now, that'd the alioth project
members guido, jelmer, keith and myself) send their patches to the
list, and if there is a LGTM / +1 from someone else and no "let's
discuss" / -1 from anyone, it gets pushed to alioth/master.
this seems like a good workflow to me, especially as pushing something
to master doesn't mean it stays there irrevocably / until the next
release, but gives a good flow of changes in general.
* project membership: i'd keep that rather lose, as long as the above
flow is used. (for example, based on his initiative and posts on the
list, i wouldn't hesitate to accept petter's pending membership
request).
currently, it's all admins on alioth. i think that's ok for now; it's
not like we could differentiate between who may upload a signed tag
and who may edit the web page (see below) anyway, at least i didn't
find options to that respect in the gui.
* commit styles: i'm a big fan of --no-ff merged topic branches, as it
retains the granularity of "commit often" while still being viewable
as a single change as well -- but that becomes a bit impractical when
sending patches one-mail-per-commit style, and is more easily reviewed
by pushing the commit to a branch or personal repo (alioth allows
users to request a /git/calypso/users/${USERNAME}.git repo).
guido, what's your stance on that style of pull requests, would it
work for you? (afair you expressed a preference for mailed patches).
* issue tracking: so far, most recent issues are directly addressed by
patches on the mailing list, that's imo harder to keep in overview
than a proper issue tracker. as things are, options are keeping all
issues on this list, opening an alioth tracker or using the debian bts
as if calypso were a native package (which i'd prefer). what are your
views?
* web page: the current best web site of calypso is
<http://keithp.com/calypso>, which being part of keith's personal
website is hard to keep current. we do have an address and web space
on alioth <http://calypso.alioth.debian.org/> at
<file://alioth.debian.org/srv/home/groups/calypso/htdocs>, which is
also configured as the project's home page, but empty.
i'd offer setting up a built-from-a-pimped-README web page and linking
there, any objections?
* python-vobject: calypso deeply depends on python-vobject, which is
practically dead upstream. i'd like to take over the library
development (or maintenance), and polish up the python3 branch there;
the calypso project seems like a good umbrella to that, and i'd apply
all mechanisms we're using here to python-vobject too (not sure how
well alioth supports having two project names in one project, i'd
figure that out on demand). any objections there?
best regards, and thanks for your time
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/20160130/c9b16193/attachment.sig>
More information about the Calypso
mailing list