On Thu, 30 Oct 2014, Radu Gheorghe wrote:
-1 for time-based releases, as I think they're more appropriate for [much]
bigger projects. I would release when it's worth releasing (i.e. it's ready
when it's ready)
Two problems I have with "when it's ready" releases (or two aspects of the same
problem)
1. they are unpredictable for users and distros
2. how do you decide that you have enough features? a single feature is enough
to want a new release for the person who needs that feature, and a hundred
features that someone doesn't need aren't enough to justify the hassle of doing
an upgrade.
If we had a roadmap of what is going to be in the next release, then doing "when
it's ready" for those features could make sense. But rsyslog doesn't have such a
roadmap, and the ongoing improvements tend to be individually small.
Regarding code quality: I have a QA background so I tend to put a[n overly]
big price on testing and documentation. But I still wouldn't stop moving
forward with the project for the sake of quality - Rainer adds juicy stuff
with every release and, looking back, I'm always thinking what a nice
progress this project has made.
However, I think there's increasing debt in terms of tests and docs as new
features are added. As rsyslog gets more complex, it looks harder to keep
it stable.
I think we are doing fairly well in tests, but I agree docs lag. But I'm also
not sure that delaying features (something Rainer is good at doing) in favour of
docs (something that Rainer is not as good at doing, in large part because he is
so close to the problem) is a good idea. There were reasons for splitting the
documentation off to a separate 'project', and they still hold, even though we
didn't get a large group of new documentation contributers.
David Lang
So I would go with something in the middle: when a new feature is done,
let's add docs and some basic tests to the testbench to it. If we want to
make exceptions, let's add a github issue with a few useful pointers so we
can "catch up" later.
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/
On Thu, Oct 30, 2014 at 2:35 PM, singh.janmejay <[email protected]>
wrote:
+1 for testsuite and CI.
+1 for time based releases.
It'll be valuable to have adhoc minor/micro releases. Release feature by
feature or few features/fixes at a time type of thing.
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Oct 30, 2014 6:01 PM, "Thomas D." <[email protected]> wrote:
Hi,
+1 for an always working "master" branch.
Do your work in feature branches. Only merge when you think the changes
are ready. Don't merge when you think "I am ready, but this needs
testing".
Regarding the testing problem in general: I would stop adding new
features for a while. Spend more time in improving code quality.
Try to find/create a working test suite. There will always be the
problem that nobody will test your stuff. So you need a way to write
tests. Yes, creating a test suite will take some time. But in the end it
will improve the software quality and boost your development.
Remember that you can use CI for free with GitHub. Every pull request
could be automatically tested for you...
+1 for a time-based release approach.
PS: Debian Jessie will freeze at 23:59 UTC on the 5th of November 2014.
Just a reminder if you want to see some of the recent changes in
Jessie...
-Thomas
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
