Re: [Libreoffice-qa] When it's time to basic bases?

2015-08-01 Thread Joel Madero
I skimmed this and really...this isn't how the team works. We don't have 
someone come and insist and dictate how we do our work. If you want 
then the best thing for you to do is lead by example and then if it 
works, others will follow. With that, I'm not going to say anything 
specific with regards to anything in this because it's just a lot of 
insist on a massive amount of changes and telling volunteers how to do 
their volunteering. Really not how the project works.



Best,
Joel

On 07/29/2015 05:16 PM, Miguel Ángel wrote:
I have had this mail in the freeze for months, but seeing the 
discussion about unit test on dev's ML, the interest for the Help 
Authoring Extension, and the recent thread in QA ML about how recruit.


There are a lot of fantastic changes and improvements in LibreOffice, 
what I'm sure is a pride for all of us.


But, always there is a but, my perception on a common feel about 
LibreOffice, is that it has a lot of improvements but with too much 
issues.


To find the best way in doing the things, there is not other way than 
to be a bit critics with our self and test if we are doing the things 
so well as we can.


What I perceive is that everyone does what she/he likes and how she/he 
likes, well, maybe a bit exaggerated from my side.


Sure it was fine in the beginning of the project, because at those 
times the priority was to go forward, but some time ago we should have 
started to change to look for a better way. 
http://nabble.documentfoundation.org/Libreoffice-qa-Looking-for-a-new-approach-in-QA-workflow-tc4052468.html


I know sometimes it's needed even more it's indispensable, force 
things and go a step forward to moving ahead.


But I'm feel obligated to insist, that at least a very basic steps to 
follow, need to be established, specially about new improvements.


a) New additions, and specially modifications, implies changes that 
always affect someone in someway, then have a previous discussion in 
the right place of the project, finding the pros and cons, to reach a 
minimal consensus, allows the Author have more security about what is 
doing, having a first feedback for a better implementation.


b) At least with the first commit of any addition, and with new 
changes, a breve explanation, about:

 - What it's the target?
 - How it supposed it must work?

c) Announce in QA ML when the implementation is ready to verify, with 
what and how verify by QA, so we can do a truth QA job.


d) Encourage make public the intentions about new works, because maybe 
others have tried first and someone can help in some way, avoiding 
duplicated works.


Often putting black on white forces oneself understand better and 
rethink about what is doing, helping in to do it better.


Help others to help, specially for verification purposes. Sometimes is 
hard to help people in forums/ML, but even worse, looking for 
something, when there is not any kind of help in the program and nowhere.


IMHO I's unacceptable having implementations in LibreOffice without a 
minimal help, for me a job without help, it's not finished and it 
shouldn't be released.


I have not doubt, that improving the QA only can leads to a less prone 
to error improvements - less developing time - more time for more 
improvements.


Really, e.g., we can't find a way to have professionals, helping in 
develop a better QA process, when we have the opportunity.


Is there any problem on having a basic rules?, or it's possible e.g. 
don't follow the languages rules to write the code.


We must take into consideration that the whole merit for a quality job 
it's for their Author, so I can't see any issue for their side.


Miguel Ángel.

An open project needs open minds.

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: 
http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? 
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/

Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/


___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Minutes of ESC call: 2015-07-30

2015-08-01 Thread Tommy
On Sat, 01 Aug 2015 02:43:41 +0200, Jan Holesovsky ke...@collabora.com  
wrote:




* Release Engineering update (Christian)
+ 4.4.5 - RC2 status
+ released as final earlier today, done
+ will update the online update soon



would you please take a look at this:
https://bugs.documentfoundation.org/show_bug.cgi?id=92791#c8

is the update mechanism not yet correctly aligned to the latest release?



--
Using Opera's revolutionary email client: http://www.opera.com/mail/

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/