[Kde-pim] Permission to forward port "folder white listing" from Enterprise branch to 3.5

[Till Adam]

On Wednesday 12 March 2008 23:34:06 Ingo Klöcker wrote:
> On Wednesday 12 March 2008, Thomas McGuire wrote:
> > Hi,
> >
> > On Wednesday 12 March 2008, Allen Winter wrote:
> > > On Wednesday 12 March 2008 01:39:05 Pradeepto K. Bhattacharya wrote:
> > > > Hi Allen, PIMsters,
> > > >
> > > >           Last week, I merged in a folder white listing from
> > > > Proko2 branch into Enterprise branch ( Revision 783244 and 783478
> > > > ). Seeking permission for merging the same into the 3.5 branch.
> > > >
> > > >           Cheers!
> > >
> > > Thomas,
> > >
> > > Let me know if you are ok with this feature.
> > > If so, I will take it to the release team for discussion.
> > >
> > > It sounds partly like a bugfix...
> >
> > It's for the 3.5 branch, which is not maintained by me. Anyway, some
> > things about that feature (I only looked at it very superficially):
> >
> > - It introduces new strings, the translation teams need to give their
> > OK - Coding style like in treebase.cpp makes me cry (all sorts of
> > different indentations, including tabs)
> > - This feature seems to be only relevant for DIMAP, right? If so, the
> > button in the filter dialog should be disabled/removed if there are
> > no DIMAP accounts. Also, when selecting source folders, the normal
> > IMAP folder items are disabled and not checked, which makes me wonder
> > if filtering will still work for my IMAP accounts. Same for my local
> > inbox for POP3. Too confusing in my opinion.
> > - Very minor: FolderSetSelector::selectedFolders() should be const
> > - i18n: "Select Source Folders" should be "Select Source Folders..."
> >
> > As I said, I didn't yet look at the patch in-depth.
>
> You found a lot of things for not having a close look. I don't know
> whether this is good (as in you are good at finding all problems even
> when not having a close look) or bad (as in if a not-so-close look did
> already reveal that many problems, then how many problems need a closer
> look to be detected).

We'll clean the patch up, of course, before merging. This stuff needs to be 
fixed in enterprise branch as well.

> > For a port to trunk, the above points would need to be fixed.
> >
> > I assume it is tested in the enterprise branch, so it probably is
> > reasonable bug-free to port it to the 3.5 branch. In general, I'm OK
> > with it. Ingo, any opinion on this?
>
> Considering the recent corruption of binary attachments which wasn't
> discovered in the enterprise branch for 21 days and was then merged to
> the 3.5 branch makes me very sceptical. As such I don't want any
> feature to be merged to the 3.5 branch which has not been thoroughly
> reviewed and tested. If it has been reviewed and tested, then I'm okay
> with the merge. I'm sorry, but I don't have the time to review it
> myself.

Ingo, there's always a tradeoff between merging new functionality into all 
branches quickly, which helps find regressions faster (as it did in this case) 
and helps us keep the delta between branches as small as possible, and letting 
changes mature in one branch first, before back or forward porting, at the risk 
of many users missing out on things, merging becoming harder, patches getting 
dropped, etc. At the current point in time, where no 3.5 nor trunk release is 
emminent, our approach is to merge quickly, since that seems to be the lesser 
evil. I think 3.5 branch has benefited from that approach overall, for the past 
two releases.

In the case of the attachment corruption the patch was picked up by the 
OpenSuse build service, the resulting packages were tested by adventurous 
users, the problem was found and fixed. In this case this process happened 
faster than the regression testing cycle in enterprise branch, where the bug 
was discovered a few days later. In my view this is Free Software synergy at 
its best and not a problem, unless such regressions creep into releases. That 
doesn't mean that we didn't make a mistake in this case, causing an avoidable 
regression, for which I apologize, but mistakes happen, and there was no harm 
done to all but some bleeding edge users. I'd much rather live with that than 
end up with another proko2 branch, which went so far away from mainline kdepim 
that we are only now able to finish merging the last bits and pieces that went 
only there, namely the feature pradeepto was talking about. It's a feature, 
strictly speaking, which is why I'd be fine with it only going into trunk, not 
3.5, if the maintainers feel it's too much of a risk, or there's not enough 
time to clean up the remaining issues with it before the next point release.

We'll work on the quality of our merges with respect to coding style changes 
etc. Point taken.

Cheers,

Till

(Note: the "we" in the above is the KDEPIM/Kolab team at KDAB, namely myself, 
Volker, Pradeepto, Kevin, Andreas, Thomas, Marc, Frank, Laurent and Jaroslaw, 
with varying degrees of involvement)

-- 
Till Adam
KDAB - platform independent software services
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080316/eabc5dfe/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/