Upcoming Releases

[Joshua A. Andler-2]

Hey All,

Obviously, we are still waiting on the final patch for 0.47 before it
can be released. When we were wanting to release 0.46, we had a similar
issue with a Win32 specific issue holding up the release. This brings up
something that needs to be addressed before the 0.48 cycle begins.

It would be really helpful if for 0.48 we have a temporary policy,
please comment on this if you agree, disagree, or have suggestions. For
0.48, it would be nice if anything that is a major change (aside from
our GSoC projects) is NOT put into trunk until it has been well tested
in a branch and/or privately by other devs/testers (I am willing and
excited to test!). It would also be nice if we decide on an open
committing period (time before Feature Freeze). For open committing, I
would think 8-12 weeks should be sufficient to not break things too
badly, yet still give enough time to flesh features out.

I know this is much more restrictive than our normal development
process, but for 0.48 to be as good and solid as possible (as soon as
possible), this route makes the most sense. Obviously, once 0.48 gets
out the door and we are onto 0.49, people can go back to committing
responsibly... but, it would be nice if we had a policy moving forward
of "if you break it, you must fix it".

Thoughts?

Cheers,
Josh


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

2009/11/3 Joshua A. Andler <scislac@...>:
> It would be really helpful if for 0.48 we have a temporary policy,
> please comment on this if you agree, disagree, or have suggestions. For
> 0.48, it would be nice if anything that is a major change (aside from
> our GSoC projects) is NOT put into trunk until it has been well tested
> in a branch and/or privately by other devs/testers (I am willing and
> excited to test!).

I agree 100%, as long as we move the code repository to Launchpad
right after 0.48 is released. It will greatly improve the visibility
of other people's unmerged work. This has multiple benefits: testers
will now focus on one feature, and the probability of a crash arising
from an unrelated change will be smaller; developers working on
important new features will get feedback earlier; code and design
review before merging will be easier; multiple people will be able to
work on a single refactoring project; refactoring projects will not be
restricted by the trunk's stability standards.

> it would be nice if we had a policy moving forward
> of "if you break it, you must fix it".

This makes sense as well.

Regards, Krzysztof

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[bulia byak]

On Tue, Nov 3, 2009 at 3:05 PM, Joshua A. Andler <scislac@...> wrote:
> Hey All,
>
> Obviously, we are still waiting on the final patch for 0.47 before it
> can be released. When we were wanting to release 0.46, we had a similar
> issue with a Win32 specific issue holding up the release. This brings up
> something that needs to be addressed before the 0.48 cycle begins.

Is this patch being worked on? It's been my impression that the issue
is at least hard to reproduce, to start with.

I may be wildly off the mark, but I would vote to release right now.


> It would be really helpful if for 0.48 we have a temporary policy,
> please comment on this if you agree, disagree, or have suggestions. For
> 0.48, it would be nice if anything that is a major change (aside from
> our GSoC projects) is NOT put into trunk until it has been well tested
> in a branch and/or privately by other devs/testers (I am willing and
> excited to test!). It would also be nice if we decide on an open
> committing period (time before Feature Freeze). For open committing, I
> would think 8-12 weeks should be sufficient to not break things too
> badly, yet still give enough time to flesh features out.

How do we define "major"?

Generally I'm in favor of making 0.48 more restrictive, because
otherwise we won't be able to do it fast. I'd suggest that people
start working on patches already, so they are ready to commit when we
reopen!

> I know this is much more restrictive than our normal development
> process, but for 0.48 to be as good and solid as possible (as soon as
> possible), this route makes the most sense. Obviously, once 0.48 gets
> out the door and we are onto 0.49, people can go back to committing
> responsibly... but, it would be nice if we had a policy moving forward
> of "if you break it, you must fix it".

Such policy is an absolute must, and mostly we adhere to it. I think
it only gets violated when the damage is discovered too late when the
original author is no longer available.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[J.B.C.Engelen]

> -----Original Message-----
> From: bulia byak [mailto:buliabyak@...]
> Sent: dinsdag 3 november 2009 22:26
> To: Joshua A. Andler
> Cc: inkscape-devel
> Subject: Re: [Inkscape-devel] Upcoming Releases
>
> On Tue, Nov 3, 2009 at 3:05 PM, Joshua A. Andler
> <scislac@...> wrote:
> > Hey All,
> >
> > Obviously, we are still waiting on the final patch for 0.47
> before it
> > can be released. When we were wanting to release 0.46, we had a
> > similar issue with a Win32 specific issue holding up the
> release. This
> > brings up something that needs to be addressed before the
> 0.48 cycle begins.
>
> Is this patch being worked on? It's been my impression that
> the issue is at least hard to reproduce, to start with.
>
> I may be wildly off the mark, but I would vote to release right now.

