Hey All,
I'd like to proposed that after we get 0.49 out the door, we have regular planned releases. No more "always open" trunk development. But leverage merge windows instead... which also means needing to land "more complete" features in trunk than we've historically allowed. I'd love to see us have 6 month cycles to get features and fixes out to users sooner. It's awesome to have flashy new stuff for every release, but it's just not necessary.
What are people's thoughts on this tried and true strategy many other projects use? Can we at least give it a shot?
Cheers, Josh
On Tue, Aug 28, 2012 at 11:17 PM, Josh Andler wrote:
What are people's thoughts on this tried and true strategy many other projects use? Can we at least give it a shot?
In my opinion it would be helpful.
But right now I'd pay a lot of attention to the way we work with contributors. Yes, it's about color managed PDF exporting in Cairo again.
We can't get stuff done if we ignore significant contributions. Personally I'm ashamed that we let it slip through our fingers.
Alexandre Prokoudine http://libregraphicsworld.org
On Tue, Aug 28, 2012 at 2:41 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
But right now I'd pay a lot of attention to the way we work with contributors. Yes, it's about color managed PDF exporting in Cairo again.
Completely agreed. Part of the problem though is the general lack of interest & knowledge by most of our devs. Neither of the 2 people with the most knowledge have really been around.
We can't get stuff done if we ignore significant contributions. Personally I'm ashamed that we let it slip through our fingers.
Very true. One of the issues we have though is a general lack of testers to give feedback. We have the possibility of mesh gradients coming to Inkscape, but it's definitely not tested enough and not enough feedback has been given on the specification end. We have the incomplete "Technical Tool" which has languished for years. I have plenty of other not-complete examples as well.
Cheers, Josh
On Tue, 2012-08-28 at 15:21 -0700, Josh Andler wrote:
Very true. One of the issues we have though is a general lack of testers to give feedback. We have the possibility of mesh gradients coming to Inkscape, but it's definitely not tested enough and not enough feedback has been given on the specification end. We have the incomplete "Technical Tool" which has languished for years. I have plenty of other not-complete examples as well.
Getting features released and in front of users is going to help that part of it. We could do more to not only make it easier to switch on and off experimental features, but also reporting issues.
It's a shame our distros don't do bug management yet (still) but that doesn't mean we couldn't at least have neophyte reports.
I say we switch on all experimental features, make sure people can turn them off if they don't like them and make sure we have options in UI for reporting.
Martin,
On Tue, Aug 28, 2012 at 6:41 PM, Martin Owens <doctormo@...400...> wrote:
Getting features released and in front of users is going to help that part of it. We could do more to not only make it easier to switch on and off experimental features, but also reporting issues.
It's a shame our distros don't do bug management yet (still) but that doesn't mean we couldn't at least have neophyte reports.
I say we switch on all experimental features, make sure people can turn them off if they don't like them and make sure we have options in UI for reporting.
While desirable on one hand, it's not on the other. The features are incomplete and/or have bugs. Nothing is to say the syntax for the mesh tool won't change. We don't want to have to support a "test" version of things. Likewise, we will get bug reports from people who aren't real testers or experienced bug reporters... it's setting us up for unhappy users and a lot of unnecessary work on the tracker.
SorinN had contacted me though and it seems like making special test builds for new features may be the way to go. That way average users won't accidently get exposed, and people who want to help us and know how to give proper feedback will then have access to builds w/o compiling themselves. Seems like a best of both option imho.
Cheers, Josh
On 28-08-12 21:17, Josh Andler wrote:
Hey All,
I'd like to proposed that after we get 0.49 out the door, we have regular planned releases. No more "always open" trunk development. But leverage merge windows instead... which also means needing to land "more complete" features in trunk than we've historically allowed. I'd love to see us have 6 month cycles to get features and fixes out to users sooner. It's awesome to have flashy new stuff for every release, but it's just not necessary.
What are people's thoughts on this tried and true strategy many other projects use? Can we at least give it a shot?
Definitely.
On Tue, 2012-08-28 at 12:17 -0700, Josh Andler wrote:
I'd like to proposed that after we get 0.49 out the door, we have regular planned releases. No more "always open" trunk development. But leverage merge windows instead... which also means needing to land "more complete" features in trunk than we've historically allowed. I'd love to see us have 6 month cycles to get features and fixes out to users sooner. It's awesome to have flashy new stuff for every release, but it's just not necessary.
So I like time based releases, but I'm concerned a bit about every six months. It seems to me, perhaps yearly would be better. Considering we don't developers who are paid to work on Inkscape, it might make sense to adapt the common cadence and scale it back slightly.
Then we can just version number by year ;-)
What are people's thoughts on this tried and true strategy many other projects use? Can we at least give it a shot?
I think that one issue that GNOME has had with the 6 month release cycle is that there is generally a feeling that "long term" features have a hard time in that environment. Certainly, Inkscape has it easier in that we're one codebase and GNOME features generally have to land in several libs/apps all at the same time. But, I think one thing we'd need to figure out is how to culturally support someone working on a feature like that to have a branch, get that branch tested, and be able to promote their work. Bazaar solves the technical issues, but there are some social ones as well.
--Ted
On Fri, Aug 31, 2012 at 5:55 PM, Ted Gould wrote:
several libs/apps all at the same time. But, I think one thing we'd need to figure out is how to culturally support someone working on a feature like that to have a branch, get that branch tested, and be able to promote their work. Bazaar solves the technical issues, but there are some social ones as well.
Ted, any examples?
Alexandre Prokoudine http://libregraphicsworld.org
On Fri, 2012-08-31 at 18:06 +0400, Alexandre Prokoudine wrote:
On Fri, Aug 31, 2012 at 5:55 PM, Ted Gould wrote:
several libs/apps all at the same time. But, I think one thing we'd need to figure out is how to culturally support someone working on a feature like that to have a branch, get that branch tested, and be able to promote their work. Bazaar solves the technical issues, but there are some social ones as well.
Ted, any examples?
Of features? I think that GTK3 was a hard one for GNOME because of this problem. It doesn't really make sense to break applications slowly, and as a result GTK APIs didn't get cleaned up like they needed to be (to maintain compatibility across the 2 series). Effectively, because the APIs exposed to much, it was hard to innovate in GTK which made it stagnate some.
--Ted
On Fri, Aug 31, 2012 at 6:24 PM, Ted Gould wrote:
several libs/apps all at the same time. But, I think one thing we'd need to figure out is how to culturally support someone working on a feature like that to have a branch, get that branch tested, and be able to promote their work. Bazaar solves the technical issues, but there are some social ones as well.
Ted, any examples?
Of features?
Nope, of social issues.
Alexandre Prokoudine http://libregraphicsworld.org
On Fri, 2012-08-31 at 18:34 +0400, Alexandre Prokoudine wrote:
On Fri, Aug 31, 2012 at 6:24 PM, Ted Gould wrote:
several libs/apps all at the same time. But, I think one thing we'd need to figure out is how to culturally support someone working on a feature like that to have a branch, get that branch tested, and be able to promote their work. Bazaar solves the technical issues, but there are some social ones as well.
Ted, any examples?
Of features?
Nope, of social issues.
Heh.
I guess my primary concern would be a sense of belonging and part of the community. If you were to work on a branch of on your own for a year or more, how do you know it's going to get merged? How do you know anyone cares about it? What excites you to continue your work?
I think that partially this can be filled by, most simply, by documenting the branches. Perhaps a "Monthly Branch Report" or some such. An official tumblr feed of screenshots? I don't know exactly. What are the kids using these days ;-)
--Ted
On Fri, Aug 31, 2012 at 6:44 PM, Ted Gould wrote:
Ted, any examples?
Of features?
Nope, of social issues.
Heh.
I guess my primary concern would be a sense of belonging and part of the community. If you were to work on a branch of on your own for a year or more, how do you know it's going to get merged? How do you know anyone cares about it? What excites you to continue your work?
The way I see it, it's a two-way issue.
Nothing prevents the developer from posting on the list to introduce shimself :) and telling about the work in progress.
Likewise, nothing prevents someone like me from doing something like what you suggested below:
I think that partially this can be filled by, most simply, by documenting the branches. Perhaps a "Monthly Branch Report" or some such. An official tumblr feed of screenshots? I don't know exactly. What are the kids using these days ;-)
I'll think about it.
Most project news go to Google+ these days. We have over 5K subscribers to our page there.
Alexandre Prokoudine http://libregraphicsworld.org
On Fri, 2012-08-31 at 11:29 -0400, Martin Owens wrote:
On Fri, 2012-08-31 at 09:44 -0500, Ted Gould wrote:
An official tumblr feed of screenshots? I don't know exactly. What are the kids using these days ;-)
An official inkscape-branches ppa?
Yes, but, the hard part there is the different packages will conflict, so they really need to be different PPAs. Also, as much as that works for me personally, it seems most of our userbase is still stuck on Windows, it would be nice if they could test as well.
--Ted
On Fri, 2012-08-31 at 12:39 -0500, Ted Gould wrote:
Yes, but, the hard part there is the different packages will conflict, so they really need to be different PPAs.
How many parts would inkscape be? I'm surprised there's not a way to encapsulate the libs. But perhaps that's a problem with debian.
Martin,
On Fri, 2012-08-31 at 23:44 -0400, Martin Owens wrote:
On Fri, 2012-08-31 at 12:39 -0500, Ted Gould wrote:
Yes, but, the hard part there is the different packages will conflict, so they really need to be different PPAs.
How many parts would inkscape be? I'm surprised there's not a way to encapsulate the libs. But perhaps that's a problem with debian.
The problem isn't with the number of parts, it's that Debian assumes that the package name is unique. That goes where things like files get placed. I did a patch to the build system for the inkscape-dev version I did a while back so that it was parallel installable, but it was kinda a PITA to maintain.
I guess what we could do is modify our build system so that there was a modifier built in. Then we could make "daily", "dev" and even "my-crazy-feature." It would make doing something like that easier.
--Ted
2012/9/2 Ted Gould <ted@...11...>:
I guess what we could do is modify our build system so that there was a modifier built in. Then we could make "daily", "dev" and even "my-crazy-feature." It would make doing something like that easier.
The same occured to me, there should be a way to specify a custom suffix which would be applied to the directories, executable names and desktop files - this way there could be an arbitrary number of versions installed together.
On the other hand, Inkscape's Debian packaging is maintained by Debian and AFAIK they're not that enthusiastic about upstream writing their own packaging scripts.
Regards, Krzysztof
On Mon, 2012-09-03 at 01:12 +0200, Krzysztof Kosiński wrote:
2012/9/2 Ted Gould <ted@...11...>:
I guess what we could do is modify our build system so that there was a modifier built in. Then we could make "daily", "dev" and even "my-crazy-feature." It would make doing something like that easier.
The same occured to me, there should be a way to specify a custom suffix which would be applied to the directories, executable names and desktop files - this way there could be an arbitrary number of versions installed together.
On the other hand, Inkscape's Debian packaging is maintained by Debian and AFAIK they're not that enthusiastic about upstream writing their own packaging scripts.
Sure, the Debian packaging is one thing, but the build system also needs modifications. Unfortunately I don't think there's much ability to dynamically build the control file so it would mostly have to be done by hand. Perhaps we can script it to make it easier for contributors.
--Ted
participants (6)
-
Alexandre Prokoudine -
Jasper van de Gronde -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Ted Gould