Upcoming Releases
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
2009/11/3 Joshua A. Andler <scislac@...400...>:
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
On Tue, Nov 3, 2009 at 3:05 PM, Joshua A. Andler <scislac@...400...> 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.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] 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@...400...> 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
On Tue, 2009-11-03 at 23:54 +0100, J.B.C.Engelen@...1578... 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
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
-----Original Message----- From: Joshua A. Andler [mailto:scislac@...400...] 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
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
On Wed, Nov 4, 2009 at 5:22 AM, <J.B.C.Engelen@...1578...> 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.
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
On Wed, 2009-11-04 at 10:22 +0100, J.B.C.Engelen@...1578... 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
participants (5)
-
unknown＠example.com -
Alexandre Prokoudine -
bulia byak -
Joshua A. Andler -
Krzysztof Kosiński