Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 02/01/2014 14:35, IKEDA Soji a écrit :
> Year, but current trunk seems not really working (I suppose).
>
> sympa-6.2-branch has been rollbacked.  The steps I hoped to propose
> after vacation are:
>
> 1. Merge fixes in sympa-6.1-branch to sympa-6.2-branch and than trunc.
That"s OK for me.

> 2. Apply reordering and renaming on sympa-cleanup branch to current
>    sympa-6.2-branch.  Then, merge it to trunc.
The sympa-cleanup branch is dead, and that's way too much work to try to 
fix it. According to our previous discussion, we were supposed to leave 
it in its current state, and instead replay the changes to the trunk 
branch, progressively and in controlled and reviewed manner.

And while waiting for #1 to complete before starting #2 would probably 
make it easier, that's exactly the kind of 'mandatory task 
serialization' we can't afford without locking ourselves: I've not 
enough knowledge for doing it myself, and just because I've available 
free time right now to cleanup my late work queue doesn't ensure I'll 
also have it tomorrow :)

Hence my proposal to just perform minimal cleanup we all have agreed so 
far on trunk, and eventually on 6.2 also if wanted.


> 3. Begin to add new features (including what rollbacked in old
>    sympa-6.2-branch) to current 6.2-branch.
>
> 4. New functions will be merged to trunk in near future.

> > > But unfortunately, I'm in new year vacation (in Japan, a few days
> > > before and after arrival of new year, all works in the country
> > > stops).  Please give me a few days to respond you.
> > );
> > As we all have strongly disconnected schedules, this won't scale much if
> > we have to wait each other approval before every single move. My
> > unability to work on sympa during last two monthes, and even just to
> > contribute to the discussion, for instance, is a perfect example of
> > preventing everyone else if we apply this model too strictly.
> >
> > We use a version control system, allowing to eventually revert changes
> > if needed, and we have post-commit notifications, allowing peer code
> > review. I think that make pretty safe to commit at least trivial
> > changes, and discuss them thereafter if really needed. Of course,
> > everyone has a different understanding of what 'trivial' means :)
>
> You are right.
>
> But now we (you and I) have all privileges on Sympa repository tree.
> Probably you may create a now branch to modify current codes,
> test new idea and propose comments on it (I can be wrong, because I
> haven't checked it).
As long as we use subversion, this is technically difficult: creating 
branches requires admin privileges on subversion repository. And merging 
branches is still a difficult task. This should be far easier after 
switching to git, but that's not yet ready.

And while branches would indeed be interesting for testing experimental 
features or refactoring, I don't see any advantages for simple cleanup 
task such as enforcing a consistent file header with uptodate copyright 
informations, for instance.
--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

Attachment: smime.p7s
Description: Signature cryptographique S/MIME