I have several patches in the bugtracker that fix important issues:
https://bugs.launchpad.net/inkscape/+bug/445790
https://bugs.launchpad.net/inkscape/+bug/409043

Less important but still:
https://bugs.launchpad.net/inkscape/+bug/456148

- Johan

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua A. Andler-2]

On Tue, 2009-11-03 at 23:54 +0100, J.B.C.Engelen@... wrote:
> I have several patches in the bugtracker that fix important issues:
> https://bugs.launchpad.net/inkscape/+bug/445790
> https://bugs.launchpad.net/inkscape/+bug/409043
>
> Less important but still:
> https://bugs.launchpad.net/inkscape/+bug/456148


Thanks, I will check these out either later tonight or tomorrow.

Cheers,
Josh


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua A. Andler-2]

On Tue, 2009-11-03 at 16:25 -0500, bulia byak wrote:
> Is this patch being worked on? It's been my impression that the issue
> is at least hard to reproduce, to start with.

Jon, care to comment?

> I may be wildly off the mark, but I would vote to release right now.

I will be honest that even if it is an issue, if we don't have a fix in
sight, it's worth releasing with this so we all can get on with active,
collaborative development.

> How do we define "major"?

Well, typically something that we would label as a refactoring task.
However, if someone has a "major" change and throws it in a branch and
it is deemed to be safe enough to be worth the possible risk for 0.48,
we'll merge it.

> Generally I'm in favor of making 0.48 more restrictive, because
> otherwise we won't be able to do it fast. I'd suggest that people
> start working on patches already, so they are ready to commit when we
> reopen!

I completely agree!

> Such policy is an absolute must, and mostly we adhere to it. I think
> it only gets violated when the damage is discovered too late when the
> original author is no longer available.

Well, this possibly ties into the branches stuff. I've noticed a few
times where people commit stuff and then leave on vacation or the like.
So, if someone has a number of changes that they want to commit and know
they will be unavailable for a few weeks to a few months or longer, put
it in a branch. Honestly, the same goes for "Here's what I've done, I
don't feel like working on it anymore" type contributions, until they've
been deemed safe to merge.

Cheers,
Josh


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[J.B.C.Engelen]

> -----Original Message-----
> From: Joshua A. Andler [mailto:scislac@...]
> Sent: Wednesday, November 04, 2009 02:40
>
> > How do we define "major"?
>
> Well, typically something that we would label as a refactoring task.
> However, if someone has a "major" change and throws it in a
> branch and it is deemed to be safe enough to be worth the
> possible risk for 0.48, we'll merge it.

I'm not sure whether it is the refactoring that troubles this release.

I don't know what my opinion is. Having bug-likely stuff in a branch is
nice of course.

However, a practical problem of large refactoring is that it touches the
source in many different places. This makes it very likely that changes
in trunk coincide with refactoring changes in the branch. A lot of time
(and frustration) will be spent merging in changes from trunk. This is
also true for non-refactoring but invasive new features, like LPE was.

Moreover, very few people test branches. I remember Josh (ScislaC) and
sim (?) being the only ones who regularly checked out my LPE branch for
testing. A branch was used for group/stacked LPE, but perhaps two people
(other than the devs) tested it a little.
Many bugs are discovered late, and it seems a branch will only delay
that. On the upside, there are also a lot of bugs that are discovered
early but the bugreports reach the developer(s) very late or not at all;
the upside is that when a branch is used, the bugs are easier to target
to a specific branch and to specific developer(s).  

I think more important than a branch is a teamed effort for big
projects. From my own experience, refactoring alone is no fun;
refactoring in a team (thanks Verbal and Diederik!) is much more fun. So
I feel that before anyone should take up refactoring, he should find a
team to do it with. This reduces the risk of 'vacation' or 'sick of it'
problems.

Ciao,
 Johan



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alexandre Prokoudine]

On 11/4/09, J.B.C.Engelen wrote:

> Moreover, very few people test branches. I remember Josh (ScislaC) and
> sim (?) being the only ones who regularly checked out my LPE branch for
> testing. A branch was used for group/stacked LPE, but perhaps two people
> (other than the devs) tested it a little.

We just need something like graphicall.org :)

