phatch-dev team mailing list archive

[Stani <spe.stani.be@xxxxxxxxx>]

Hi All,

Phatch 0.1 started as a one mans project. That was fun. Phatch 0.2
made the transition to a multi-person team effort. That is even more
fun! This requires to adapt to optimize the workflow for which I
unfortunately had no time during 0.2 as we needed to finish the
release. Now finally I found some time and read everything about
launchpad and bazaar I could. I will spare you the details and give my
conclusion. Also I will give some pointers to links everyone should
read.

LAUNCHPAD

We already used series. Series are related to big version numbers such
as 0.1, 0.2, 0.3, ... Blueprints have to be associated to series. So
if we think a feature belongs to 0.3, you should mark it in launchpad.
A level below are milestones for example 0.2.1 and 0.2.2 Milestones
get assigned a selection of blueprints and bugs which have to be fixed
or implemented. Milestones are potential releases. So a milestone is a
target we want to reach at a certain point and probably it will be
released. It is very important to assign blueprints and bugs to a
milestone as otherwise it won't be on the radar. Bug reports in
general have to be associated immediately to the next milestone as we
want to fix bugs immediately. Special exception are Windows bugs which
we will fix in special Windows milestones if they require a lot of
work. These bugs are marked as 'Triaged' and will be fixed in the near
(not immediate) future. I won't require to target bugs to series as
from my evaluation it creates a lot of overhead and it is not so
efficient.

So to give an overview of bug status:
- Incomplete, Invalid, Won't Fix: no milestone needed
- Confirmed: needs milestone, will be fixed at a certain milestone
- Triaged: no milestone needed, same as confirmed but will be fixed in
the near, unknown future
- In progress: needs milestone, will be fixed at a certain milestone
- Fix committed: needs milestone, is fixed for the next milestone
- Fix Released: needs milestone, is fixed for the next milestone

Conclusion:
- blueprints: assigned to milestones and series
- bugs: assigned to milestones (series optionally, but not at all required)

Blueprints and bugs should start with a capital character (not
lowercase) as we like aesthetics ;-)

Mostly we will always make a stable release for Linux first, as this
tied to an external planning (Ubuntu release cycle). We will make a
Windows/Mac version afterwards. This might change when we have a
py2exe/py2app framework ready and a release does not trigger cross
platform regression.

Please read this document carefully:
https://help.launchpad.net/Projects/SeriesMilestonesReleases

So the next milestone is: 0.2.2 and is a bug fix release for Linux.
Probably 0.2.3 will focus on Windows/Mac.
https://launchpad.net/phatch/+milestone/0.2.2

BAZAAR

For each series we have a separate stable branch. For example for 0.2:
lp:phatch/0.2

Development happens in trunk:
lp:phatch

The trunk should already be as stable as possible. In phatch 0.1 and
phatch 0.2 I used trunk as my personal branch, from now on I will work
separate from trunk as everyone to garantuee the trunk is always in a
stable state. Before you request a merge from the trunk, you need to
do the following steps:
1) merge your branch first with trunk and resolve any conflicts
2) run test_pep8 to check if your code is pep8 compliant
3) run nadia's test suite to see if your changes don't break existing code

Please only request a merge after these steps. I will act as a human
gatekeeper to fix obvious errors, but please test your branch
thoroughly yourself. I expect that any merge with trunk is error free
before merging. That's your own responsability. We are getting too
many, so everyone needs to take up responsibility.

The naming of the branches should reflect the features you work on.
For example this is no longer allowed:
lp:~nadiana/phatch/phatch-dev -> change it into: lp:~nadiana/phatch/test-suite

These are good examples:
lp:~trbs/phatch/bugfixes
lp:~trbs/phatch/uniconvertor	
lp:~trbs/phatch/multiprocessing
lp:~bebraw/phatch/blender

Don't worry about your history. Everything which is merged in trunk
will be recorded.

Until now everyone used private branches (lp:~user). This is fine if
you want the only access to the branch. However if you want to open
your branches for collaboration, please upload them to lp:~phatch-dev.
In that case everyone of the phatch-dev team can participate. For
example:
lp:~phatch-dev/phatch/blender

You might consider stacked branches, for example:
branch --stacked lp:phatch

This will not download the whole branch but enough to work with. On
the other hand for many commands which involve history such as diff,
log, ... you will need to be connected to your parent branch, which
might require an internet connection if is remote (such as lp:phatch).
What I do now is to branch lp:phatch normally and to uses stacked
branches for the different features:
bzr branch lp:phatch
bzr branch --stacked phatch blender

Read more about stack branches here:
http://doc.bazaar-vcs.org/latest/en/user-guide/stacked.html

Lately most developers write me personally instead of to phatch-dev.
While I like personal attention, I think most of these conversations
better can happen on phatch-dev, so everyone can follow. It is no
problem to send me personal emails, but please make a conscious
distinction. If I feel certain conversations belong to phatch-dev, I
will reply to phatch-dev instead. If there are mails you don't want to
appear on phatch-dev let me know. I don't want flame wars on
phatch-dev, which luckily did not happen. I would prefer flame wars to
be settled in private emails rather than on phatch-dev.

We should try to release more early and often. The big releases like
0.1, 0.2, 0.3, ... could happen every 6 months, while micro releases
should happen more often. We need to finish 0.2.2 as soon as possible.
If you plan to do rewrites, please do it in a separate branch. For
0.2.2 the changes should be as minimal as possible. Most of you have
work to do, go for it!
https://launchpad.net/phatch/+milestone/0.2.2

Best regards,
Stani

-- 
Phatch Photo Batch Processor - http://photobatch.stani.be
SPE Python IDE - http://pythonide.stani.be