Creating 0.9.0 branch ?

[Gilles Caulier]

Hi all,

We have already discuted about future svn branch to use on the future,
especially to use :

- '/trunk/extragear/graphics/digikam/' for future unstable 0.9.0 serie
- '/tags/digikam' for stable serie
- '/branches/digikam' unused.

Fix me if something is wrong here...

But, I have a _MAJOR_ problem on my computer_S_. I use 2 computers to develop
digikam &co.

- My laptop.
- My office computer.

The are large source code repository to sync between these computer, with 3
branchs :

- current (svn)
- 0.8.1 (unstable using image properties sidebar and RAW file support)
- 0.9.0 (unstable like 0.8.1 + Dimage implementation instead imlib2)

This situation is very complex and infernal to manage. I can't continue to
work like this without _LOST_ any codes somewhere !!!

To clean up future digikam developement (and my computers (:=)))), I propose
to create a new 0.9.0 branch (and only one) in svn with only my unstable
0.9.0 implementation and forget definitivly my 0.8.1 implementation for the
future. This is want mean that image properties sidebar and raw files support
on IE will coming only with 0.9.0 release ! 0.8.x will staying on trunk and
only bugs fix will be commited into.

Yes, Tom, this is want mean too that we reproduce the 0.7.x -> 0.8.x branchs
way, and especially the branch merging when we will moving 0.9.0 branch to
trunk.

To resume my idea :

- '/trunk/extragear/graphics/digikam/' == 0.8.x serie with bugfix.
- '/tags/digikam' == only tagging releases.
- '/branches/digikam' == 0.9.0 unstable.

If you have a better solution, please let's me hear.
--
Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Op donderdag 17 november 2005 08:33, schreef Gilles CAULIER:

> Hi all,
>
> We have already discuted about future svn branch to use on the future,
> especially to use :
>
> - '/trunk/extragear/graphics/digikam/' for future unstable 0.9.0 serie
> - '/tags/digikam' for stable serie
> - '/branches/digikam' unused.
>
> Fix me if something is wrong here...
>
> But, I have a _MAJOR_ problem on my computer_S_. I use 2 computers to
> develop digikam &co.
>
> - My laptop.
> - My office computer.
>
> The are large source code repository to sync between these computer, with 3
> branchs :
>
> - current (svn)
> - 0.8.1 (unstable using image properties sidebar and RAW file support)
> - 0.9.0 (unstable like 0.8.1 + Dimage implementation instead imlib2)
>
> This situation is very complex and infernal to manage. I can't continue to
> work like this without _LOST_ any codes somewhere !!!
>
> To clean up future digikam developement (and my computers (:=)))), I
> propose to create a new 0.9.0 branch (and only one) in svn with only my
> unstable 0.9.0 implementation and forget definitivly my 0.8.1
> implementation for the future. This is want mean that image properties
> sidebar and raw files support on IE will coming only with 0.9.0 release !
> 0.8.x will staying on trunk and only bugs fix will be commited into.
>
> Yes, Tom, this is want mean too that we reproduce the 0.7.x -> 0.8.x
> branchs way, and especially the branch merging when we will moving 0.9.0
> branch to trunk.
>
> To resume my idea :
>
> - '/trunk/extragear/graphics/digikam/' == 0.8.x serie with bugfix.
> - '/tags/digikam' == only tagging releases.
> - '/branches/digikam' == 0.9.0 unstable.

I dont agree. The imlib2 replacement is a very big change, which should be
released seperately in the 0.9.0 version.

For almost half a year we can not develop new code because of the upcomming
release, so I want 0.8.1 to at least be free to commit some new features to
which will be difficult to do when 0.9.0 has changed a lot already.

So, I prefer a branch for 0.8.x serie and trunk for 0.9.0 and backport
bugfixes. I would prefer if someone stood up in this room who is willing to
do that.

I do not see any relation between your two computers, the two projects you are
working on and the two branches. In other words using trunk / branch or
branch / trunk does not make a difference in this mess..

Tom

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

[Gilles Caulier]

Le Vendredi 18 Novembre 2005 00:01, Tom Albers a écrit :

