kdesupport changes

Re: kdesupport changes

On Tuesday 02 September 2008 10:01:48 Benoit Jacob wrote:
> Hi,
> 
> I just found out these discussions on the release-team list, to which I was
> not
> subscribed:
> 
> http://mail.kde.org/pipermail/release-team/2008-August/002395.html
> http://mail.kde.org/pipermail/release-team/2008-August/002433.html
> 

> 5. After we create a tag does that mean that we can do whatever we want
> in /trunk/kdesupport/eigen2 without risking to break compilation for other
> people? This is related to question 1. As long as we tell people to use
> trunk/kdesupport, making tags is rather pointless.
> 
That was the idea.  And I think toma supported me.
But there has been a lot of push back from the kdesupport authors.

IOW: no decision yet.

I suspect we continue going on as usual until further notice.

Re: KDE 3.5.final?

On Friday 29 August 2008, Allen Winter wrote:

> I expect KDAB will continue doing the best they can for kdepim enterprise.
> But the rest of the kdepim team will be moving onto KDE 4 and I plan
> to tightly monitor the kdepim 3.5 branch and stop anything but the most
> obvious bug fixes there.
>
> IOW: branches/KDE/3.5/kdepim is essentially frozen.

I'm confused. Stephan said that it is fine for him to have kdepim being 
developed in KDE 3.5 branch, and you're saying that kdepim should not be 
developed in KDE 3.5 branch but in enterprise3 branch. 

Greetings,
Dirk

Re: KDE 3.5.final?

On Friday 05 September 2008 05:59:27 Dirk Mueller wrote:
> On Friday 29 August 2008, Allen Winter wrote:
> 
> > I expect KDAB will continue doing the best they can for kdepim enterprise.
> > But the rest of the kdepim team will be moving onto KDE 4 and I plan
> > to tightly monitor the kdepim 3.5 branch and stop anything but the most
> > obvious bug fixes there.
> >
> > IOW: branches/KDE/3.5/kdepim is essentially frozen.
> 
> I'm confused. Stephan said that it is fine for him to have kdepim being 
> developed in KDE 3.5 branch, and you're saying that kdepim should not be 
> developed in KDE 3.5 branch but in enterprise3 branch. 
> 

Correct.
Because KDAB does real development with real QA in the enterprise3 branch.
And for the 3.5 branch people mostly just throw patches over the wall and
assume they work, with no testing at all.

Re: KDE 3.5.final?

On Friday 05 September 2008 15:01:48 Allen Winter wrote:
> On Friday 05 September 2008 05:59:27 Dirk Mueller wrote:
> > On Friday 29 August 2008, Allen Winter wrote:
> > > I expect KDAB will continue doing the best they can for kdepim
> > > enterprise. But the rest of the kdepim team will be moving onto KDE 4
> > > and I plan to tightly monitor the kdepim 3.5 branch and stop anything
> > > but the most obvious bug fixes there.
> > >
> > > IOW: branches/KDE/3.5/kdepim is essentially frozen.
> >
> > I'm confused. Stephan said that it is fine for him to have kdepim being
> > developed in KDE 3.5 branch, and you're saying that kdepim should not be
> > developed in KDE 3.5 branch but in enterprise3 branch.
>
> Correct.
> Because KDAB does real development with real QA in the enterprise3 branch.
> And for the 3.5 branch people mostly just throw patches over the wall and
> assume they work, with no testing at all.

So having 3.5 branch and enterprise completely in sync would make more sense?
--

-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

Re: kdesupport changes

At Tuesday 02 September 2008 16:01, you wrote:
> 1. Is /trunk/kdesupport going to be no longer recommended to build KDE SVN?
> I
> mean e.g. on the techbase page,
> http://techbase.kde.org/Getting_Started/Build/KDE4/Prerequisites#kdesupport

That would be the idea, yes.

> Any plan to update that page to no longer recommend to
> checkout /trunk/kdesupport?

After we reached a descision.

> 2. What is the difference between a "tag" and a "branch" ? I seem to see a
> lot
> of overlap between /tags and /branches.

Technically there is not much of a difference. But in real life, tags should be static, so no development
happens in there, it just is a snapshot of a certain state. A branch is a copy where development can happen,
either a stable tree of the application, or a experimental tree for new features.

> 3. So what is the "tag" that I should create for version x.y of eigen: is
> it /tags/eigen/x.y ?

yes, you should tag your software at each release. Distro's can then easily see the changes between the
released version and the development version, if that is needed for some reason.

> 4. We are about to release a beta version of eigen but the 2.0 final will
> have
> to wait about 6-10 more weeks. Shall I still create a tag as soon as
> possible? /tags/eigen/2.0-beta1 ? Or wait until 2.0 to create a tag?

Tags are cheap. Tag every release you make.

> 5. After we create a tag does that mean that we can do whatever we want
> in /trunk/kdesupport/eigen2 without risking to break compilation for other
> people? 

Yes.

> This is related to question 1. As long as we tell people to use
> trunk/kdesupport, making tags is rather pointless.

Yes. Time to reach a decision about this subject I think.

Toma

Re: kdesupport changes

Aah thanks for the detailed reply.

