Proposed idea for an interim trunk release
After 0.92.2 is completed, I've been thinking about doing a development release of trunk, to help us build towards 0.93. Something a bit more than just a nightly snapshot, but far less than even an alpha release. Call it an "unrelease" or just a "blessed snapshot".
Here's my reasoning for why I think this would be worth doing:
a. Our alphas get decent testing, but there's not time for the necessary bug fixing, since we're anxious to get the actual release out. This interim release would stimulate testing and bug fixing independent of any such pressure.
b. Moving to gitlab, cmake, and gtk3 has changed a LOT structurally. Doing a "practice release" would help find remaining problems with these transitions.
c. Despite all the great work done setting up CI's, automated builds, and rolling packaging systems, many advanced users want a fully usable, QA'd build before they'll look at our work. Lesson learned from last release is that we really need these kinds of users' input on our features before we finalize stuff.
d. For the rest of us Inkscapers, it will provide a focal point for our near term development, testing, documentation, and refactoring work. But one that won't need all the rigor that a regular release would have - no about screen contests, overly long feature freeze periods, string freezes, worrying over release-blocker bugs, or needing to polish up release notes and other docs.
Procedurally:
* A soft feature freeze for a week or two, max * No more than one pre-release (if even that) * Translations encouraged, but no string freeze * Packaging needed for all platforms * Packages available from website, but not linked prominently * Lite marketing - basically just target to advanced users * Is clearly marked UNSTABLE and UNSUPPORTED
Some other crazy ideas to consider, that might help prevent it from becoming a support burden:
+ Annoying popup dialog declaring it so at run time? + No guarantee of file format compatibility? + Limited period for accepting bugs reports? + Expiring binary refuses to run after a certain date? + Advise distros to NOT distribute it?
So, your thoughts?
Bryce
Sounds great to me! I generally use inkscape-trunk for production work to help test, and I'm sure others would appreciate the opportunity.
my 2p -C
On Sun, Jul 16, 2017 at 7:21 AM, Bryce Harrington <bryce@...961...> wrote:
After 0.92.2 is completed, I've been thinking about doing a development release of trunk, to help us build towards 0.93. Something a bit more than just a nightly snapshot, but far less than even an alpha release. Call it an "unrelease" or just a "blessed snapshot".
Here's my reasoning for why I think this would be worth doing:
a. Our alphas get decent testing, but there's not time for the necessary bug fixing, since we're anxious to get the actual release out. This interim release would stimulate testing and bug fixing independent of any such pressure.
b. Moving to gitlab, cmake, and gtk3 has changed a LOT structurally. Doing a "practice release" would help find remaining problems with these transitions.
c. Despite all the great work done setting up CI's, automated builds, and rolling packaging systems, many advanced users want a fully usable, QA'd build before they'll look at our work. Lesson learned from last release is that we really need these kinds of users' input on our features before we finalize stuff.
d. For the rest of us Inkscapers, it will provide a focal point for our near term development, testing, documentation, and refactoring work. But one that won't need all the rigor that a regular release would have - no about screen contests, overly long feature freeze periods, string freezes, worrying over release-blocker bugs, or needing to polish up release notes and other docs.
Procedurally:
- A soft feature freeze for a week or two, max
- No more than one pre-release (if even that)
- Translations encouraged, but no string freeze
- Packaging needed for all platforms
- Packages available from website, but not linked prominently
- Lite marketing - basically just target to advanced users
- Is clearly marked UNSTABLE and UNSUPPORTED
Some other crazy ideas to consider, that might help prevent it from becoming a support burden:
- Annoying popup dialog declaring it so at run time?
- No guarantee of file format compatibility?
- Limited period for accepting bugs reports?
- Expiring binary refuses to run after a certain date?
- Advise distros to NOT distribute it?
So, your thoughts?
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Sounds great to me! I generally use inkscape-trunk for production work to help test, and I'm sure others would appreciate the opportunity.
my 2p -C
On Sun, Jul 16, 2017 at 7:21 AM, Bryce Harrington <bryce@...961...> wrote:
After 0.92.2 is completed, I've been thinking about doing a development release of trunk, to help us build towards 0.93. Something a bit more than just a nightly snapshot, but far less than even an alpha release. Call it an "unrelease" or just a "blessed snapshot".
Here's my reasoning for why I think this would be worth doing:
a. Our alphas get decent testing, but there's not time for the necessary bug fixing, since we're anxious to get the actual release out. This interim release would stimulate testing and bug fixing independent of any such pressure.
b. Moving to gitlab, cmake, and gtk3 has changed a LOT structurally. Doing a "practice release" would help find remaining problems with these transitions.
c. Despite all the great work done setting up CI's, automated builds, and rolling packaging systems, many advanced users want a fully usable, QA'd build before they'll look at our work. Lesson learned from last release is that we really need these kinds of users' input on our features before we finalize stuff.
d. For the rest of us Inkscapers, it will provide a focal point for our near term development, testing, documentation, and refactoring work. But one that won't need all the rigor that a regular release would have - no about screen contests, overly long feature freeze periods, string freezes, worrying over release-blocker bugs, or needing to polish up release notes and other docs.
Procedurally:
- A soft feature freeze for a week or two, max
- No more than one pre-release (if even that)
- Translations encouraged, but no string freeze
- Packaging needed for all platforms
- Packages available from website, but not linked prominently
- Lite marketing - basically just target to advanced users
- Is clearly marked UNSTABLE and UNSUPPORTED
Some other crazy ideas to consider, that might help prevent it from becoming a support burden:
- Annoying popup dialog declaring it so at run time?
- No guarantee of file format compatibility?
- Limited period for accepting bugs reports?
- Expiring binary refuses to run after a certain date?
- Advise distros to NOT distribute it?
So, your thoughts?
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I like the general idea, but I think we're not there yet:
* master has no big new features so far, so we have nothing to showcase * the work involved in getting to gtk3/git was considerable but it's a purely technical aspect mostly invisible to the user * the parts that actually *are* visible to the user (i.e. mostly gtk3 ui changes) are in a bad state to say the least - we don't need user input to know (or work) on that * some work is known to be unfinished at this point (e.g. UI files and icons). I'm sure work on them will continue without users telling us that it's not fully working yet * packaging is something I'd think about when master is in a working state again, but not before
If you want to channel our efforts, it's probably more effective if the board appeals to the developers to get some regression/bug fixing done before looking at further feature work or non-essential code re-factoring (it's even in the roadmap if anybody is still reading that). To be honest I'm a bit unhappy with how this is handled in the Inkscape project right now :-/.
Regards, Eduard
Am 16.07.2017 um 11:20 schrieb C R:
Sounds great to me! I generally use inkscape-trunk for production work to help test, and I'm sure others would appreciate the opportunity.
my 2p -C
On Sun, Jul 16, 2017 at 7:21 AM, Bryce Harrington <bryce@...961...> wrote:
After 0.92.2 is completed, I've been thinking about doing a development release of trunk, to help us build towards 0.93. Something a bit more than just a nightly snapshot, but far less than even an alpha release. Call it an "unrelease" or just a "blessed snapshot".
Here's my reasoning for why I think this would be worth doing:
a. Our alphas get decent testing, but there's not time for the necessary bug fixing, since we're anxious to get the actual release out. This interim release would stimulate testing and bug fixing independent of any such pressure.
b. Moving to gitlab, cmake, and gtk3 has changed a LOT structurally. Doing a "practice release" would help find remaining problems with these transitions.
c. Despite all the great work done setting up CI's, automated builds, and rolling packaging systems, many advanced users want a fully usable, QA'd build before they'll look at our work. Lesson learned from last release is that we really need these kinds of users' input on our features before we finalize stuff.
d. For the rest of us Inkscapers, it will provide a focal point for our near term development, testing, documentation, and refactoring work. But one that won't need all the rigor that a regular release would have - no about screen contests, overly long feature freeze periods, string freezes, worrying over release-blocker bugs, or needing to polish up release notes and other docs.
Procedurally:
- A soft feature freeze for a week or two, max
- No more than one pre-release (if even that)
- Translations encouraged, but no string freeze
- Packaging needed for all platforms
- Packages available from website, but not linked prominently
- Lite marketing - basically just target to advanced users
- Is clearly marked UNSTABLE and UNSUPPORTED
Some other crazy ideas to consider, that might help prevent it from becoming a support burden:
- Annoying popup dialog declaring it so at run time?
- No guarantee of file format compatibility?
- Limited period for accepting bugs reports?
- Expiring binary refuses to run after a certain date?
- Advise distros to NOT distribute it?
So, your thoughts?
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2017-07-16 at 14:31 +0200, Eduard Braun wrote:
If you want to channel our efforts, it's probably more effective if the board appeals to the developers to get some regression/bug fixing done before looking at further feature work or non-essential code re- factoring (it's even in the roadmap if anybody is still reading that). To be honest I'm a bit unhappy with how this is handled in the Inkscape project right now :-/.
The board isn't developer leadership. It's the money and trademark arm of the project.
So, as for getting together a bug hunt, that's a developer team decision. Bryce, Eduard, Martin, anyone could set that up (and it sounds like a good idea)
Best Regards, Martin Owens
Yes, I agree. Maybe some of the Hackfest budget that was not spent could be used as a bounty for most bugs squashed? Or maybe some other motivational item? Can we put up a bug squashing paperboard?
On 16 Jul 2017 5:38 p.m., "Martin Owens" <doctormo@...400...> wrote:
On Sun, 2017-07-16 at 14:31 +0200, Eduard Braun wrote:
If you want to channel our efforts, it's probably more effective if the board appeals to the developers to get some regression/bug fixing done before looking at further feature work or non-essential code re- factoring (it's even in the roadmap if anybody is still reading that). To be honest I'm a bit unhappy with how this is handled in the Inkscape project right now :-/.
The board isn't developer leadership. It's the money and trademark arm of the project.
So, as for getting together a bug hunt, that's a developer team decision. Bryce, Eduard, Martin, anyone could set that up (and it sounds like a good idea)
Best Regards, Martin Owens
Paperboard = Leaderboard
On 16 Jul 2017 6:59 p.m., "C R" <cajhne@...400...> wrote:
Yes, I agree. Maybe some of the Hackfest budget that was not spent could be used as a bounty for most bugs squashed? Or maybe some other motivational item? Can we put up a bug squashing paperboard?
On 16 Jul 2017 5:38 p.m., "Martin Owens" <doctormo@...400...> wrote:
On Sun, 2017-07-16 at 14:31 +0200, Eduard Braun wrote:
If you want to channel our efforts, it's probably more effective if the board appeals to the developers to get some regression/bug fixing done before looking at further feature work or non-essential code re- factoring (it's even in the roadmap if anybody is still reading that). To be honest I'm a bit unhappy with how this is handled in the Inkscape project right now :-/.
The board isn't developer leadership. It's the money and trademark arm of the project.
So, as for getting together a bug hunt, that's a developer team decision. Bryce, Eduard, Martin, anyone could set that up (and it sounds like a good idea)
Best Regards, Martin Owens
participants (4)
-
Bryce Harrington -
C R -
Eduard Braun -
Martin Owens