policy change related to kdelibs snapshots

[David Faure]

On Monday 10 July 2006 20:11, Cornelius Schumacher wrote:
> On Monday 10 July 2006 18:57, David Faure wrote:
> >
> > There's just one downside to Cornelius's proposal: we lose the granularity
> > of svn logs then, in the kdelibs-trunk history. All changes get merged
> > every 2 weeks, in one go.
> 
> I tend to think that the history of bug fixes is more interesting than the 
> history of new feature development or big refactorings.

That's rather arguable... sometimes you want to see why something was changed
a certain way during the development of the new stuff, or the commit with all
the details about a refactoring....

> What happens to changes done to the snapshot branch? Are they merged back to 
> trunk or are they just overwritten?

I don't think this would change; as long as it's called snapshot, it's just that and no
development branch.

> An app developer using the stable branch of kdelibs might do the occasional 
> bug fix in the libs, but probably doesn't have the development branch of the 
> libs checked out to port patches.

This seems to work ok already, where people either commit fixes
to both branches (no need to do a full kdelibs trunk compile just to apply
a bugfix from snapshot), or ask someone else to commit to kdelibs-trunk.

If you think we'll get many many bugfixes in snapshot we can rethink this, but up
to now it wasn't necessary. Having the bugfixes asap in trunk is good, too....
In theory most of the code should be unit tested anyway :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).