2015-12-21 17:57 GMT+01:00 Thomas D. <[email protected]>:
> Hi,
>
> I agree with everything David and Michael already said. But I wouldn't
> add a time-limit for pushing a new release: For example if there's a
> broken release tarball or a really bad bug which broke major
> functionality but which only affects some architectures we maybe won't
> notice that within the first 24-72 hours (remember the nasty x86 bug in
> the ~8.8 release?).
>
> I would always push a new release if the release tarball isn't usable or
> a major functionality is somehow unusable. Now all we have to do is to
> define what we call a major functionality and if we all consider a
> broken test suite critical or not ;)
I think this is the root of our disagreement: If we had have a
critical situation, I would have immediately done a new release. This
is my school of thought:
The problem cannot result in malfunction of code being executed.
It affects only the build process.
Few people build rsyslog from source.
Those few are skilled and know their way around.
Even fewer people try to run the testbench.
So we have a *very small* set of *very skilled* people who are
affected by the bug, which cannot cause any issue at all in
deployment.
This, for me, is the *prototype case* for a minor bug that does *not*
require a re-release, because those few people can easily apply a
patch.
I am so hesistant to agree because I think if we do re-releases for
such minor problems, we actually need to do re-releases for all bug
fixes except static analyzer false positive reports being worked
around.
I think, however, that David's suggestion of re-releasing even for
minor things if they come up very quickly after release makes a lot of
sense. Especially as those nits usually occur immediately and now even
probably never occur again as I have applied your suggestion to
improve CI.
>
>
> Some additional comments:
>
> Like Rainer quoted in my mail from October 2014: If you (rsyslog team)
> are not ready to publish a new feature on a scheduled date, that's fine.
> Do _not_ publish this code because just we hit the release date.
That's impractical, because if you say you run on a schedule, people
expect you to actually do so and adjust their schedules accordingly.
So you need to publish in order to avoid confusion ("what has gone so
wrong that they are unable to...?").
>
> One important thing about this release cycle is that it should _remove
> pressure_ from all: If we miss a date, don't worry, we all already know
> when the next opportunity will appear.
> So you _did everything right_ by pulling these changes for the v8.14
> release when they weren't yet ready for _some_ reasons (and that will
> include "feelings": If your stomach worries about the changes, do _not_
> publish! Your are the one who knows best about rsyslog. We all trust you
> and nobody will blame you for hiding back a new feature (remember that
> people can always pull from git if they cannot wait)).
I was not so much concerned on not releasing the fix "in time" but
more on the fact that a fix which really would have done good for some
folks needed to be held back 5 weeks (as it was not an emergency). But
I agree, usually not a big deal. I just wanted to put the focus
straight here.
On this specifuically to make my core concern clear:
> (remember that
> people can always pull from git if they cannot wait)).
Yup, but most actually cannot because they are not skilled enough. But
when following this paradigm, I need to really treat this wrong
tarball as very low prio as said above. Think about it: isn't who
actually build software much more in the position to do what you
propose vs. a causal user installing packages?
That affects my severity rating very much...
>
> Also don't worry because you are doing a big release before holiday: You
> should only care about the code/product quality. If the new release
> meets the quality the rsyslog team wants to ship, ship it. If it don't
> meet the quality or you just don't know, wait.
>
As an ole' data center guy let me say: you never ever know something
for sure, not even when running IBM mainframe OS and intentionally
keeping on old releases. Folks with much better QA occasionally fail,
and thus you'll never see a data center do upgrades when limited folks
are available for fixing. At least I hope this still holds... No
matter how much testing you put in, reality always has a different
twist.
> And if you ship there are always the user/distro maintainers who will
> decide at the end of the day if they will adopt the new release or wait
> for _their_ reasons. ;)
>
>
> Final suggestions:
>
> 1) The master branch should always be ready to release. So when you
> merge something into the master we all know that will be part of the
> next scheduled release.
That's what happens. 8.14 was an exception, because I merged into
master when we were really sure it was time to do so, but some time
later something popped up that looked like a regression (but
ultimately was not).
>
> 2) Because of #1, never ever disable tests in master for $reasons. There
> is _nothing_ which justify something like that (=so don't merge
> something with disabled tests). If there's a test failure for some
> reasons that's an indicator that the code doesn't meet the project's
> quality requirements.
Depends... we have some tests we know to be racy. Still it's good to
have them as we know how to deal with that. Do you suggest I
completely remove these tests? I can do if that is the overall
consensus.
> Don't even start thinking "Well, that's just a
> small test... and I also know that's a bad test I wanted to replace/get
> rid of years ago... do I really have to care?" -- Define quality. Make
> sure that features are tested. Don't accept contributions without tests
> (while it is nice to have contributions, once you have integrated the
> code the rsyslog project will become responsible for maintaining that
> code. Because of that only accept things if they meet your requirements).
I mostly agree, but refer you back to last years discussion thread for
differences, because this is identical.
>
> You can always play around in feature branches. But keep the master in a
> well known reliable state.
>
>
> -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.