I have been very concerned about the risk of breaking KDE compilation,
so I welcome these changes very much. I would like that the
development branch of Eigen be a place where we can experiment and
break stuff without affecting our users. So, I support your plan.

Cheers,
Benoit

2008/9/7 Tom Albers <tomalbers@...>:
> At Tuesday 02 September 2008 16:01, you wrote:
>> 1. Is /trunk/kdesupport going to be no longer recommended to build KDE SVN?
>> I
>> mean e.g. on the techbase page,
>> http://techbase.kde.org/Getting_Started/Build/KDE4/Prerequisites#kdesupport
>
> That would be the idea, yes.
>
>> Any plan to update that page to no longer recommend to
>> checkout /trunk/kdesupport?
>
> After we reached a descision.
>
>> 2. What is the difference between a "tag" and a "branch" ? I seem to see a
>> lot
>> of overlap between /tags and /branches.
>
> Technically there is not much of a difference. But in real life, tags should be static, so no development
happens in there, it just is a snapshot of a certain state. A branch is a copy where development can happen,
either a stable tree of the application, or a experimental tree for new features.
>
>> 3. So what is the "tag" that I should create for version x.y of eigen: is
>> it /tags/eigen/x.y ?
>
> yes, you should tag your software at each release. Distro's can then easily see the changes between the
released version and the development version, if that is needed for some reason.
>
>> 4. We are about to release a beta version of eigen but the 2.0 final will
>> have
>> to wait about 6-10 more weeks. Shall I still create a tag as soon as
>> possible? /tags/eigen/2.0-beta1 ? Or wait until 2.0 to create a tag?
>
> Tags are cheap. Tag every release you make.
>
>> 5. After we create a tag does that mean that we can do whatever we want
>> in /trunk/kdesupport/eigen2 without risking to break compilation for other
>> people?
>
> Yes.
>
>> This is related to question 1. As long as we tell people to use
>> trunk/kdesupport, making tags is rather pointless.
>
> Yes. Time to reach a decision about this subject I think.
>
> Toma
> _______________________________________________
> release-team mailing list
> release-team@...
> https://mail.kde.org/mailman/listinfo/release-team
>
>

Re: kdesupport changes

On Sunday 07 September 2008 10:03:47 Benoit Jacob wrote:
> Aah thanks for the detailed reply.
> 
> I have been very concerned about the risk of breaking KDE compilation,
> so I welcome these changes very much. I would like that the
> development branch of Eigen be a place where we can experiment and
> break stuff without affecting our users. So, I support your plan.
> 
There seems to be another set of kdesupport developers who
rely on the KDE folks to help test their stuff in-progress, just
like any other KDE code.  Hence the push-back on this idea.

Re: kdesupport changes

I see. Eigen is special in this respect because it's a
template-library; the biggest risk with the development version of
eigen is not just runtime bugs, it's that it will break compilation of
the program using it. We do have extensive unit-tests, but it's
impossible to cover all corner cases. So far no big glitch has
happened but we're still scared of having users relying on our
development tree.

By contrast, other libs in kdesupport may have bugs but (normally)
won't break compilation of the programs using them.

Cheers,
Benoit

2008/9/7 Allen Winter <winter@...>:
> On Sunday 07 September 2008 10:03:47 Benoit Jacob wrote:
>> Aah thanks for the detailed reply.
>>
>> I have been very concerned about the risk of breaking KDE compilation,
>> so I welcome these changes very much. I would like that the
>> development branch of Eigen be a place where we can experiment and
>> break stuff without affecting our users. So, I support your plan.
>>
> There seems to be another set of kdesupport developers who
> rely on the KDE folks to help test their stuff in-progress, just
> like any other KDE code.  Hence the push-back on this idea.
>
>

kdesupport discussion on release-team list

Hi,

I just found out these discussions on the release-team list, to which I am not 
subscribed:

http://mail.kde.org/pipermail/release-team/2008-August/002395.html
http://mail.kde.org/pipermail/release-team/2008-August/002433.html

My questions are:

1. Is /trunk/kdesupport going to be no longer recommended to build KDE SVN? I 
mean e.g. on the techbase page,
http://techbase.kde.org/Getting_Started/Build/KDE4/Prerequisites#kdesupport
Any plan to update that page to no longer recommend to 
checkout /trunk/kdesupport?

2. What is the difference between a "tag" and a "branch" ? I seem to see a lot 
of overlap between /tags and /branches.

3. So what is the "tag" that I should create for version x.y of eigen: is 
it /tags/eigen/x.y ?

4. We are about to release a beta version of eigen but the 2.0 final will have 
to wait about 6-10 more weeks. Shall I still create a tag as soon as 
possible? /tags/eigen/2.0-beta1 ? Or wait until 2.0 to create a tag?

5. After we create a tag does that mean that we can do whatever we want 
in /trunk/kdesupport/eigen2 without risking to break compilation for other 
people? This is related to question 1. As long as we tell people to use 
kdesupport, making tags is rather pointless.

Cheers,
Benoit

> Howdy,
>
> If you are a developer of a kdesupport project, please make sure
> that your latest-and-greatest stable version is tagged
> in our subversion tags repository.
>
> The "lastest-and-greatest stable version" should be the version
> that we need to use when building trunk.
>
> If you need help with this, please send a note to release-team ML.
>
> -Allen