Alexandre

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[bulia byak]

On Wed, Nov 4, 2009 at 5:22 AM,  <J.B.C.Engelen@...> wrote:
> I don't know what my opinion is. Having bug-likely stuff in a branch is
> nice of course.
>
> However, a practical problem of large refactoring is that it touches the
> source in many different places. This makes it very likely that changes
> in trunk coincide with refactoring changes in the branch. A lot of time
> (and frustration) will be spent merging in changes from trunk. This is
> also true for non-refactoring but invasive new features, like LPE was.

Exactly. And a better SVN with easier branches won't change that.
Let's not be carried away by the shiny new tools. Branches' freedom
can easily turn sour. Whenever there's a chance to effect a change by
a series of focused, well-planned changes in the trunk, each of which
leaves it in a workable state, this should be preferred to branching.

> I think more important than a branch is a teamed effort for big
> projects. From my own experience, refactoring alone is no fun;
> refactoring in a team (thanks Verbal and Diederik!) is much more fun. So
> I feel that before anyone should take up refactoring, he should find a
> team to do it with. This reduces the risk of 'vacation' or 'sick of it'
> problems.

Exactly. That's why we're doing Inkscape in the first place :)  It is
so much more than the sum of what each of us could do alone.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua A. Andler-2]

On Wed, 2009-11-04 at 10:22 +0100, J.B.C.Engelen@... wrote:
> I'm not sure whether it is the refactoring that troubles this release.

I'm not saying it troubled this release, but that something of that
nature would potentially (not definitely) make for a longer 0.48 cycle.


> However, a practical problem of large refactoring is that it touches the
> source in many different places. This makes it very likely that changes
> in trunk coincide with refactoring changes in the branch. A lot of time
> (and frustration) will be spent merging in changes from trunk. This is
> also true for non-refactoring but invasive new features, like LPE was.

Well, I'm not going to say that a proper DVCS will make the merges less
difficult, however, just as I am willing to test branches, I am also
willing to help merge more often (and address issues that arise) to make
it easier on the devs in the trenches.

> Moreover, very few people test branches. I remember Josh (ScislaC) and
> sim (?) being the only ones who regularly checked out my LPE branch for
> testing. A branch was used for group/stacked LPE, but perhaps two people
> (other than the devs) tested it a little.

I think you're underestimating our community. :) As with any high
profile, exciting, or important changes, if you tap the community I
think they will surprise you. For things that are less obvious or
exciting, there are still a couple of us that would be more than happy
to test.

> Many bugs are discovered late, and it seems a branch will only delay
> that. On the upside, there are also a lot of bugs that are discovered
> early but the bugreports reach the developer(s) very late or not at all;
> the upside is that when a branch is used, the bugs are easier to target
> to a specific branch and to specific developer(s).

I can't disagree about when bugs are discovered... there's a reason why
regular users report bugs after release that no one saw in testing. :)
The branch recommendation was really just for 0.48 though... is there
something you're working on that you're particularly concerned about?
Post a diff right now and I'll start testing.

> I think more important than a branch is a teamed effort for big
> projects. From my own experience, refactoring alone is no fun;
> refactoring in a team (thanks Verbal and Diederik!) is much more fun. So
> I feel that before anyone should take up refactoring, he should find a
> team to do it with. This reduces the risk of 'vacation' or 'sick of it'
> problems.

Yes it is more fun... this is why I want 0.47 out the door. So we can
get back to collaborative development. Releases are a "drag"... momentum
comes to a crawl, the energy is sapped from the community, and
contributions are few and far between. This is part of my wanting to be
able to get 0.48 done quickly, to keep the pace and energy as much as
possible into a longer refactoring cycle.

Cheers,
Josh


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua A. Andler-2]

On Wed, 2009-11-04 at 12:26 -0400, bulia byak wrote:
> Exactly. And a better SVN with easier branches won't change that.
> Let's not be carried away by the shiny new tools. Branches' freedom
> can easily turn sour. Whenever there's a chance to effect a change by
> a series of focused, well-planned changes in the trunk, each of which
> leaves it in a workable state, this should be preferred to branching.

I won't (completely) disagree about the shiny new tools remark... but I
will also say that you (bulia) have a particularly good record for the
well-planned changes. I've seen others (in a number of projects) not
have such success with what they thought were well-planned changes.

> Exactly. That's why we're doing Inkscape in the first place :)  It is
> so much more than the sum of what each of us could do alone.

Yay for collaboration! :)

Cheers,
Josh


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel