GSoC 2009 - Project handling in the repository
Hey All,
Due to concerns and issues voiced in the past, it seems like we should talk about how GSoC projects should be handled in our repository. A big concern is the impact on Trunk and if we want to release 0.47 with minimal pain this year. Given that I'm the hold-over release warden for 0.47, and that I have also taken on future release related duties from bryce... I'd like to see things work as smoothly as possible.
What are some thoughts on what to do? Should we stick to the way we did it in the past and potentially introduce much more breakage in the near future? Branches on an as-needed basis? Perhaps just a GSoC2009 branch for all students work to be committed to?
I could see the latter being beneficial to ease testing all their work with no harm to trunk the process. Additionally, it's a great way to learn about our "don't break trunk" rule... the students will be forced to commit responsibly as breaking it would hinder all other students too (which I would hope they'd be vocal yet diplomatic in handling).
Any and all thoughts are welcome.
Cheers, Josh
Are we seriously not expecting to get 0.47 out before SoC09 code starts hitting svn?
2009/3/19 Joshua A. Andler <scislac@...400...>:
Hey All,
Due to concerns and issues voiced in the past, it seems like we should talk about how GSoC projects should be handled in our repository. A big concern is the impact on Trunk and if we want to release 0.47 with minimal pain this year. Given that I'm the hold-over release warden for 0.47, and that I have also taken on future release related duties from bryce... I'd like to see things work as smoothly as possible.
What are some thoughts on what to do? Should we stick to the way we did it in the past and potentially introduce much more breakage in the near future? Branches on an as-needed basis? Perhaps just a GSoC2009 branch for all students work to be committed to?
I could see the latter being beneficial to ease testing all their work with no harm to trunk the process. Additionally, it's a great way to learn about our "don't break trunk" rule... the students will be forced to commit responsibly as breaking it would hinder all other students too (which I would hope they'd be vocal yet diplomatic in handling).
Any and all thoughts are welcome.
Cheers, Josh
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2009-03-19 at 19:56 +0000, john cliff wrote:
Are we seriously not expecting to get 0.47 out before SoC09 code starts hitting svn?
I think it's questionable how soon it can be pulled together. Let's take a vote though...
Anyone with the ability and willingness to contribute time and/or code to making this happen, say "aye". JonCruz and bulia byak, I know you're already in bug fixing mode. :)
Additionally we need to discuss some larger items related to feature completion as bug fixing is not all that needs to be done.
*Live Path Effects - It appears that they're in a reasonable place to move toward a release with no big issues, any disagreements? Johan, anything major that needs to be addressed prior to release?
*Filters - Things are still coming in at an amazing pace, and the question is when do we stop Ivan? ;) Additionally, is there any chance of us being able to get the zoom dependence issue taken care of with some of the filters? Ivan, you are probably more experienced with the filters in Inkscape than anyone else at this point, any other major issues?
*Icons - There are still missing icons, last I heard some of them were platform specific issues as well. Perhaps this work would be better moved to a branch until it is ready for trunk. Any other thoughts on this?
*LPE Tool/Technical Tool - What is the plan? Should it be completely disabled for 0.47 since Max has stated that he will be unable to work on it?
As soon as I see a few people step up, I will propose the timeline.
Cheers, Josh
Joshua A. Andler wrote:
*Filters - Things are still coming in at an amazing pace, and the question is when do we stop Ivan? ;) Additionally, is there any chance of us being able to get the zoom dependence issue taken care of with some of the filters? Ivan, you are probably more experienced with the filters in Inkscape than anyone else at this point, any other major issues?
How do those color space and dynamic range issues factor in here? Are we building up a large set of filters that will "break" when the colors are fixed?
Aaron Spike
Thanks a lot for your welcome again ;)
I reply to Joshua togheter in this message.
I don't think there will be too much broken things in filters when colours problems will be fixed. Only some tunings which may be done probably in a short time.
But the most problematic issue for illustration quality output remains as Niko told it last week :
"256 levels is not a limitation of SVG itself, but a limitation of Inkscape rendering engine. Using more than 8 bits per colour component would help with this problem, but likely would require quite a bit of work."
It has some consequences on the blur quality (banding problems) and also the progressiveness of the height maps (odd plateaus). I don't know if this work could be done for the 0.47 release. I can't evaluate the amount of work because I am not a programmer. However that's not a limitation for my work on filters.
About the zooming problem (here I mean zooming in the work space and not resizing filtered objects) it occurs only with three Bevel filters : Badge, Glowing metal and Pastel bevel.
Otherwise, no major issue. Only some little things not completely implemented (feImage and feTile for example) but I am a patient person and I am sure that will be very refreshing for me to work with these functions when they will be freshly implemented, and so even if they aren't for 0.47 ! Filters are very attractive but there are probably more important things to solve in other areas.
And finally I must apologize for not being able of stopping a bit my so fascinating and addictive filters researches and take more time to document them properly. I must do it not only to facilitate their use but also to give taste to the others of exploring their possibilities.
Thanks again and friendly, ivan
________________________________ De : Aaron Spike <aaron@...749...> À : Inkscape Devel List inkscape-devel@lists.sourceforge.net Envoyé le : Jeudi, 19 Mars 2009, 22h06mn 18s Objet : Re: [Inkscape-devel] Inkscape 0.47 - was Re: GSoC 2009 - Project handling in the repository
Joshua A. Andler wrote:
*Filters - Things are still coming in at an amazing pace, and the question is when do we stop Ivan? ;) Additionally, is there any chance of us being able to get the zoom dependence issue taken care of with some of the filters? Ivan, you are probably more experienced with the filters in Inkscape than anyone else at this point, any other major issues?
How do those color space and dynamic range issues factor in here? Are we building up a large set of filters that will "break" when the colors are fixed?
Aaron Spike
------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thu, 19 Mar 2009 21:47:07 +0000 (GMT) Ivan Louette <ivan_louette@...48...> kirjoitti:
"256 levels is not a limitation of SVG itself, but a limitation of Inkscape rendering engine. Using more than 8 bits per colour component would help with this problem, but likely would require quite a bit of work."
It has some consequences on the blur quality (banding problems) and also the progressiveness of the height maps (odd plateaus). I don't know if this work could be done for the 0.47 release. I can't evaluate the amount of work because I am not a programmer. However that's not a limitation for my work on filters.
If there is banding visible with blur, moving to higher bitdepth is not going to help (unless there are some quality-loss bugs in blur rendering): even if Inkscape internally used 16-bit colours, they must be converted to 8-bit to be displayed on screen. Some kind of dithering might help, though.
-----Original Message----- From: Niko Kiirala [mailto:niko@...1267...] Sent: 21 March, 2009 16:31 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re : Inkscape 0.47 - was Re: GSoC 2009 - Project handling in the repository
Thu, 19 Mar 2009 21:47:07 +0000 (GMT) Ivan Louette <ivan_louette@...48...> kirjoitti:
"256 levels is not a limitation of SVG itself, but a limitation of Inkscape rendering engine. Using more than 8 bits per colour component would help with this problem, but likely would require quite a bit of work."
It has some consequences on the blur quality (banding problems) and also the progressiveness of the height maps (odd plateaus). I don't know if this work could be done for the 0.47 release. I can't evaluate the amount of work because I am not a programmer. However that's not a limitation for my work on filters.
If there is banding visible with blur, moving to higher bitdepth is not going to help (unless there are some quality-loss bugs in blur rendering): even if Inkscape internally used 16-bit colours, they must be converted to 8-bit to be displayed on screen. Some kind of dithering might help, though.
The banding comes mostly from contrast manipulations, and having 16 bit representation of colors would alleviate that.
-- Niko Kiirala niko@...1267...
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Even simple blur without any use of feBlend svg primitive causes banding at display and png export.
But this is also the case with gradients.
________________________________ De : Preben Soeberg <prsodk@...400...> À : Niko Kiirala <niko@...1267...> Cc : inkscape-devel@lists.sourceforge.net Envoyé le : Samedi, 21 Mars 2009, 11h16mn 09s Objet : Re: [Inkscape-devel] Re : Inkscape 0.47 - was Re: GSoC 2009 - Project handling in the repository
-----Original Message----- From: Niko Kiirala [mailto:niko@...1267...] Sent: 21 March, 2009 16:31 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re : Inkscape 0.47 - was Re: GSoC 2009 - Project handling in the repository
Thu, 19 Mar 2009 21:47:07 +0000 (GMT) Ivan Louette <ivan_louette@...48...> kirjoitti:
"256 levels is not a limitation of SVG itself, but a limitation of Inkscape rendering engine. Using more than 8 bits per colour component would help with this problem, but likely would require quite a bit of work."
It has some consequences on the blur quality (banding problems) and also the progressiveness of the height maps (odd plateaus). I don't know if this work could be done for the 0.47 release. I can't evaluate the amount of work because I am not a programmer. However that's not a limitation for my work on filters.
If there is banding visible with blur, moving to higher bitdepth is not going to help (unless there are some quality-loss bugs in blur rendering): even if Inkscape internally used 16-bit colours, they must be converted to 8-bit to be displayed on screen. Some kind of dithering might help, though.
The banding comes mostly from contrast manipulations, and having 16 bit representation of colors would alleviate that.
-- Niko Kiirala niko@...1267...
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Sat, 21 Mar 2009 17:16:09 +0700 "Preben Soeberg" <prsodk@...400...> kirjoitti:
If there is banding visible with blur, moving to higher bitdepth is not going to help (unless there are some quality-loss bugs in blur rendering): even if Inkscape internally used 16-bit colours, they must be converted to 8-bit to be displayed on screen. Some kind of dithering might help, though.
The banding comes mostly from contrast manipulations, and having 16 bit representation of colors would alleviate that.
Yes, that's true. And it's not only blur and contrast manipulation. Most filter combinations would benefit to some extent from using 16-bit colours.
However, as there have been claims that banding can occur even with blur only, I've tried running some tests. And well, I've found nothing. All blurs are as smooth as they can be. Naturally, as we are producing images with 8 bits per channel, the quantization error is inevitable but that's hardly visible at all. (OK, it's inevitable with any bitdepth, but a lot smaller with higher bitdepths)
Could someone provide a small example file (SVG) exhibiting banding with simple blur? Or any pointers whatsoever for finding them.
My apologies !
I compared blur and gradients results in Inkscape devel and Xara Pro 4.0 and didn't notice any difference in banding. It's there but it's hardly visible as you told it.
However banding is allways very visible in glows around objects while using filters with specular light. A lot of bevel filters and some materials and textures show this banding. But this is annoying only for illustration design while objects sizes in web design don't allow to notice it.
ivan
________________________________ De : Niko Kiirala <niko@...1267...> À : inkscape-devel@lists.sourceforge.net Envoyé le : Samedi, 21 Mars 2009, 19h45mn 24s Objet : [Inkscape-devel] Colour banding in filters? (was: Inkscape 0.47)
Sat, 21 Mar 2009 17:16:09 +0700 "Preben Soeberg" <prsodk@...400...> kirjoitti:
If there is banding visible with blur, moving to higher bitdepth is not going to help (unless there are some quality-loss bugs in blur rendering): even if Inkscape internally used 16-bit colours, they must be converted to 8-bit to be displayed on screen. Some kind of dithering might help, though.
The banding comes mostly from contrast manipulations, and having 16 bit representation of colors would alleviate that.
Yes, that's true. And it's not only blur and contrast manipulation. Most filter combinations would benefit to some extent from using 16-bit colours.
However, as there have been claims that banding can occur even with blur only, I've tried running some tests. And well, I've found nothing. All blurs are as smooth as they can be. Naturally, as we are producing images with 8 bits per channel, the quantization error is inevitable but that's hardly visible at all. (OK, it's inevitable with any bitdepth, but a lot smaller with higher bitdepths)
Could someone provide a small example file (SVG) exhibiting banding with simple blur? Or any pointers whatsoever for finding them.
Unfortunately blur banding is also visible after .png export. Perhaps something could be done there first.
________________________________ De : Niko Kiirala <niko@...1267...> À : inkscape-devel@lists.sourceforge.net Envoyé le : Samedi, 21 Mars 2009, 10h30mn 48s Objet : Re: [Inkscape-devel] Re : Inkscape 0.47 - was Re: GSoC 2009 - Project handling in the repository
Thu, 19 Mar 2009 21:47:07 +0000 (GMT) Ivan Louette <ivan_louette@...48...> kirjoitti:
"256 levels is not a limitation of SVG itself, but a limitation of Inkscape rendering engine. Using more than 8 bits per colour component would help with this problem, but likely would require quite a bit of work."
It has some consequences on the blur quality (banding problems) and also the progressiveness of the height maps (odd plateaus). I don't know if this work could be done for the 0.47 release. I can't evaluate the amount of work because I am not a programmer. However that's not a limitation for my work on filters.
If there is banding visible with blur, moving to higher bitdepth is not going to help (unless there are some quality-loss bugs in blur rendering): even if Inkscape internally used 16-bit colours, they must be converted to 8-bit to be displayed on screen. Some kind of dithering might help, though.
On 3/19/09, Joshua A. Andler <scislac@...400...> wrote:
*Live Path Effects - It appears that they're in a reasonable place to move toward a release with no big issues, any disagreements? Johan, anything major that needs to be addressed prior to release?
Except most written LPE are marked as unstable and are not available to users :) Can't say for everybody else, but I've experienced a number of crashes "thanks" to LPE, so to me they need attention.
*Filters - Things are still coming in at an amazing pace, and the question is when do we stop Ivan? ;)
We need a GSoC project to invent tools to stop him :)
What I'm concerned about is how we document all these filters. But this is for inkscape-docs@, perhaps.
There are some both rendering and non-rendering issues with SVG Filters. I'll see if they are already logged in the tracker.
*LPE Tool/Technical Tool - What is the plan? Should it be completely disabled for 0.47 since Max has stated that he will be unable to work on it?
ifdef?
Alexandre
-----Original Message----- From: Alexandre Prokoudine [mailto:alexandre.prokoudine@...400...] Sent: donderdag 19 maart 2009 22:55 To: Joshua A. Andler Cc: Inkscape Devel List; john cliff Subject: Re: [Inkscape-devel] Inkscape 0.47 - was Re: GSoC 2009 - Projecthandling in the repository
On 3/19/09, Joshua A. Andler <scislac@...400...> wrote:
*Live Path Effects - It appears that they're in a
reasonable place to
move toward a release with no big issues, any disagreements? Johan, anything major that needs to be addressed prior to release?
Except most written LPE are marked as unstable and are not available to users :) Can't say for everybody else, but I've experienced a number of crashes "thanks" to LPE, so to me they need attention.
Undoing LPE path parameter editing crashes Inkscape; I don't know other crashes. The reason I've disabled many effects is mainly because most of them haven't got a 'stable' parameter set, or are inconvenient to use. I'm also into bug fixing mode (quite some time already); I'll see what I can do about the crash.
-Johan
Not major issues but somewhat annoying...
- When applied to outlines filters render much slower
- When applied to outlines they have clipping problems (like if the outline width was substracted from the total wisth of the shape ?)
- When applied to bitmaps rendering doesn't refresh after changing filter settings (one must unselect and reselect the filter or slightly move the bitmap or change the display mode)
I would also add something to my wishlist :
- the possibility to select objects or groups by their filter in the Filters Editor. I mean that if you (double?)click on a filter in the Filters Editor list any object or group onto which this filter is applied is automatically selected.
ivan
________________________________ De : Joshua A. Andler <scislac@...400...> À : john cliff <john.cliff@...400...> Cc : Inkscape Devel List inkscape-devel@lists.sourceforge.net; Johan Engelen <j.b.c.engelen@...1578...>; Ivan Louette <ivan_louette@...48...> Envoyé le : Jeudi, 19 Mars 2009, 21h53mn 48s Objet : Inkscape 0.47 - was Re: [Inkscape-devel] GSoC 2009 - Project handling in the repository
On Thu, 2009-03-19 at 19:56 +0000, john cliff wrote:
Are we seriously not expecting to get 0.47 out before SoC09 code starts hitting svn?
I think it's questionable how soon it can be pulled together. Let's take a vote though...
Anyone with the ability and willingness to contribute time and/or code to making this happen, say "aye". JonCruz and bulia byak, I know you're already in bug fixing mode. :)
Additionally we need to discuss some larger items related to feature completion as bug fixing is not all that needs to be done.
*Live Path Effects - It appears that they're in a reasonable place to move toward a release with no big issues, any disagreements? Johan, anything major that needs to be addressed prior to release?
*Filters - Things are still coming in at an amazing pace, and the question is when do we stop Ivan? ;) Additionally, is there any chance of us being able to get the zoom dependence issue taken care of with some of the filters? Ivan, you are probably more experienced with the filters in Inkscape than anyone else at this point, any other major issues?
*Icons - There are still missing icons, last I heard some of them were platform specific issues as well. Perhaps this work would be better moved to a branch until it is ready for trunk. Any other thoughts on this?
*LPE Tool/Technical Tool - What is the plan? Should it be completely disabled for 0.47 since Max has stated that he will be unable to work on it?
As soon as I see a few people step up, I will propose the timeline.
Cheers, Josh
On 3/21/09, Ivan Louette wrote:
Not major issues but somewhat annoying...
Also:
1. Apply any filter from menu. Non-localized name will be displayed in both editor and status bar. 2. Remove filter from the object using "Filters->Remove" 3. Apply another filter -- previous filter becomes something like "filter10185" and the new one is in English again. Sometimes a new filter has a name like "filter 10125". 4. For each selected object a new filter is created. I can see that it can make sense, but really not always :) 5. When you remove a filter from an object and filter editor is present, checkbox will still be visible until you reselect the object.
Alexandre
On Thu, Mar 19, 2009 at 01:53:48PM -0700, Joshua A. Andler wrote:
On Thu, 2009-03-19 at 19:56 +0000, john cliff wrote:
Are we seriously not expecting to get 0.47 out before SoC09 code starts hitting svn?
I think it's questionable how soon it can be pulled together. Let's take a vote though...
Anyone with the ability and willingness to contribute time and/or code to making this happen, say "aye". JonCruz and bulia byak, I know you're already in bug fixing mode. :)
"aye"! :-)
Well, for what limited influence I have...
Anyway, for Ubuntu I am thinking regardless, that I'd like to pull a newer version of Inkscape, even if it means just an svn snapshot, for Karmic. A more offical 0.47 or even 0.46.5 would be better obviously.
Seems like it's been far too long since there's been an official release, and I know there's been tons of kewl stuff gone into it, I'd like to make available to a wider audience.
Bryce
- filters (drop shaddow, etc) - snap points - the construction support (from maximiliam albert) - I know it is hidden and not completed now would be the most valuable features for me for a new release
+1 from my side to head to a 0.47 before GSOC
Adib. ---
On Thu, Mar 19, 2009 at 10:53 PM, Joshua A. Andler <scislac@...400...> wrote:
On Thu, 2009-03-19 at 19:56 +0000, john cliff wrote:
Are we seriously not expecting to get 0.47 out before SoC09 code starts hitting svn?
I think it's questionable how soon it can be pulled together. Let's take a vote though...
Anyone with the ability and willingness to contribute time and/or code to making this happen, say "aye". JonCruz and bulia byak, I know you're already in bug fixing mode. :)
Additionally we need to discuss some larger items related to feature completion as bug fixing is not all that needs to be done.
*Live Path Effects - It appears that they're in a reasonable place to move toward a release with no big issues, any disagreements? Johan, anything major that needs to be addressed prior to release?
*Filters - Things are still coming in at an amazing pace, and the question is when do we stop Ivan? ;) Additionally, is there any chance of us being able to get the zoom dependence issue taken care of with some of the filters? Ivan, you are probably more experienced with the filters in Inkscape than anyone else at this point, any other major issues?
*Icons - There are still missing icons, last I heard some of them were platform specific issues as well. Perhaps this work would be better moved to a branch until it is ready for trunk. Any other thoughts on this?
*LPE Tool/Technical Tool - What is the plan? Should it be completely disabled for 0.47 since Max has stated that he will be unable to work on it?
As soon as I see a few people step up, I will propose the timeline.
Cheers, Josh
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 3/19/09, john cliff wrote:
Are we seriously not expecting to get 0.47 out before SoC09 code starts hitting svn?
Official coding phase starts on May 23. We still have some new code not applied to trunk:
1. Maximilian's guides selection (anybody looked at it?) 2. Milosz's work on text tool 3. New Spray tool by a group of French students (mostly ready as I was told) 4. Something else I definitely forgot :)
It looks like Jon Cruz also started some long anticipated work on swatches too.
Besides, there are way too many bugs in SVN, including 39 crashers (in fact, 40 -- I just didn't register another one, but sent backtrace to J. F. Barraud directly).
Chances that we can wrap up in just two month are... well... :)
Alexandre
On Thu, Mar 19, 2009 at 11:43:14AM -0700, Joshua A. Andler wrote:
Hey All,
Due to concerns and issues voiced in the past, it seems like we should talk about how GSoC projects should be handled in our repository. A big concern is the impact on Trunk and if we want to release 0.47 with minimal pain this year. Given that I'm the hold-over release warden for 0.47, and that I have also taken on future release related duties from bryce... I'd like to see things work as smoothly as possible.
What are some thoughts on what to do?
One of the hardest things for me about managing the release is "release blocker bugs". Especially when no one was actively working on solving the bugs, these cause delays to the whole process which is very taxing.
Instead, I think we should move to more of a timed release process. Put out major releases regularly every 3 months like clockwork, and allow for doing point releases in between for any serious bugs that slipped through.
Should we stick to the way we did it in the past and potentially introduce much more breakage in the near future? Branches on an as-needed basis? Perhaps just a GSoC2009 branch for all students work to be committed to?
Even in general, having an "experimentation" branch might make the barrier of entry lower for new contributors, or people who'd like to work on something and get community testing feedback before committing to it officially.
I could see the latter being beneficial to ease testing all their work with no harm to trunk the process. Additionally, it's a great way to learn about our "don't break trunk" rule... the students will be forced to commit responsibly as breaking it would hinder all other students too (which I would hope they'd be vocal yet diplomatic in handling).
Good points.
Bryce
participants (10)
-
unknown＠example.com -
Aaron Spike -
Alexandre Prokoudine -
Bryce Harrington -
Ivan Louette -
john cliff -
Joshua A. Andler -
Niko Kiirala -
Preben Soeberg -
the Adib