>>> On 4/22/2008 at 4:52 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 11:52:03AM -0600, Brad Nicholes wrote: >> >> I am assuming that most if not all of the recent commits that you have > made to trunk should probably be backported to the 3.1 branch. > > most of them are not critical enough to be considered for backport, and the > few that are critical enough are still in the process of being stabilized > for backport. > >> Are you going to submit them for backport? It might be a good idea to add > them to the STATUS file so we don't lose track of them. > > the STATUS file has no place for "work in progress" or "request for > testing/comments" but will try not to lose track of them and post requests > for > testing/comments as needed. > > updated STATUS for this request, so hopefully it will get the > votes/attention > needed. >
That is the purpose of the backport proposal. If you commit a patch to trunk and determine that it should be backported, then enter a proposal into the STATUS file for backport. The idea is that people are suppose to review and test the patch and then vote on whether they believe the patch is stable enough to actually be applied to the stable branch. In other words, every backport proposal in the STATUS file is a "work in progress" or "request for testing/comments". It is a means of making sure that all patches that should be backported are tracked and not lost. Just because a patch as been proposed for backport, doesn't mean that it won't be reworked and replaced with a different patch. But by putting the proposal in the STATUS file, we can track it until it is accepted and applied. Even if it sits there for weeks or months. Also, all backports should follow the version chain. In other words, a backport should rarely ever skip a version. If a patch needs to be backp orted to the 3.0.x branch, it should first go through the 3.1 branch or at least be proposed for backport to the 3.1 branch at the same time. We just have to make sure that we don't cause any regressions due to a patch that was applied to a previous version but got lost in later versions. Brad ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
