>>>> - Less noise in commits: a new feature in SVN sometimes comprises over 20
>>>> commits in
>> ..
>>> The commits are the beats of LyX's development heart, so why kill them.
>>
>> there is actually something on this.
Commits will be still there, just in a less annoying way.
>>
>> its good idea that having some "final" tree where 1 feature=1 commit.
> For bisecting I found it really useful to have not-so-fat commits. The
> bisecting itself is only logarithmic in the number of commits and
> automatable, whereas finding the actual bug in the faulty commit is
> linear in the size of the commit and typically manual.
I would rather see this as: 1 feature = 1 branch that get merged in.
This branch can consist of numerous not-so-fat commits organized in
logical steps.
> I don't think there's something wrong with having a big feature in a
> dozen commits, as long as all of the intermediate versions are working,
> and preferably if the version represent "logical steps".
>
> Preparing some infrastructure, maybe some refactoring, the actual
> feature work and finally enabling it is not an uncommon pattern.
>
Indeed.
> on the other i find the above "beats" important for life of the community
> around dev list, so whatever dev model we adopt some git-commit mailing
> list where things go imeddiately not waiting for some final merged or approval
> feature-commit is must-have imho.
>
>> on the other i find the above "beats" important for life of the
>> community around dev list, so whatever dev model we adopt some
>> git-commit mailing list where things go imeddiately not waiting for
>> some final merged or approval feature-commit is must-have imho.
>
> That's starting to look a bit over-engineered and the need to implement
> an "out-of-band heartbeat notification scheme" might be a problem of the
> primary approach then. It's incidentally less prominent in a "1
> feature = a reasonable smallish number of commits"...
I agree that we need to find some solution here. We don't want people
to work on their own feature, let them make this publicly available,
but to have none of the other developers be aware of his work on this
feature.
Intuitively I would might want something like this:
Create a branch, work on it, work on it, work on it. When I think
the feature is sort of ready or when I want some response or when
I want to let others know about it, I mark this branch as "ready"
which then triggers a mail to lyx-cvs. People see the work done,
comment on it, add things, correct things. During this phase, it
might be useful to involve all developers in the process and notify
them with a mail to lyx-cvs. When a feature is really ready and
will get merged into the stable/release branch a final mail could
be send. So to summarize, you will get something like this:
From: sanda@...
Subject: [NEW sanda/new-2.1-banner] Introduce a new banner for LyX 2.1
branch: sanda/new-2.1-banner (01-05-2011) 2 commits
modification: new
- new-banner: Add a new banner image, banner.png.
- new-banner: Use the new banner in the svn version.
log: This add a new banner because I think we need to change the
appearance for each new major release.
[commits...]
[.. comments and objections]
From: sanda@...
Subject: [UPDATE sanda/new-2.1-banner] Introduce a new banner for LyX 2.1
In-Reply-to: [NEW sanda/new-2.1-banner] Introduce a new banner for LyX 2.1
branch: sanda/new-2.1-banner (01-05-2011) 2 commits
modification: update
- new-banner: Add a new banner image, banner.png.
- new-banner: Use the new banner in the git version.
log: This replace the image by another one, because vfr didn't like
the previous one. Also, I forgot we didn't use svn anymore, so
I changed it to use the banner in the git version instead.
From: maintainer@...
Subject: [MERGE sanda/new-2.1-banner] Introduce a new banner for LyX 2.1
In-Reply-to: [NEW sanda/new-2.1-banner] Introduce a new banner for LyX 2.1
branch: sanda/new-2.1-banner (01-05-2011) 2 commits
modification: merge
- new-banner: Add a new banner image, banner.png.
- new-banner: Use the new banner in the git version.
log: This branch is ready and will get merged into the
release/stable branch in week #6.
- You will get noticed of all new development, so you can
step in early if you are interested
- If a certain feature doesn't really have your interest, you
can safely ignore the updates, and only look at the merge
proposal to see whether things are introduced which look
buggy or on which you really do not agree.
- When you are an expert in a certain area in which a feature
is introduced, you can exactly follow the development by
watching one single thread in your mailbox. This then will
look like:
- [NEW sanda/new-2.1-banner] New banner for LyX 2.1
+ comments
- [UPDATE sanda/new-2.1-banner] Add another image as banner
+ comments
- [UPDATE sanda/new-2.1-banner] Fix the resolution of the image
- [UPDATE sanda/new-2.1-banner] Use git instead of svn
- [MERGE sanda/new-2.1-banner] Ready to merge in week #6
This is just from the top of my head something that might work nicely.
Comments ? Other ideas ?
>
>
>> pavel
>
> Andre'
Vincent
