[Aptitude-devel] On working together (was: On reviews, supervision, etc)
abe at debian.org
Wed Feb 5 14:42:08 UTC 2014
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
* 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
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
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.
,''`. | 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...
Size: 198 bytes
Desc: Digital signature
More information about the Aptitude-devel