String freeze tomorrow

Hi all,

there will be a string freeze tomorrow for the digiKam project.
Does this mean we create a new branch for that?
Or am I forced to skip any code that involves string changes for nearly 2
months now?
Isn't that a bit long and contra-productive?

Andi
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2009/1/20 Andi Clemens <[hidden email]>

Hi all,

there will be a string freeze tomorrow for the digiKam project.
Does this mean we create a new branch for that?
Or am I forced to skip any code that involves string changes for nearly 2
months now?
Isn't that a bit long and contra-productive?

yes sure... but it's depand of translators team viewpoints. digiKam is a huge application and it's take time to translate.

Perhaps we must ask to kde-doc-i18n ML ?

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

martedì 20 gennaio 2009 alle 15:34, Gilles Caulier ha scritto:

> 2009/1/20 Andi Clemens <[hidden email]>
>
> > Hi all,
> >
> > there will be a string freeze tomorrow for the digiKam project.
> > Does this mean we create a new branch for that?
> > Or am I forced to skip any code that involves string changes for nearly 2
> > months now?
> > Isn't that a bit long and contra-productive?
> >
>
> yes sure... but it's depand of translators team viewpoints. digiKam is a
> huge application and it's take time to translate.
>
> Perhaps we must ask to kde-doc-i18n ML ?
>
> Gilles
>

Does that mean is also for kipi-plugins? In the case can you send an

e-mail to kde imaging ml also?
Argh, i'm almost ready to be back to the net...

Angelo

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia Tuesday 20 January 2009, Andi Clemens napisał:
> Hi all,
>
> there will be a string freeze tomorrow for the digiKam project.
> Does this mean we create a new branch for that?
> Or am I forced to skip any code that involves string changes for nearly
> 2 months now?
> Isn't that a bit long and contra-productive?

Counterproductive is also updating translation 20 times ;)

m. translator from Poland

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2009/1/20 Angelo Naselli <[hidden email]>

martedì 20 gennaio 2009 alle 15:34, Gilles Caulier ha scritto:

> 2009/1/20 Andi Clemens <[hidden email]>
>
> > Hi all,
> >
> > there will be a string freeze tomorrow for the digiKam project.
> > Does this mean we create a new branch for that?
> > Or am I forced to skip any code that involves string changes for nearly 2
> > months now?
> > Isn't that a bit long and contra-productive?
> >
>
> yes sure... but it's depand of translators team viewpoints. digiKam is a
> huge application and it's take time to translate.
>
> Perhaps we must ask to kde-doc-i18n ML ?
>
> Gilles
>

Does that mean is also for kipi-plugins? In the case can you send an
e-mail to kde imaging ml also?

yes, digiKam and kipi-plugins are synchronized...
 
Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2009/1/20 Andi Clemens <[hidden email]>

Hi all,

there will be a string freeze tomorrow for the digiKam project.
Does this mean we create a new branch for that?
Or am I forced to skip any code that involves string changes for nearly 2
months now?
Isn't that a bit long and contra-productive?

Andi,

I'm also agree to create a new development branch for next major release 0.11

It will include :

- Batch Queue Manager code
- icon view pure Qt4 port
- thumbbar pure Qt4 port
- previewwidget pure Qt4 port

Marcel, Your viewpoint ?

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> > Hi all,

> >

> > there will be a string freeze tomorrow for the digiKam project.

> > Does this mean we create a new branch for that?

> > Or am I forced to skip any code that involves string changes for nearly 2

> > months now?

> > Isn't that a bit long and contra-productive?

>

> Andi,

>

> I'm also agree to create a new development branch for next major release

> 0.11

>

> It will include :

>

> - Batch Queue Manager code

> - icon view pure Qt4 port

> - thumbbar pure Qt4 port

> - previewwidget pure Qt4 port

>

> Marcel, Your viewpoint ?

Yes I agree to branch.

With 0.9.x we added a lot of features while incrementing the third number.

This was mostly due to KDE4 development taking a long time.

It's much more common and sane to add major features on major releases, incrementing second number

There are some questions:

What is the time range for 0.11? It's not next month, but it should not in the least take as long as 0.10. Six to twelve months?

What will be done for the 0.10 branch - bugfixes there and forward port, bugfixes in feature branch and backport, features backport?

Branch 0.10 and use trunk for feature development? Branching 0.11 would later mean to branch 0.10 and move or merge 0.11 to trunk

Marcel

>

> Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2009/1/20 Marcel Wiesweg <[hidden email]>

> > Hi all,

> >

> > there will be a string freeze tomorrow for the digiKam project.

> > Does this mean we create a new branch for that?

> > Or am I forced to skip any code that involves string changes for nearly 2

> > months now?

> > Isn't that a bit long and contra-productive?

>

> Andi,

>

> I'm also agree to create a new development branch for next major release

> 0.11

>

> It will include :

>

> - Batch Queue Manager code

> - icon view pure Qt4 port

> - thumbbar pure Qt4 port

> - previewwidget pure Qt4 port

>

> Marcel, Your viewpoint ?

Yes I agree to branch.

With 0.9.x we added a lot of features while incrementing the third number.

This was mostly due to KDE4 development taking a long time.

It's much more common and sane to add major features on major releases, incrementing second number

