[Aptitude-devel] On working together (was: On reviews, supervision, etc)

Wed Feb 5 14:42:08 UTC 2014

Hi,

I must admit, I only have read the "tl;dr" part of the mail I'm
replying to, but I'm sick of these heated discussions despite I think
I can understand both sides. (I may read that later but I think I
already have read enough mails in the past few weeks to have an idea
where the different views clash.)

I would like to de-escalate the situation and to come to some common
ground so we are all able to get working on aptitude again.

The following workflow is based on the these ideas:

* If someone wants to review changes by others, he should have a fair
  chance to do that.

* If somone thinks, he has a better solution, he should have a fair
  chance to show that.

* If someone has no time, this should not hinder others to continue
  their work.

* If someone works on long-term features, this should be visible.

* Try to get some consesus instead of having someone playing "boss".

* It should be able to do bug-fixes in a "release early, release
  often" style.

So I propose the following team workflow:

* Minor and obvious bug-fixes intended for the next upload should go
  directly to master or debian-sid (depending if they target upstream
  or packaging code) without any review or similar. In case of doubt,
  use a feature branch. (See below.)

  All bug-fix-only releases should have urgency=medium or urgency=high
  depending on how critical the contained bug fixes are.

* Features or invasive bug fixes should be developed in a feature
  branch, preferably named <username>/<feature> or
  <username>/debian-<feature> depending if they target upstream or
  packaging code, e.g. "abe/german-doc" or "abe/debian-german-doc".

  Unless stated otherwise by the owner of the branch, please do not
  commit stuff to someone else's feature branch without an OK of the
  owner. Use your own feature branch with the same feature name in
  case of doubt.

* As soon as its author thinks the feature is ready for inclusion, he
  writes an e-mail to the according bug report or, in case of no
  related bug-report, to the aptitude-devel list directly, including

  + Either a link to a branch or a single commitdiff on
    anonscm.debian.org, or with a single git formatted patch attached.

  + A short description of what the patch or the commits in the branch
    do. If the patch is attached, the included commit message should
    suffice.

  If there's no objection against the proposed patch within 6
  days(*) or if there's a _consensus_ anyway, the branch may merged
  into master, debian-sid or in one of the feature fe branches.

  If you have objections, please provide an alternative patch in your
  own feature branch and send that for review, too. If there's an
  objection without alternative patch for more than 7 days(*), the
  feature branch in question may be merged anyway.

  For now I'll leave explicitly open what happens if someone thinks
  that a feature should not included in aptitude by all means and the
  author of the patch disagrees, or if we have two opposing
  implementations whose authors object the other's patch -- because I
  really hope that we are all sane enough to not let it come that far.

* Finetuning of already merged branches should preferably be continued
  in the feature branch which is then later merged again, probably
  with a shortened review interval.

* There may be seperate branches for new feature releases. They should
  be handled like the master branch.

* Branches should be pushed at least once a day if they received local
  changes, so that others (also people outside the team) can see
  what's happening in aptitude and can review it if they want.

* If you commit code written by someone else, please properly
  attribute it by using "git commit --author='Name <email>'" (if not
  already given in a merge request or git formatted patch).

* If you're not (yet) a team member, you're welcome to contribute
  anyway and publish your feature branches elsewhere, either on Alioth
  under the "user/" hierachy or on Gitorious, GitHub, etc. or on your
  personal Git server. Be sure to include a working URL to anonymously
  pull your changes in that case.

I hope this allows everyone to contribute without the need of heated
discussions and avoids that the general development of aptitude stalls
again despite there is someone who wants to continue working it.

(*) Other timeframes are debatable, but I don't think anything less
    than 2 days or more than 10 days makes sense. 6 days would allow
    to merge code written on Sunday late evening to be merged on next
    Sunday in the afternoon, hence without time pressure in the
    evening and 7 days include one full week-end of time in any case.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20140205/6b05b4d3/attachment.sig>