Hello,
let me post some non-technical topic within this post. I want to start some
discussion (not flamewar) about IPF release policy/source code maintanance etc.
I see there are those problems in IPF project:
(1) there are no writen rules set up if any one (except Darren) would like
to submit/comitt his own source to IPF.
(2) not all changes in CVS are linked to each commit
(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)
(4) the maintanance releases come out in bursts
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. However there are
definitely more people, who are interested to add some new feature to IPF
or improve IPF or just to help with bugfixing. 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, ...)
to change this some approach similar to *BSD models should be used.
there will be a HEAD branch and RELEASE branch. Any IPF developer can commit
to HEAD branch (bugfixes, features, clean ups, anything goes to HEAD first).
the RELEASE branch maintainer takes patches from HEAD and applies them to
release. the only man, who can commit to release branch is RELEASE branch
keeper (maintainer) no one else is allowed to do so.
the only rule should be applied to HEAD: the HEAD must compile at any time,
the commit, which breaks a build on any supported platform must be fixed ASAP
or back out.
(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.
(3) every change must appear in HEAD first, no excuse. Only release branch
maintainer will decide when the fix will be also integrated into release
branch. I have no idea it is possible to clone bugs in bug tracker at
sourcerforge but the workflow example in terms of bugfix can be as follows:
user reports bug -> BugID
developer fixes bug and commits change to HEAD. once fix is commited
and works developer will clone and closes the original BugID reported
by user. BugID -> ClnBugID
(disclaimer - I have no idea whether it is possible with BTS at
sourceforge,
the idea is to have two related bugs - one for HEAD, the second one
for RELASE branch)
RELEASE branch maintainer should consider whether the bug is 'critical'
enough to let the fix go into release. if it is critical/serious bug,
it should be integrated there and ClnBugID should be closed, if the bug
is not serious enough to let fix to appear in RELEASE branch, the
ClnBugID
should be closed as Won'tFix.
don't know if it is possible to set up such workflow with tools provided by
sourcefroge, but we should try to achieve the best we can.
(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.
so this just a topic to provoke a discussion about IPF project in more general
level.
regards
sasha
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ipfilter-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ipfilter-devel
