<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hmmmmm well maybe a VM which validated the install from scratch on fedora would be cool. There are scripts to do this (I.e. Justin's article on building from source), which already exist. </div><div><br></div><div>Versioning them in a git repo could make the documentation "self-healing".</div><div><br></div><div>:)</div><div><br></div><div>On May 17, 2013, at 8:00 PM, Anand Avati <<a href="mailto:anand.avati@gmail.com">anand.avati@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">There is one - tests/basic/rpm.t which is run against every commit. However it only guarantees a that an RPM can be built on a machine which is similar to the build server itself.<div><br></div><div>Avati</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 17, 2013 at 5:48 PM, Jay Vyas <span dir="ltr"><<a href="mailto:jayunit100@gmail.com" target="_blank">jayunit100@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There should be a test that confirms that the build actually produces rpms :)<br>
<br>
That would have caught this bug.<br>
<br>
On May 17, 2013, at 5:54 PM, Justin Clift <<a href="mailto:jclift@redhat.com">jclift@redhat.com</a>> wrote:<br>
<br>
> On 18/05/2013, at 4:19 AM, Jay Vyas wrote:<br>
>> Ahh yes, well the lesson i learned was to build from branches instead of from master (switched to branch release-3.4) and that solved it.<br>
><br>
> Well, that's one way of doing it. :)<br>
><br>
> Personally, I do build from master 99.5% of the time, as it's<br>
> *supposed* to work all the time. The automated testing that's<br>
> done for all of the patches is (in theory) meant to stop general<br>
> breakage for things like this. Of course though, things don't<br>
> always play ball,<br>
><br>
> When it doesn't, I generally file a BZ (if one's not already<br>
> there), and try to figure out the cause/fix.<br>
><br>
><br>
>> Justin maybe on your guide to gluster installation from source you should<br>
>> also suggest this?<br>
><br>
> Including info on how to build from the branches is a decent idea.<br>
><br>
> I've been kind of avoiding it so far, because that starts down a fairly<br>
> complicated road. Different branches have slightly different needs for<br>
> compiling (different dependencies, different ./configure options), and<br>
> I've been wanting to keep that rpm compiling page as simple as possible.<br>
><br>
> Maybe that needs to be revisited though... :)<br>
><br>
><br>
>> I update my blog post that "steals" some of that content :)<br>
><br>
> Steal away. The info on that page is Community knowledge, and the<br>
> wider it gets spread/stolen/etc the better. :)<br>
><br>
> + Justin<br>
><br>
> --<br>
> Open Source and Standards @ Red Hat<br>
><br>
> <a href="http://twitter.com/realjustinclift" target="_blank">twitter.com/realjustinclift</a><br>
><br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</blockquote></div><br></div>
</div></blockquote></body></html>