<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Calibri"><br>
<big>I agree with Juca, I think this is going to be solved only
with process. We are waiting until the last moments before a
Hawkular release to make component releases and that is killing
us. I don't think Juca's proposal goes far enough in that I
think the release dates should be earlier; for base components,
a week of planned quiet time prior to the hawkular release.
Furthermore, I think the components are getting mature enough to
stick to a release schedule. Now we, the developers, need to
be mature enough to apply more discipline to what we are
producing.<br>
</big></font>
<ul>
<li><font face="Calibri"><big>release dates should be in Jira,
should be based on the next hawkular release, and should be
reliable</big></font></li>
<ul>
<li><font face="Calibri"><big>jiras should have Fix versions
assigned as best as possible to reflect what is going to
be in the release<br>
</big></font></li>
<li><font face="Calibri"><big>slips, breaking changes, etc must
be made very public</big></font></li>
<li><font face="Calibri"><big>stability should start to take
precedence over refactoring/elegance<br>
</big></font></li>
</ul>
<li><font face="Calibri"><big>back compat/stability: it would be
nice if a component/hawkular did not *have* to always
upgrade to the latest version of a dependency.</big></font></li>
<li><font face="Calibri"><big>updating hawkular pom with a srcdep
version means hawkular requires the upcoming .Final release</big></font></li>
<li><font face="Calibri"><big>srcdeps removed/.Final versions updated
in the hawkular pom prior to hawkular milestone:<br>
</big></font></li>
<ul>
<li><font face="Calibri"><big>at least 7 days prior: parent,
bus, commons, accounts, command gateway, </big></font></li>
<li><font face="Calibri"><big>at least 5 days prior: inventory,
alerts, metrics, agent, BTM (when it is incorporated)</big></font></li>
<li><font face="Calibri"><big>at least one day prior: console</big></font></li>
</ul>
</ul>
<br>
<br>
<div class="moz-cite-prefix">On 12/16/2015 4:52 AM, Juraci Paixão
Kröhling wrote:<br>
</div>
<blockquote cite="mid:5671346F.8090303@redhat.com" type="cite">
<pre wrap="">On 16.12.2015 10:35, Peter Palaga wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I still think that speaking with one's upstream before releasing is the
most flexible and reliable way of solving the present problem.
</pre>
</blockquote>
<pre wrap="">
+1 . The problems discussed in this thread are, IMO, inherent to our
modular design. I certainly don't want an update to Accounts to be
propagated right away to all components, as a bug there might block
someone in a downstream component. What I certainly would want is to
have all components updated to the same accounts version by a given date.
I'm still convinced that we need some sort of code freeze, or, at least,
a component freeze, like any multi-module project with complex
dependencies have, such as a Linux distribution.
My suggestion (based on our current dependency graph):
- Thursday before the release: Parent, Commons and Accounts
- Friday before the release: Inventory, Metrics, BTM
- Monday before the release: Command Gateway, Agent, Alerts
- Tuesday (release day): Hawkular
This should give us enough time to fix any last-minute issues.
- Juca.
_______________________________________________
hawkular-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>