> Op donderdag 17 november 2005 08:33, schreef Gilles CAULIER:
> > Hi all,
> >
> > We have already discuted about future svn branch to use on the future,
> > especially to use :
> >
> > - '/trunk/extragear/graphics/digikam/' for future unstable 0.9.0 serie
> > - '/tags/digikam' for stable serie
> > - '/branches/digikam' unused.
> >
> > Fix me if something is wrong here...
> >
> > But, I have a _MAJOR_ problem on my computer_S_. I use 2 computers to
> > develop digikam &co.
> >
> > - My laptop.
> > - My office computer.
> >
> > The are large source code repository to sync between these computer, with
> > 3 branchs :
> >
> > - current (svn)
> > - 0.8.1 (unstable using image properties sidebar and RAW file support)
> > - 0.9.0 (unstable like 0.8.1 + Dimage implementation instead imlib2)
> >
> > This situation is very complex and infernal to manage. I can't continue
> > to work like this without _LOST_ any codes somewhere !!!
> >
> > To clean up future digikam developement (and my computers (:=)))), I
> > propose to create a new 0.9.0 branch (and only one) in svn with only my
> > unstable 0.9.0 implementation and forget definitivly my 0.8.1
> > implementation for the future. This is want mean that image properties
> > sidebar and raw files support on IE will coming only with 0.9.0 release !
> > 0.8.x will staying on trunk and only bugs fix will be commited into.
> >
> > Yes, Tom, this is want mean too that we reproduce the 0.7.x -> 0.8.x
> > branchs way, and especially the branch merging when we will moving 0.9.0
> > branch to trunk.
> >
> > To resume my idea :
> >
> > - '/trunk/extragear/graphics/digikam/' == 0.8.x serie with bugfix.
> > - '/tags/digikam' == only tagging releases.
> > - '/branches/digikam' == 0.9.0 unstable.
>
> I dont agree. The imlib2 replacement is a very big change, which should be
> released seperately in the 0.9.0 version.
>

Well, 0.8.x staying depend of imlib2 ! only 0.9.x (unstable use DImage
instead).

> For almost half a year we can not develop new code because of the upcomming
> release, so I want 0.8.1 to at least be free to commit some new features to
> which will be difficult to do when 0.9.0 has changed a lot already.
>
> So, I prefer a branch for 0.8.x serie and trunk for 0.9.0 and backport
> bugfixes. I would prefer if someone stood up in this room who is willing to
> do that.
>
> I do not see any relation between your two computers, the two projects you
> are working

There is just one project : digikam.

> on and the two branches. In other words using trunk / branch or
> branch / trunk does not make a difference in this mess..

Excepted for i18n. What's the rules about .po files updating using branch
instead trunk for stable release ?

I'm sure that trunk is linked to i18n area using ato script. What the goal for
branches about ? If you push stable to a branch, i18n will not be broken ?

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

[Gerhard Kulzer]

