Re: [sf-ipf-dev] IPF release cycle model

[Darren R. <da...@re...>]

Saša Nedvědický wrote:
> Hello,
> ...
>
> (3)	the release branch (v4-1-RELEASE) can be safely assumed as HEAD branch
> 	at these days (bugfixes are committed right there first, the regressions
> 	appears quite often)
>   

No, that's not at all true.
There are new features and changes to HEAD that are not on v4-1-RELEASE.

> (4)	the maintanance releases come out in bursts
>   

There's more than one reason for that...
And mostly the reasons for "bursts" is not enough time
to test/compile/build everywhere.

> So let me allow to dicuss problems stated above in more details. I'll try
> to put some proposals how to solve those problems.
>
> (1) There is currently single committer in IPF project.

That's wrong.
Everyone who's part of the project on sourceforge as a developer, 
including you,
is able to commit to the CVS repository on sourceforge.  Currently the 
only other
person who has is from NetBSD (Martti.)

If you wanted to fix a trivial bug (such as the patch I committed today) 
then the
only thing stopping you is you.


> The only way for those
> people to get involved is to ask Darren to integrate their patch. This way
> blocks development of new (potentially major features), which require more
> significant change (i.e. rpc rules for IPF, better stats, ...)
>
>
> (2) any change should be recorded in bugtracking system. each change coming to
> HEAD must have a BugID in commit comments. the commit without BugIF should
> be back out. even if change is just code clean up it should be recorded in
> bug tracking system (BTS). The BTS currently runs on sourcerforge.
> This is the only strict rule in fact, but it is very reasonable if there are
> considered more than one single developer participating on project.
>   

Before making such rules, you need to understand that there are exceptions.

For example, the HISTORY file and others with the version number are 
updated for every
release.  This requires a committed change in CVS.  It is silly to have 
a bugid for that.
So (2) needs to be waived for release engineering.

> (3) every change must appear in HEAD first, no excuse.

I disagree.  Sometimes a change is only relevant to a release branch.

> (4) the only person who will decide to release new maintanance release (the
> release from RELEASE branch) is RELEASE branch maintainer. He should try to
> establish some regular release cycles - every two months or so. it will help
> users to track when bugfix for bug they eventually reported will be available.
>   

There are three factors that influence when I do releases at present:
1) release cycles of BSDs
2) the nature of bugs that have been fixed but are not in a release
3) time

At the moment, there should be a 4.1.29, and maybe on the weekend
I'll do this, because there have been some important changes for FreeBSD
and it should really have 4.1.29 (and not 4.1.28) as the version number
that will be in FreeBSD 6.3 and FreeBSD 7.0.

So moving on...

On the topic of patching and developing IPFilter, I'd like to propose that
we set up a web page, say ipfilter.sourceforge.net/changes or something
else and upload diff files converted to html that have proposed changes
to review for non-trivial fixes.

Darren