Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-28 Thread mikko . viinamaki
>Maybe we should do a public "call for hackers" with the help of the FSF and other friend associations around? I think this is a great idea. With some planning it could be a smash hit. In English and Spanish. Mentioning the current projects and specific skill sets needed. A very short intro

Re: [Trisquel-users] Solve bugs on a timeframe

2012-05-28 Thread Dave Hunt
Thanks for this how-to on reporting bugs; it's the sort of thing I've been looking for. Cheers, Dave

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-28 Thread ruben
and this one

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-28 Thread sirgrant
Yeah, if you guys could write documentation on how to write package helpers for volunteers (outside devel server) I think that would be very helpful.

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-28 Thread chris
I think quidam's points are all good. I'm just going to emphasise the resources issue and a few ways in which we might find solutions to these issues. I think one of the things Ubuntu has shown works well is the three year release cycle. While I know a lot of people would abandon Trisquel o

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-28 Thread ruben
ignore this test

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-28 Thread ruben
I have many pending bugs to review, sorry about that. I'm done with traveling for the year, so I'll be catching up with those tasks from now on. Regarding the documentation, there may be some glitches, mostly due to that code being used just by me and Aklis (and then only inside the devel ser

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-28 Thread sirgrant
Ok here are some modifications because I agree with you. * Bug reports for packages not included in the default Trisquel install will be marked as "won't fix" and should be reported upstream. * Bugs should have a patch/fix either researched or submitted when reporting. An exception would b

Re: [Trisquel-users] Solve bugs on a timeframe

2012-05-28 Thread ruben
I'll give you some answers: The main problem is the lack of hands, I still do most of the job by myself (maybe the "lack of transparency" mentioned is just me being shy about that). Also it may have been a problem that I traveled way too much this year, I'm sorry if I wasn't very responsive

Re: [Trisquel-users] Solve bugs on a timeframe

2012-05-28 Thread sirgrant
I wrote up a draft bug reporting guidelines document and wanted to throw it up for comment. I would appreciate any feedback. '''Bug reporting rules:''' '''Before Reporting a bug:''' 1 Check upstream to find out if this bug has been reported. Trisquel GNU/Linux is based off Ubuntu and even

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-24 Thread Morne Alberts
I don't have a response to your suggestion, but it relates to something that has been bothering me: we really need to improve communication and co-ordination within this project. I understand that quidam is really busy and that we don't have many (or any other?) people working on core development.

Re: [Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-24 Thread mikko . viinamaki
I also think it's very important the users are not treated as consumers. We already want to take part and help the project. The worst thing to do is to ignore reported issues. It would be a million times better even to just say "No, this will not be fixed because of ..." Trisquel's developm

[Trisquel-users] Solve bugs on a timeframe depending on the priority

2012-05-24 Thread Quiliro Ordóñez
https://trisquel.info/es/issues/5565 I was checking reported bugs. There are critical bugs that were not solved for versions as old as 2.0. There wasn't even a reason about why they were not solved or what was needed for them to be solved. It is critical not to leave users alone. In the worst