[WG: Sakai QA] [Building Sakai] 2.6.x build is broken

[David Horwitz]

FYI the Hudson server builds this once a night. I have added sakai dev
to the list of notified sites for this build.   
http://builds.sakaiproject.org:8080/view/Sakai%202%20Builds/job/sakai-2.6.x%20maintenance%20branch/


//off topic
This is one of the reasons that I advocated independent releases. My
branch management experience has convinced me that our branch managment
practices are brittle and give us an over inflated confidence in our
ability to maintain branches. This is compounded by the absence of unit
tests over much of the code and the complexity of some of the tools.
Recent attempts at merging fixes to 2.6 leads me to believe that
assignments and sam are effectively no longer compatible with the trunk
code and therefore not effectively maintanable under current practices

D

On 05/12/2010 01:55 PM, Steve Swinsburg wrote:
> IMO, the branches shouldn't ever be broken. People merging to the branches should *always* be building and verifying what they are about to commit. That should catch 99% of commits that may break the build.
>
> Trunk is a bit less strict since active development happens in trunk, but when it's broken it can hold up people from their work which costs time and money. We've got tweets and emails going out from Hudson about trunk builds failing which are great, since we can get it fixed quicker. I think we need something for the branches too.
>
> As you mentioned, sometimes a build can still go ahead by skipping the broken module if it's non-essential so that is one workaround.
>
> cheers,
> Steve
>
> On 12/05/2010, at 9:42 PM, Jean-Francois Leveque wrote:
>
>   
>> Should we have a policy to deal with broken builds?
>>
>> Some time ago, I broke the 2.5.x build and I broke trunk not so long ago. Sometimes doing things quickly leads to a broken build.
>>
>> How long do we want trunk, the next version branch or a maintenance branch to have a broken build (time may differ in each case)?
>>
>> Should a build task force across time zones be ready to get builds back to working?
>>
>> A build can even be partly unusable without the build been broken.
>>
>> How often should we run the expected automated functional testing on builds?
>>
>> Jean-Francois
>>
>> Steve Swinsburg a écrit :
>>     
>>> Hi all,
>>> The 2.6.x build is broken:
>>> [ERROR] BUILD FAILURE
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] Compilation failure
>>> /Users/steve/dev/sakai/src/2.6.x/sam/samigo-services/src/java/org/sakaiproject/tool/assessment/facade/PublishedAssessmentFacadeQueries.java:[119,7] org.sakaiproject.tool.assessment.facade.PublishedAssessmentFacadeQueries is not abstract and does not override abstract method getPublishedAssessment(java.lang.Long,boolean) in org.sakaiproject.tool.assessment.facade.PublishedAssessmentFacadeQueriesAPI
>>> Due to:
>>> http://jira.sakaiproject.org/browse/SAM-696
>>>       
>>>> From the commits, the trunk and branch merges don't match and the branch is missing a method.
>>>>         
>>> Steve
>>>       
> _______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>