We have a great program here, probably the best in its category, definitively
the best for me, and we should be very proud of it. As we are going for big
steps with 0.8 and 0.9, I want to share some thoughts of mine.
I'm not aware of any 'Leitmotif' for digiKam development as to where do we
want to go, what is the targeted 'user market segment'? Please guide me if
there is one. I also think that OSS should be careful with this kind of beast
of a Leitmotif, flexibility and openness are paramount. Maybe it's enough to
follow the averaged direction of the developers which move like a flock of
birds?
Observing 6 people around me using digiKam and 3 that use iPhoto, they are all
casual photographers, no ambitions, makes me think. If I had to make a list
of what is important to them it would be the following:
1. Ease of use
(no cluttered GUI, logical menu structure, important things in taskbar...)
1a. Easy download of pictures, camera support
(here the hotplug scripts are important, and we have to deal with udev in the
near future)
2. First thing they do after download is a Slideshow
(the interactivity mode of iPhoto in the slideshow would be a 'nice to have'
feature)
3. Cropping and saving the new crop.
(I support the feature discussed at length to keep the downloaded pics by
default untouched as originals, 'normal people' are not so sure about what
they are doing with their files as developers are.)
4. Keeping order and finding the pictures again (here the 0.8 date view and
search dialog has brought about a big plus)
5. Exporting pics to galleries (remote, local and Flikr... )
(people are proud of their photos and want to show them, and want to show off.
The looks [graphical presentation] of galleries is very important. Galleries
produced by digiKam are telling of the Linux world as a whole as well! We can
and must improve here, I'm working on it.)

Me, I am more ambitious and I use all plugins, play around with them a lot. I
feel that Gilles pushes a lot to provide the best algorithms for ambitious
photographers, and I support him a 100% there! So my profile of digiKam
development direction would sound like that:

keep it as simple as possible having in mind the average user, and, at the
same time keep it an advanced tool ahead of the pack for the more ambitious,
for ourselves in the end.

Looking back of where we're going so far, I think we are on the right track. A
nice looking GUI will attract people, will make them install and try digiKam,
but it will not keep them if the functionality is not good.

Thanks for letting me share my thoughts

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

Op vrijdag 18 november 2005 07:37, schreef Gilles Caulier:
> > I do not see any relation between your two computers, the two projects
> > you are working
>
> There is just one project : digikam.

I meant changes in showfoto and dimage.

> Excepted for i18n. What's the rules about .po files updating using branch
> instead trunk for stable release ?

branch/stable is equally treated as trunk.

> I'm sure that trunk is linked to i18n area using ato script. What the goal
> for branches about ? If you push stable to a branch, i18n will not be
> broken ?

Im not sure what you mean, translators should work in branch untill we stop
0.8.x series, copy po over to trunk and translate 0.9.x

toma

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

On 18/11/05, Gerhard Kulzer <[hidden email]> wrote:

We have a great program here, probably the best in its category, definitively
the best for me, and we should be very proud of it. As we are going for big
steps with 0.8 and 0.9, I want to share some thoughts of mine.
follow the averaged direction of the developers which move like a flock of
birds?
5. Exporting pics to galleries (remote, local and Flikr... )
(people are proud of their photos and want to show them, and want to show off.
The looks [graphical presentation] of galleries is very important. Galleries
produced by digiKam are telling of the Linux world as a whole as well! We can
and must improve here, I'm working on it.)

Would like to second on that point, I have very little coding experience for digikam and have more of a user opinion, some kipi-plugins are basically not providing up to the mark service. I include my own flickr export in this category. Sometimes I feel digikams good feature being ignored due to simplicity of other apps and kipi-interface.
Time and again there has been discussion about incorporating digikam tags in to kipi-plugins, there is no good(?) solution yet.
This point has been discussed already but I will put it in a different context, the search feature in digikam is terrific, After searching the images I would probably like to 'apply' some kipi-plugin on them for e.g I might like to export them to flickr or mail them or something in similar way the image selection dialog for kipi-plugins need to changed and re-worked to use the best of digikams feature like searching etc.

Thanks for letting me share my ideas :)

Regards,
Vardhman
--
Blogs: http://vardhman.blogspot.com

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

Op vrijdag 18 november 2005 21:25, schreef Vardhman Jain:
> for digikam and have more of a user opinion, some kipi-plugins are
> basically not providing up to the mark service.

We share the kipi plugins with ~5 other apps. This list is meant for digikam
development and not for kipi-development, please post your comment to the
other list.

> I include my own flickr
> export in this category.

Well, I guess you know how it works....

> Sometimes I feel digikams good feature being
> ignored due to simplicity of other apps and kipi-interface.
> Time and again there has been discussion about incorporating digikam tags
> in to kipi-plugins, there is no good(?) solution yet.

Again, currently me, Joern and Gilles are working on digiKam, we can not
maintain, digikam, showfoto, 20 digikamimageplugins. 10 kipi-plugins,
website, answer questions on irc and read everything on three mailinglists.

If you have a solution for above case, make it, we dont have time.

> This point has been discussed already but I will put it in a different
> context, the search feature in digikam is terrific, After searching the
> images I would probably like to 'apply' some kipi-plugin on them for e.g I
> might like to export them to flickr or mail them or something in similar
> way the image selection dialog for kipi-plugins need to changed and
> re-worked to use the best of digikams feature like searching etc.

The kipi-interface of digikam is not prepared to pass through the search
results atm. I tried to fix that but I have failed, so maybe I will give it a
new try in a couple of months...

So, it is nice that everyone files all kinds of 'i need this', 'i want to
point out that...' and other good ideas, but unless we double the development
team we might not make the progress everyone expects.

Tom

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