[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