Proposed idea for an interim trunk release

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposed idea for an interim trunk release

Bryce Harrington-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed idea for an interim trunk release

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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed idea for an interim trunk release

C R
In reply to this post by Bryce Harrington-3
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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed idea for an interim trunk release

Eduard Braun

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
[hidden email] 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed idea for an interim trunk release

Martin Owens-2
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed idea for an interim trunk release

C R
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" <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposed idea for an interim trunk release

C R
Paperboard = Leaderboard


On 16 Jul 2017 6:59 p.m., "C R" <[hidden email]> 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" <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Loading...