Hi,
I’ve been thinking about the current code/release management process and would
like to propose and improvement.
The shorter time in which the trunk is open for development is helping us avoiding to
pile up too many new features that might destabilize the code, at the same time,
we still have five months or open development (the plan was to make 4, but we
actually did five this time) and then a beta that lumps all the improvements in one shot.
I think this is still bad, too much stuff reaches the users in a single shot, and the development
of a certain new feature might be months old by the time we reach the release.
Imho it would be better, if we can, to do a blog post the moment the new feature hits
the code base, to suggest interested parties to try it out off the nightly build, and gather
feedback sooner rather than later.
A further improvement to that would be to have a windows installer for the “trunk” nightly builds,
as the windows platform still seems the preferred one when it comes to just trying out
the software
Opinions?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Definitely a great idea.
If the windows installer is easy that’s great. But I think it also could be sufficient to just prominently feature a little write up on ‘testing nightlies with windows’, where we tell people how to call the .bat script (I think we still include that in the binary download?). Or how to install tomcat and drop in a war. I just feel like people down to help out with super early testing could be willing to take a small step to test on windows.
One other alternative could also be to create alpha releases for each new feature. Not sure if we’re at the ease of release that we all want, but if/when it is easy to tag a nightly as an alpha then that’s a nice way to communicate that we want testing. But I think blog post on nightlies could definitely be sufficient.
···
On Mon, Mar 11, 2013 at 9:56 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I’ve been thinking about the current code/release management process and would
like to propose and improvement.
The shorter time in which the trunk is open for development is helping us avoiding to
pile up too many new features that might destabilize the code, at the same time,
we still have five months or open development (the plan was to make 4, but we
actually did five this time) and then a beta that lumps all the improvements in one shot.
I think this is still bad, too much stuff reaches the users in a single shot, and the development
of a certain new feature might be months old by the time we reach the release.
Imho it would be better, if we can, to do a blog post the moment the new feature hits
the code base, to suggest interested parties to try it out off the nightly build, and gather
feedback sooner rather than later.
A further improvement to that would be to have a windows installer for the “trunk” nightly builds,
as the windows platform still seems the preferred one when it comes to just trying out
the software
Opinions?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave™: Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I like the idea of doing blog posts as features come out, however I question how useful this will be without requiring documentation for features as they hit the trunk. Perhaps we should be a bit stricter on new features that will show up in a nightly build (that is changes to core, extension and “Releasable” community modules) stating that they need to be accompanied with documentation.
This would have the upside of making the blog post more useful in that not only will it give users a heads up about a new feature it will point them directly at the relevant docs, which aren’t always that easy to find when they do exist.
$0.02
···
On Mon, Mar 11, 2013 at 8:46 AM, Chris Holmes <chomie@anonymised.com> wrote:
Definitely a great idea.
If the windows installer is easy that’s great. But I think it also could be sufficient to just prominently feature a little write up on ‘testing nightlies with windows’, where we tell people how to call the .bat script (I think we still include that in the binary download?). Or how to install tomcat and drop in a war. I just feel like people down to help out with super early testing could be willing to take a small step to test on windows.
One other alternative could also be to create alpha releases for each new feature. Not sure if we’re at the ease of release that we all want, but if/when it is easy to tag a nightly as an alpha then that’s a nice way to communicate that we want testing. But I think blog post on nightlies could definitely be sufficient.
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave™: Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, Mar 11, 2013 at 9:56 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I’ve been thinking about the current code/release management process and would
like to propose and improvement.
The shorter time in which the trunk is open for development is helping us avoiding to
pile up too many new features that might destabilize the code, at the same time,
we still have five months or open development (the plan was to make 4, but we
actually did five this time) and then a beta that lumps all the improvements in one shot.
I think this is still bad, too much stuff reaches the users in a single shot, and the development
of a certain new feature might be months old by the time we reach the release.
Imho it would be better, if we can, to do a blog post the moment the new feature hits
the code base, to suggest interested parties to try it out off the nightly build, and gather
feedback sooner rather than later.
A further improvement to that would be to have a windows installer for the “trunk” nightly builds,
as the windows platform still seems the preferred one when it comes to just trying out
the software
Opinions?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave™: Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Mon, Mar 11, 2013 at 4:29 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
I like the idea of doing blog posts as features come out, however I question how useful this will be without requiring documentation for features as they hit the trunk. Perhaps we should be a bit stricter on new features that will show up in a nightly build (that is changes to core, extension and “Releasable” community modules) stating that they need to be accompanied with documentation.
Eh, I fully agree that we eventually should get there.
Once we required just code.
Now we’re asking for code + tests, and I still find myself having to ask people to write tests, explaining why, even to people that have experience.
Going code + test + doc is a goal, but… it seems we’re far away.
In any case, I fully agree that before blogging one should prepare some docs.
By making the blog one gets some benefit, both in terms of image return and feedback on the code presented,
so asking for a bit of extra work to make some docs seems fair.
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
On Mon, Mar 11, 2013 at 12:41 PM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Mon, Mar 11, 2013 at 4:29 PM, Justin Deoliveira <jdeolive@anonymised.com>wrote:
I like the idea of doing blog posts as features come out, however I
question how useful this will be without requiring documentation for
features as they hit the trunk. Perhaps we should be a bit stricter on new
features that will show up in a nightly build (that is changes to
core, extension and "Releasable" community modules) stating that they need
to be accompanied with documentation.
Eh, I fully agree that we eventually should get there.
Once we required just code.
Now we're asking for code + tests, and I still find myself having to ask
people to write tests, explaining why, even to people that have experience.
Going code + test + doc is a goal, but... it seems we're far away.
Agreed. But in this case I think we could probably just limit it to "big"
new features.
In any case, I fully agree that before blogging one should prepare some
docs.
By making the blog one gets some benefit, both in terms of image return
and feedback on the code presented,
so asking for a bit of extra work to make some docs seems fair.
I agree
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, Mar 11, 2013 at 1:51 PM, Justin Deoliveira <jdeolive@anonymised.com>wrote:
On Mon, Mar 11, 2013 at 12:41 PM, Andrea Aime <
andrea.aime@anonymised.com> wrote:
On Mon, Mar 11, 2013 at 4:29 PM, Justin Deoliveira <jdeolive@anonymised.com>wrote:
I like the idea of doing blog posts as features come out, however I
question how useful this will be without requiring documentation for
features as they hit the trunk. Perhaps we should be a bit stricter on new
features that will show up in a nightly build (that is changes to
core, extension and "Releasable" community modules) stating that they need
to be accompanied with documentation.
Eh, I fully agree that we eventually should get there.
Once we required just code.
Now we're asking for code + tests, and I still find myself having to ask
people to write tests, explaining why, even to people that have experience.
Going code + test + doc is a goal, but... it seems we're far away.
Agreed. But in this case I think we could probably just limit it to "big"
new features.
In any case, I fully agree that before blogging one should prepare some
docs.
By making the blog one gets some benefit, both in terms of image return
and feedback on the code presented,
so asking for a bit of extra work to make some docs seems fair.
I agree
Sorry, premature send. I was going to say I agree and folks that are doing
larger scale feature development are probably planning on writing docs
anyways, this would really just be urging them to do it before the feature
is publicized.
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I can see the advantages, particularly in getting more people to test new code as it comes out, but the cold hard reality is that those features are not much use without stability - particularly if there are regressions. If you don't have a development server, then you are only going use full releases.
I'm trying to encourage more use of the development system (which links latest/greatest webapps to development server) by internal users though so if we get a spangly new feature in a nightly build, I would be inclined to speed it onto the development system.
Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.