There is always one rule that overwrites all:

Features that have outstanding bugs and are not fixed in between two release 
candidates will be disabled.

So maybe the checkbox is a reminder for the developer that he has outstanding 
work to do …. or useless …

Nils


Am 15.03.2012 um 18:44 schrieb Tobias Wunden:

> I am not sure there is any process in place right now. I have been advocating 
> a couple of times for requiring developers who change anything related to 
> databases to provide working and tested update scripts (and will keep doing 
> so).
> 
> Any other approach (including the checkbox on the Jira ticket) will in my 
> mind lead to a major overhead during QA (certainly as long as there is no 
> reliably schema generation in place) and even worse to offloading the 
> responsability for catching all relevant codechanges and producing correct 
> ddl and update scripts to the release manager, who already has enough on his 
> plate.
> 
> It is almost as if I were allowed to change some REST endpoint and then 
> simply tick a checkbox, suggesting that I'm done. Instead, I am required to 
> adjust the remote implementation, adjust the integration tests, update (or 
> create) documentation and, last but not least, let my fellow co-developers 
> and adopters know that this REST endpoint will change, so they are able to 
> prepare for the next release and adjust their local integrations accordingly.
> 
> We all want a stable system that is trusted (and further recommended) by our 
> adopters. By allowing (and making it easy for) developers to push off tasks 
> that they don't like that are critical to keeping adopters on board and 
> facilitate adopting institutions to follow the releases we are directl 
> walking into the opposite direction: who would want to invest into a system 
> that first and foremost appears to be a few developer's playground? Rolling 
> out a lecture capture program is a major undertaking and requires a certain 
> amount of trust into the system and its surrounding (aka developers and 
> community). If we as a project are not able to build this trust, Matterhorn 
> cannot be a relevant choice for institutions that take lecture capture 
> seriously. And that would be a shame, given that we offer standards, 
> scalability, openness and lots of features part of which are well ahead of 
> our competitors.
> 
> Sorry if this has turned into a long winded rant. But I we probably won't 
> have too many opportunities to screw up release management and even more so 
> migration strategies.
> 
> Tobias
> 
> 
> On 15.03.2012, at 17:48, Nils Hendrik Birnbaum 
> <[email protected]> wrote:
> 
>> At the moment, the checkbox does nothing. We just decide, that we need it. 
>> We should add the underling process to Tobias proposal for the 1.4 Release 
>> processes.
>> 
>> regards
>> Nils
>> 
>> Am 15.03.2012 um 16:21 schrieb Greg Logan:
>> 
>>> So, now that we have the convenient 'Conversion script required' button,
>>> what does that actually do?  Does the RM need to have a filter setup to
>>> look for these tickets?  Does it email list?
>>> 
>>> G
>>> 
>>> _______________________________________________
>>> Matterhorn mailing list
>>> [email protected]
>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
>>> 
>>> 
>>> To unsubscribe please email
>>> [email protected]
>>> _______________________________________________
>> 
>> _______________________________________________
>> Matterhorn mailing list
>> [email protected]
>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
>> 
>> 
>> To unsubscribe please email
>> [email protected]
>> _______________________________________________
> _______________________________________________
> Matterhorn mailing list
> [email protected]
> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> 
> 
> To unsubscribe please email
> [email protected]
> _______________________________________________

_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to