There are some questions:

What is the time range for 0.11?

not too long (few month)

 

It's not next month, but it should not in the least take as long as 0.10.

agree
 

Six to twelve months?

six max.
 

What will be done for the 0.10 branch - bugfixes there and forward port, bugfixes in feature branch and backport, features backport?

0.10.x only bugfix. no new features (all delegate to 0.11). BAckport of fixes must be done between branches.

 

Branch 0.10 and use trunk for feature development?

Branching 0.11 would later mean to branch 0.10 and move or merge 0.11 to trunk

good question. i think to branch trunk to 0.11 branch until 0.10.0 is released, because, code will become unstable and people know that trunk is 0.10.0 to test. After 0.10.0 release, 0.11 can become trunk and 0.10.x is branched.
 
Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

I just added some more code to the removeredeyes plugin, but now I will not be
able to commit it for 2 months, because it contains new  and altered strings.
I still don't understand why trunk is not trunk in our case.

trunk = newest, unstable code

I mean why not just create a branch for 0.10-rc1 and do bugfixes in there?
And merge them into trunk later on. Is KDE working like this, too?
I can not imagine they don't commit for months into trunk. Maybe I'm seeing
things wrong, but for me this is very contra-productive.

I will need to keep changes in my local GIT branch for now...

Andi

On Tuesday 20 January 2009 22:11:54 Gilles Caulier wrote:

> 2009/1/20 Marcel Wiesweg <[hidden email]>
>
> >  > > Hi all,
> > > >
> > > > there will be a string freeze tomorrow for the digiKam project.
> > > >
> > > > Does this mean we create a new branch for that?
> > > >
> > > > Or am I forced to skip any code that involves string changes for
> > > > nearly
> >
> > 2
> >
> > > > months now?
> > > >
> > > > Isn't that a bit long and contra-productive?
> > >
> > > Andi,
> > >
> > >
> > >
> > > I'm also agree to create a new development branch for next major
> > > release
> > >
> > > 0.11
> > >
> > >
> > >
> > > It will include :
> > >
> > >
> > >
> > > - Batch Queue Manager code
> > >
> > > - icon view pure Qt4 port
> > >
> > > - thumbbar pure Qt4 port
> > >
> > > - previewwidget pure Qt4 port
> > >
> > >
> > >
> > > Marcel, Your viewpoint ?
> >
> > Yes I agree to branch.
> >
> > With 0.9.x we added a lot of features while incrementing the third
> > number.
> >
> > This was mostly due to KDE4 development taking a long time.
> >
> > It's much more common and sane to add major features on major releases,
> > incrementing second number
> >
> > There are some questions:
> >
> > What is the time range for 0.11?
>
> not too long (few month)
>
> > It's not next month, but it should not in the least take as long as 0.10.
>
> agree
>
> > Six to twelve months?
>
> six max.
>
> >  What will be done for the 0.10 branch - bugfixes there and forward port,
> > bugfixes in feature branch and backport, features backport?
>
> 0.10.x only bugfix. no new features (all delegate to 0.11). BAckport of
> fixes must be done between branches.
>
> >  Branch 0.10 and use trunk for feature development?
>
> Branching 0.11 would later mean to branch 0.10 and move or merge 0.11 to
>
> > trunk
>
> good question. i think to branch trunk to 0.11 branch until 0.10.0 is
> released, because, code will become unstable and people know that trunk is
> 0.10.0 to test. After 0.10.0 release, 0.11 can become trunk and 0.10.x is
> branched.
>
> Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2009/1/25 Andi Clemens <[hidden email]>

I just added some more code to the removeredeyes plugin, but now I will not be
able to commit it for 2 months, because it contains new  and altered strings.
I still don't understand why trunk is not trunk in our case.

trunk = newest, unstable code

I mean why not just create a branch for 0.10-rc1 and do bugfixes in there?
And merge them into trunk later on. Is KDE working like this, too?
I can not imagine they don't commit for months into trunk. Maybe I'm seeing
things wrong, but for me this is very contra-productive.

I will need to keep changes in my local GIT branch for now...

Do not change anything. i18n freeze is not yet done. The announce is not yet sent to translators mailing list.

Like i have too some patches where strings are touch, i delay i18n freeze to rc2

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Ok, so I have still some time... good!

Andi


On Sunday 25 January 2009 17:04:36 Gilles Caulier wrote:

> 2009/1/25 Andi Clemens <[hidden email]>
>
> > I just added some more code to the removeredeyes plugin, but now I will
> > not be
> > able to commit it for 2 months, because it contains new  and altered
> > strings.
> > I still don't understand why trunk is not trunk in our case.
> >
> > trunk = newest, unstable code
> >
> > I mean why not just create a branch for 0.10-rc1 and do bugfixes in
> > there? And merge them into trunk later on. Is KDE working like this, too?
> > I can not imagine they don't commit for months into trunk. Maybe I'm
> > seeing things wrong, but for me this is very contra-productive.
> >
> > I will need to keep changes in my local GIT branch for now...
>
> Do not change anything. i18n freeze is not yet done. The announce is not
> yet sent to translators mailing list.
>
> Like i have too some patches where strings are touch, i delay i18n freeze
> to rc2
>
> Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel