PROPOSAL: New MidCOM commit policy
-
Henri Bergius
PROPOSAL: New MidCOM commit policy
Fri October 10 2008 09:46:59 UTCRagnaroek is now out, and so it is time to put a new commit policy in order. With 2.8 everybody has been bitten many times with nasty breaking changes and regressions, and the plan is to prevent that for the future, while keeping the necessary creative freedom for our committers.
To ensure these policies are functional we will appoint a "VCS tyrant" who will police all incoming commits and revert them if necessary. This worked well for establishing MidCOM coding standards under Torben, and we hope it will work well again. I'd propose Rambo for this.
MidCOM 2.8
With Ragnaroek being new stable, Thor (Midgard 1.8 and MidCOM 2.8) goes to bugfix-only mode. The proposed schedule and limits related to this are:
- October 2008: No breaking changes allowed, commits only referring to bug number and backported from 8.09
- January 2009: No new components
- March 2009: Security fixes only
MidCOM 8.09
Ragnaroek is the LTS version, meaning that maintenance and development will happen in this branch (SVN trunk at the moment) for a long time to come. Therefore, the proposed schedule is quite simple:
- October 2008: No breaking changes allowed, commits only referring to bug number
New components will be welcome to the branch for several years to come.
MidCOM 3
MidCOM3 is the "new world" MidCOM that will be running in the 9.03 Vinland release onwards. To ensure smooth running, we should try to adhere to some rules:
- January 2009: "master" is stable, work happens in feature branches
- April 2009: No breaking changes to core or core components, "contrib" remains a wild west
- June 2009: No commits without corresponding unit tests
Definitions
"No breaking changes": all commits must be backwards compatible. If backwards compatibility needs to be broken, then the component must be forked. Core backwards compatibility will not be broken.
"Feature branches": each new feature or bug fix is worked in its own git branch, and only merged to master when it has been properly tested. Master remains stable.
"No new components": only bug fixes or minor feature additions to existing components are allowed. This is to ensure new work moves to current stable branch.
"Security fixes only": at this point all real work has moved off the branch and only security fixes are done as needed.
"Commits only referring to bug number": Each commit must include referral to corresponding bug in the commit message. This means every new feature or a bug fix must first be reported into the bug tracker.
"No commits without unit tests": Every commit must be covered by a unit test.
Some links
MidCOM coding standards: http://www.midgard-project.org/documentation/concepts-midcom-specs-components-styleguide/
Feature branching with git: http://bergie.iki.fi/blog/feature_branches_in_midgard_development_with_git.html
Midgard synchronized releases process: http://www.midgard-project.org/discussion/developer-forum/read/093499085eed11dd85376322b5d26f366f36.html
PHPunit: http://www.phpunit.de/
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 00:09:37 UTCHenri Bergius schrieb:
> Ragnaroek is now out, and so it is time to put a new commit policy in order. With 2.8 everybody has been bitten many times with nasty breaking changes and regressions, and the plan is to prevent that for the future, while keeping the necessary creative freedom for our committers.
>
> To ensure these policies are functional we will appoint a "VCS tyrant" who will police all incoming commits and revert them if necessary. This worked well for establishing MidCOM coding standards under Torben, and we hope it will work well again. I'd propose Rambo for this.
>
> MidCOM 2.8
> ----------
>
> With Ragnaroek being new stable, Thor (Midgard 1.8 and MidCOM 2.8) goes to bugfix-only mode. The proposed schedule and limits related to this are:
>
> * October 2008: No breaking changes allowed, commits only referring to bug number and backported from 8.09
> * January 2009: No new components
> * March 2009: Security fixes only
>
> MidCOM 8.09
> -----------
>
> Ragnaroek is the LTS version, meaning that maintenance and development will happen in this branch (SVN trunk at the moment) for a long time to come. Therefore, the proposed schedule is quite simple:
>
> * October 2008: No breaking changes allowed, commits only referring to bug number
Well, ideally, there should never be any breakage in SVN, but I'm not
sure if it's not a bit too early for a rule like tat. I bet that half of
the components in the tree were not even run yet on 2.9 or even 2.8 yet
(net.nehmer.jobmarket, anyone?), while others are in need of quite
drastic rewrites (DM1 to DM2 can be quite messy f.x. and hard to
reproduce the functionality exactly). For core components, such a policy
is fine, but I have to admit that I don't really know which ones are
core. The only indication is the distinction made by m.a.babel, but I
don't know if that is really accurate (it sure would be nice if you
could tell from the component name, if f.x. all core components would be
called midcom.core.something, but I guess it's a bit too late for that now).
To make commits refer to bug numbers is a good idea, but it would be
more useful if we had better milestones. F.x. trac says that there are
115 fixed bugs for 8.09, but I have no easy way to know if the fixes are
present in the .0 release, in the .1 release or still only in SVN. Other
projects (like the trac project itself) usually close milestones when a
release is done and reassign all tickets which are still open to the
following point release. With a system like that, you could also easily
generate changelogs, by just copy-n-pasting the list of closed tickets
into the release notes.
But the problem with this approach is that there is not really one
release, MidCOM is at .1 at the moment and Midgard is at .0 while the
components have completely different numbering systems and release
times. Maybe there should be separate milestones at least for MidCOM
core, MidCOM others, and Midgard. Because otherwise, there'd soon be
hundreds of open and closed tickets for the 8.09 milestone without any
real way of managing them.
Bye,
Andreas
>
> New components will be welcome to the branch for several years to come.
>
> MidCOM 3
> --------
>
> MidCOM3 is the "new world" MidCOM that will be running in the 9.03 Vinland release onwards. To ensure smooth running, we should try to adhere to some rules:
>
> * January 2009: "master" is stable, work happens in feature branches
> * April 2009: No breaking changes to core or core components, "contrib" remains a wild west
> * June 2009: No commits without corresponding unit tests
>
> Definitions
> -----------
>
> * "No breaking changes": all commits must be backwards compatible. If backwards compatibility needs to be broken, then the component must be forked. Core backwards compatibility will not be broken.
>
> * "Feature branches": each new feature or bug fix is worked in its own git branch, and only merged to master when it has been properly tested. Master remains stable.
>
> * "No new components": only bug fixes or minor feature additions to existing components are allowed. This is to ensure new work moves to current stable branch.
>
> * "Security fixes only": at this point all real work has moved off the branch and only security fixes are done as needed.
>
> * "Commits only referring to bug number": Each commit must include referral to corresponding bug in the commit message. This means every new feature or a bug fix must first be reported into the bug tracker.
>
> * "No commits without unit tests": Every commit must be covered by a unit test.
>
> Some links
> ----------
>
> * MidCOM coding standards: <http://www.midgard-project.org/documentation/concepts-midcom-specs-components-styleguide/>
>
> * Feature branching with git: <http://bergie.iki.fi/blog/feature_branches_in_midgard_development_with_git.html>
>
> * Midgard synchronized releases process: <http://www.midgard-project.org/discussion/developer-forum/read/093499085eed11dd85376322b5d26f366f36.html>
>
> * PHPunit: <http://www.phpunit.de/>
> _______________________________________________
> dev mailing list
> dev@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 05:59:37 UTCHi,
2008/10/13 Andreas Flack <flack@contentcontrol-berlin.de>:
> I bet that half of the components in the tree were not even run yet on 2.9 or even 2.8 yet
> (net.nehmer.jobmarket, anyone?)
Well, the point is that while some rules are in place, we can still
try to remain sensible. If a component never worked in 8.09, then
there can be no "breaking change" to it, can there ;-)
With the "unproven" components that have fallen out of maintenance we
have basically two options:
* Drop them from SVN and PEAR
* Have somebody adopt them (like happened with org.openpsa.*)
> while others are in need of quite drastic
> rewrites (DM1 to DM2 can be quite messy f.x. and hard to reproduce the
> functionality exactly).
DM1 to DM2 transition can indeed be a bit messy, especially if users
run those components with custom schemas or custom templates. But I
think as that has been accepted as a general goal in the Ragnaroek
branch, we can deal with it.
The important thing is to just let users know well in advance that it
is going to happen. In 2.8, too often such changes (where templates
would be affected) would be noticed only after a "pear upgrade-all"
broke something. Unclear and breaking changes have hurt our reputation
quite badly, and with Ragnaroek we must remedy that.
> For core components, such a policy is fine, but I
> have to admit that I don't really know which ones are core. The only
> indication is the distinction made by m.a.babel, but I don't know if that is
> really accurate (it sure would be nice if you could tell from the component
> name, if f.x. all core components would be called midcom.core.something, but
> I guess it's a bit too late for that now).
It is too late for naming indeed, but in MidCOM componentloader there
is a is_core_component() method to determine this.
In MidCOM3 I think we should keep separate repositories (or at least
separate directories) for core and contrib components.
With Ragnaroek, the rules should be adhered to more strictly when
dealing with core components, but in general we should avoid
uncommunicated and undiscussed breakage also with the non-core ones.
The main point about all this in the proposal is that:
1. Changes should have some communication related to them (i.e. a bug in trac)
2. VCS Tyrant has the final say on what is OK and what isn't
> To make commits refer to bug numbers is a good idea, but it would be more
> useful if we had better milestones. F.x. trac says that there are 115 fixed
> bugs for 8.09, but I have no easy way to know if the fixes are present in
> the .0 release, in the .1 release or still only in SVN. Other projects (like
> the trac project itself) usually close milestones when a release is done and
> reassign all tickets which are still open to the following point release.
> With a system like that, you could also easily generate changelogs, by just
> copy-n-pasting the list of closed tickets into the release notes.
Actually, a good idea. It is much a question on how granular
milestones we want to manage. Anybody else have opinions on this?
If it is desired, I can easily open Ragnaroek .1 and .2 milestones
there and start reassigning bugs.
> Andreas
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 07:29:42 UTCHenri Bergius writes:
> Hi,
Hi!
>> To make commits refer to bug numbers is a good idea, but it would be more
>> useful if we had better milestones. F.x. trac says that there are 115 fixed
>> bugs for 8.09, but I have no easy way to know if the fixes are present in
>> the .0 release, in the .1 release or still only in SVN. Other projects (like
>> the trac project itself) usually close milestones when a release is done and
>> reassign all tickets which are still open to the following point release.
>> With a system like that, you could also easily generate changelogs, by just
>> copy-n-pasting the list of closed tickets into the release notes.
>
> Actually, a good idea. It is much a question on how granular
> milestones we want to manage. Anybody else have opinions on this?
>
> If it is desired, I can easily open Ragnaroek .1 and .2 milestones
> there and start reassigning bugs.
Good option would be to keep all fixed bugs opened till next bugfix
release is made.
But on the other hand, it's enough to commit bugfix with 'Fixes #NNN'
log to mark ticket as fixed.
Minore milestones are good idea, but I am a bit worry if we are able to
keep them up to date.
Other than that +1 from me for minor milestones.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 08:09:01 UTCHi, all
On Mon, Oct 13, 2008 at 10:29 AM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
> Good option would be to keep all fixed bugs opened till next bugfix
> release is made.
That is possibly even harder to keep track of.
> Minore milestones are good idea, but I am a bit worry if we are able to
> keep them up to date.
>
> Other than that +1 from me for minor milestones.
Now that we have the synchronized releases (and possibly VCS Tyrant,
if the proposal is accepted), we need some coordination here anyway.
In 2.8 world we lived in the "wild west" where everybody committed
whatever, and components and their fixes were released whenever. On
the other hand this meant that bugfix releases were "out there"
faster, but it also meant that nobody exactly knew what was fixed, and
what breaking changes were introduced. This made "pear upgrade" like
Russian roulette. The fact that we have MidCOM 2.8.24 tells something.
If we want to get organized, we should really focus on a coordinated
effort here. This means that we should:
* Have a separate bug tracking milestone for each .x release
* Connect all (or most) commits to a ticket assigned to its correct milestone
* Make a coordinated .x release of all affected packages (midcom,
midgard, components)
- Of course, if in that milestone there are no commits to some
package, that package doesn't need to go out
* Maintain proper per-milestone changelogs for each package
(documentation/CHANGES is currently practically dead)
- In future these could maybe be autogenerated from commit messages,
but on release we can also get these from milestone's closed tickets
* Actually announce what issues have been fixed in that point release
(supported by milestone info in Trac)
* Communicate it clearly with users when the next .x release fixing
their issue is due to come out
Of course, the way I'm looking at this is from customer service point
of view. We have gotten a lot of flak about the "wild west" model that
MidCOM has been worked on in past, and a lot of customers have been
pissed off when things suddenly break. If we want to fix that, we need
to work in a more coordinated fashion.
To make things work, we of course need people responsible for various
things. Something that is "everybody's responsibility" often ends up
being nobody's responsibility. I'd suggest the following roles:
* VCS Tyrant: responsible for watching incoming commits and
reverting/correcting faulty ones (Rambo?)
* Bug Manager: responsible for shuffling things between milestones (Bergie?)
* Release Manager: responsible for actually pushing new packages, and
creating the release notes (Piotras)
Now, the challenge is, can we make things more coordinated and still
keep it fun and flexible enough for all committers. I think we can.
> Piotras
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 08:19:58 UTCHi,
On Mon, Oct 13, 2008 at 11:09 AM, Henri Bergius <henri.bergius@iki.fi> wrote:
> * Have a separate bug tracking milestone for each .x release
> * Make a coordinated .x release of all affected packages (midcom,
> midgard, components)
Related to this, I suggest making first coordinated Ragnaroek
milestone 8.09.2, as MidCOM and some components have already slipped
out a .1 release.
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 08:21:56 UTCHenri Bergius writes:
> Hi,
Hi!
> On Mon, Oct 13, 2008 at 11:09 AM, Henri Bergius <henri.bergius@iki.fi> wrote:
>> * Have a separate bug tracking milestone for each .x release
>> * Make a coordinated .x release of all affected packages (midcom,
>> midgard, components)
>
> Related to this, I suggest making first coordinated Ragnaroek
> milestone 8.09.2, as MidCOM and some components have already slipped
> out a .1 release.
That way we loose 8.09.1 minor release :)
I like the way how we can quckly provide fixes on midcom level, if it
workarounds core issues for example.
What about 8.09.x.y versioning for midcom hotfixes?
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 08:24:37 UTCOn 13.10.2008, at 11.09, Henri Bergius wrote:
>
> * Have a separate bug tracking milestone for each .x release
> * Connect all (or most) commits to a ticket assigned to its correct
> milestone
Hi.
I would like to take this idea to future. When MidCOM 3 is out and if
we have concept of "core" components and the contrib ones. I would
like to see that there's no commit to the "core" that is not related
to some ticket.
If you are doing something new in a feature branch there must be a
feature ticket opened for it. This enables us to keep really track
what is happening.
> Now, the challenge is, can we make things more coordinated and still
> keep it fun and flexible enough for all committers. I think we can.
And from this point of view the VCS Tyrant is a must in the future
with the "core" components. Especially if we don't want any
unexpected breaking up of things.
Keeping things fun and flexible the "contrib" components serve that
well I think. It can be the more "wild" west.
If I look this as my point of view, it's not amount of more or less
stable components that are out. It' about good covering set of very
stable basic components + a very stable simple core. And with MidCOM
3 and component heritance even the wild west can benefit this. So
basically this means that more "creative" core service
implementations don't need to reside inside the stable MidCOM's core
code.
- Tero
--
Tero Heikkinen
http://teroheikkinen.iki.fi
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 09:05:46 UTCHi,
On Mon, Oct 13, 2008 at 11:21 AM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
> That way we loose 8.09.1 minor release :)
Yep. This is intentional, as MidCOM managed to release .1 before we
were able to move into this new model. So Midgard has to jump directly
from .0 to .2 :-)
Please note that this new model adds some new responsibilities to you,
as you need to compile the change lists of both Midgard and MidCOM for
that particular .x release, make packages etc.
But I imagine most of these .x's will affect only some components, so
that should be OK. Actually, this is the explanation for why Midgard
skipped 8.09.1, as there simply weren't any fixed bugs to release for
that :-)
As to testing this model, how would 8.09.2 next week sound?
> I like the way how we can quckly provide fixes on midcom level, if it
> workarounds core issues for example.
> What about 8.09.x.y versioning for midcom hotfixes?
+1, though this mechanism should be only used for major bug and security fixes.
> Piotras
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PROPOSAL: New MidCOM commit policy
Mon October 13 2008 10:02:17 UTCHenri Bergius writes:
> Hi,
Hi!
> Please note that this new model adds some new responsibilities to you,
> as you need to compile the change lists of both Midgard and MidCOM for
> that particular .x release, make packages etc.
Yes, but it's not fun using trac's timeline.
> But I imagine most of these .x's will affect only some components, so
> that should be OK. Actually, this is the explanation for why Midgard
> skipped 8.09.1, as there simply weren't any fixed bugs to release for
> that :-)
>
> As to testing this model, how would 8.09.2 next week sound?
Major issues should be fixed by this time, but we need to test them
before releasing.
>> I like the way how we can quckly provide fixes on midcom level, if it
>> workarounds core issues for example.
>> What about 8.09.x.y versioning for midcom hotfixes?
>
> +1, though this mechanism should be only used for major bug and security fixes.
Agreed.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
