Hey all,
As of right now there hasn't really been much headway on the renderer related bugs we have which will block 0.49 as well as no action on the security bug stopping all releases.
0.49 should be in feature freeze at this point so we can work towards releasing it (you know, being friendly to translators and all), but other than our blocker bugs, people are still happily working on other features and items that they're wanting merged in (connector cleanup, "spiro live", etc).
Does anyone have any proposals on how we should move forward given the issues holding us back? Is it time that we move to using more branches as a project? One possible route would be to branch off 0.49 and allow open work to resume on trunk. Another is to create a "staging" branch that accepted merge proposals can all land in to get further testing. Note: After this experience, if things have known regressions, I feel strongly that they should not be merged into an actual "to be released" branch until those issue are resolved.
I'm open to suggestions. Development shouldn't stagnate, but at this point things aren't looking good with a feature freeze in place and no signs of our blockers getting taken care of.
Cheers, Josh
On Tue, 2012-12-04 at 13:42 -0800, Josh Andler wrote:
Does anyone have any proposals on how we should move forward given the issues holding us back? Is it time that we move to using more branches as a project? One possible route would be to branch off 0.49 and allow open work to resume on trunk. Another is to create a "staging" branch that accepted merge proposals can all land in to get further testing. Note: After this experience, if things have known regressions, I feel strongly that they should not be merged into an actual "to be released" branch until those issue are resolved.
If we have a release schedule and we've reached a feature freeze, we should have branched into a release branch at that point. Trunk shouldn't ever be blocked with feature freezes, but instead making sure bugs get fixed in both trunk and release branches is a chore for us developers.
I'm open to suggestions. Development shouldn't stagnate, but at this point things aren't looking good with a feature freeze in place and no signs of our blockers getting taken care of.
Do you have a launchpad bug search tag for these? Maybe I can help.
Martin,
On Tue, Dec 4, 2012 at 1:50 PM, Martin Owens <doctormo@...400...> wrote:
If we have a release schedule and we've reached a feature freeze, we should have branched into a release branch at that point. Trunk shouldn't ever be blocked with feature freezes, but instead making sure bugs get fixed in both trunk and release branches is a chore for us developers.
This is not how our development process has worked in the past. Which is why I put it forth as an idea to branch 0.49. We've previously opted to not actually branch for release until the release was ready as opposed to at freeze.
Perhaps we should put this proposed change in processes up to a vote (along with any other reasonable suggestions) a few days of waiting for feedback.
Do you have a launchpad bug search tag for these? Maybe I can help.
https://bugs.launchpad.net/inkscape/+bugs?field.tag=blocker I've subscribed you to the security bug as well so you can review that one too.
Cheers, Josh
On Tue, 2012-12-04 at 14:40 -0800, Josh Andler wrote:
On Tue, Dec 4, 2012 at 1:50 PM, Martin Owens <doctormo@...400...> wrote:
If we have a release schedule and we've reached a feature freeze, we should have branched into a release branch at that point. Trunk shouldn't ever be blocked with feature freezes, but instead making sure bugs get fixed in both trunk and release branches is a chore for us developers.
This is not how our development process has worked in the past. Which is why I put it forth as an idea to branch 0.49. We've previously opted to not actually branch for release until the release was ready as opposed to at freeze.
Perhaps we should put this proposed change in processes up to a vote (along with any other reasonable suggestions) a few days of waiting for feedback.
The concern has always been effectively dividing the workforce. If no one ends up making that release, what state are we in? Sure, Bazaar helps here, but it seems like the project suffers a bit overall. TBH, we have done that a bit in the past. Bryce did release management on 0.44 I believe on a branch in a similar style (as much as SVN allows it) and that was a frustration that he expressed.
Realistically, there's no difference to forking off a release branch and telling devs to keep their features on feature branches. In neither case is anyone "blocked" it's about naming really. So I don't think we should look at it as blocking anyone's progress either way.
Personally, I guess I want to see the release as "happening" which I think is the main concern. If it's well on it's way to being complete it's just baking and fixing, then sure, I'm for it. So what I'd propose is that we need to find people to assign to the bugs who are willing to take responsibility for fixing them. When they're all assigned, I think it might make sense to do a release branch.
--Ted
On Tue, 2012-12-04 at 21:13 -0600, Ted Gould wrote:
So I don't think we should look at it as blocking anyone's progress either way.
The down side to feature branch delay merge delay is that conflicts between features or fixes aren't dealt with centrally and instead rot away at the feature branches making them harder to merge over time.
Apart from that, using trunk is fine.
Martin,
On Wed, Dec 5, 2012 at 5:46 AM, Martin Owens <doctormo@...400...> wrote:
The down side to feature branch delay merge delay is that conflicts between features or fixes aren't dealt with centrally and instead rot away at the feature branches making them harder to merge over time.
I guess the Q, whether in a feature branch or in a central staging branch is, can't some of this be handled by some scripting? Effectively, it seems like it is fairly rare for conflicts to occur on regularly updated branches (thankfully in our project people tend to communicate that they're working on things so we don't step on each others toes). If it were scripted to pull trunk once a day, and then have the feature or staging branch pull right after that, it minimizes divergence... hopefully avoiding conflicts. If it hits a conflict, notify the human(s) about it to resolve the problem.
In general, I almost never see conflicts (except the .pot file) or if I have a patch applied locally and the feature gets committed to trunk w/o me seeing it first. Then again, I don't do heavy development work, so I just may be sheltered on issues like this. Am I off the mark?
Cheers, Josh
On 5-12-2012 4:13, Ted Gould wrote:
On Tue, 2012-12-04 at 14:40 -0800, Josh Andler wrote:
On Tue, Dec 4, 2012 at 1:50 PM, Martin Owens <doctormo@...400...> wrote:
If we have a release schedule and we've reached a feature freeze, we should have branched into a release branch at that point. Trunk shouldn't ever be blocked with feature freezes, but instead making sure bugs get fixed in both trunk and release branches is a chore for us developers.
This is not how our development process has worked in the past. Which is why I put it forth as an idea to branch 0.49. We've previously opted to not actually branch for release until the release was ready as opposed to at freeze.
Perhaps we should put this proposed change in processes up to a vote (along with any other reasonable suggestions) a few days of waiting for feedback.
The concern has always been effectively dividing the workforce. If no one ends up making that release, what state are we in? Sure, Bazaar helps here, but it seems like the project suffers a bit overall. TBH, we have done that a bit in the past. Bryce did release management on 0.44 I believe on a branch in a similar style (as much as SVN allows it) and that was a frustration that he expressed.
Realistically, there's no difference to forking off a release branch and telling devs to keep their features on feature branches. In neither case is anyone "blocked" it's about naming really. So I don't think we should look at it as blocking anyone's progress either way.
I think the difference is in who gets extra overhead: the bug fixer or the feature coder. If we would have a 'release' branch for too long, one would have to apply bugfixes to both 'release' and 'trunk'. Backporting is no fun at all, so... I'd much rather put the merging/whatever burden upon the feature coder.
Personally, I guess I want to see the release as "happening" which I think is the main concern. If it's well on it's way to being complete it's just baking and fixing, then sure, I'm for it. So what I'd propose is that we need to find people to assign to the bugs who are willing to take responsibility for fixing them. When they're all assigned, I think it might make sense to do a release branch.
Branching right before people are going to fix bugs sounds very sadistic and is not motivating at all! ;)
I think the problem now is that it all takes long. It doesn't mean the "system" we have is broken, just that it is unfriendly for feature-coders during stretched out freezy phases. So be it.
Have a look at the graphs here: https://www.ohloh.net/p/inkscape/contributors/summary We are getting by with only a few coders, so things are going slower than people may hope. Take note: 10 committers per month on average.
Branches are pain. Let's not make it hard for ourselves.
Cheers, Johan
On Thu, 2012-12-06 at 00:23 +0100, Johan Engelen wrote:
Branches are pain. Let's not make it hard for ourselves.
Maybe a status email during a freeze:
Merges waiting for thaw:
blah blah blah
Bugs Blocking Release:
blah blah blah
You are strongly encouraged to fix a bug to help get the release out the door.
I admit I looked through some of the bugs and they baffle me, but I'm going to have a hack at one and see if I can learn some more about the codebase.
Shame there isn't a feature freeze status for branches.
Martin,
On Tue, 2012-12-04 at 13:42 -0800, Josh Andler wrote:
Hey all,
As of right now there hasn't really been much headway on the renderer related bugs we have which will block 0.49 as well as no action on the security bug stopping all releases.
We need the input of Krzysztof here. I've looked at some of the bugs. They require a good knowledge of how the rendering code works. I've managed to fix one but a fix for another of the bugs has introduced regressions elsewhere. Our choices are:
1. Go ahead with the release with the current rending bugs. 2. Delay the release until the bugs are fixed.
Which choice, I think, depends on if/when Krzysztof has the time (and desire) to help fix the bugs. The most important bug can't be properly fixed until Cairo introduces APIs to access the new Pixman downscaling routines. I can't see this happening for at least several months.
If we chose (1) then we should be in feature freeze. If we chose (2) then we can have a feature thaw (using a staging branch).
I thought we had a solution for the security bug.
0.49 should be in feature freeze at this point so we can work towards releasing it (you know, being friendly to translators and all), but other than our blocker bugs, people are still happily working on other features and items that they're wanting merged in (connector cleanup, "spiro live", etc).
Does anyone have any proposals on how we should move forward given the issues holding us back? Is it time that we move to using more branches as a project? One possible route would be to branch off 0.49 and allow open work to resume on trunk. Another is to create a "staging" branch that accepted merge proposals can all land in to get further testing. Note: After this experience, if things have known regressions, I feel strongly that they should not be merged into an actual "to be released" branch until those issue are resolved.
I am a bit worried about branching too early. I have found that working in branches can quickly lead to code rot. I had to spend several days getting my Mesh branch to work with trunk after not touching it for a couple of months (which is why it got checked in even though disabled by default).
I do like the idea of a staging branch and agree that if something has known regression it should not be added to trunk.
I'm open to suggestions. Development shouldn't stagnate, but at this point things aren't looking good with a feature freeze in place and no signs of our blockers getting taken care of.
Cheers, Josh
Tav
On Wed, Dec 5, 2012 at 2:55 AM, Tavmjong Bah <tavmjong@...8...> wrote:
We need the input of Krzysztof here. I've looked at some of the bugs. They require a good knowledge of how the rendering code works. I've managed to fix one but a fix for another of the bugs has introduced regressions elsewhere. Our choices are:
- Go ahead with the release with the current rending bugs.
- Delay the release until the bugs are fixed.
We can do alpha, beta, or pre-releases with the current rendering bugs, but I am uncomfortable doing a stable release with them. If a majority vote were to be to release with them, I would have to step aside as release warden this cycle as it would be an issue for me.
If we chose (1) then we should be in feature freeze. If we chose (2) then we can have a feature thaw (using a staging branch).
Seems sensible.
I thought we had a solution for the security bug.
Johan & I emailed about this earlier. So, I'm waiting to hear back or see a commit.
I am a bit worried about branching too early. I have found that working in branches can quickly lead to code rot. I had to spend several days getting my Mesh branch to work with trunk after not touching it for a couple of months (which is why it got checked in even though disabled by default).
I do share your worry. Any thoughts on the scripting to avoid it suggesting from my other message?
Cheers, Josh
El 05/12/12 07:55, Tavmjong Bah escribió:
- Go ahead with the release with the current rending bugs.
The first bug in the list (the lack of proper bitmap downscaling in cairo) makes Inkscape unusable for anyone using bitmap images in their designs. For me it would mean that I should have to pin my current version of inkscape and skip 0.49 completely. Same goes for the gaussian blur glitches although it's more random.
Personally I don't think it would be wise to release a stable version with those important regressions that affect the quality of the output so sensibly.
Gez
2012/12/5 Tavmjong Bah <tavmjong@...8...>:
On Tue, 2012-12-04 at 13:42 -0800, Josh Andler wrote:
Hey all,
As of right now there hasn't really been much headway on the renderer related bugs we have which will block 0.49 as well as no action on the security bug stopping all releases.
We need the input of Krzysztof here. I've looked at some of the bugs. They require a good knowledge of how the rendering code works. I've managed to fix one but a fix for another of the bugs has introduced regressions elsewhere.
I am in the process of finishing my master's thesis and I have to defend it before the end of the year. Sorry that I didn't fix all these issues before - the work is taking much longer than I anticipated and this is partially my fault (too much distractions).
Regards, Krzysztof
participants (7)
-
Guillermo Espertino (Gez) -
Johan Engelen -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Tavmjong Bah -
Ted Gould