Unfortunately, we don't have access to the source code for Joomlacode
or the tracker. That is one of the reasons we have looked at trying to
replace it, preferably with a Joomla-based system. Unfortunately, it
takes a lot of time to research this and we all have limited time. So,
as far as I know, there is nothing we can do to accomplish this. If
someone else knows something more about it, please let me know.
> I offer to implement this if I can get access to the files/code.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! bug Squad" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ.
> To post to this group, send email to joomlabugsquad@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsquad+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.
On Thu, Oct 4, 2012 at 7:17 AM, Mark Dexter <dextercow...@gmail.com> wrote:
> Unfortunately, we don't have access to the source code for Joomlacode
> or the tracker. That is one of the reasons we have looked at trying to
> replace it, preferably with a Joomla-based system. Unfortunately, it
> takes a lot of time to research this and we all have limited time. So,
> as far as I know, there is nothing we can do to accomplish this. If
> someone else knows something more about it, please let me know.
> Thanks. Mark
> On Thu, Oct 4, 2012 at 2:35 AM, Peter van Westen
> <petervanwes...@gmail.com> wrote:
>> I think it would be useful to color code the table cells under 'Status' in
>> the tracker
>> (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBr...)
>> So you can quickly see if a tracker item is closed or pending or open, etc.
>> I offer to implement this if I can get access to the files/code.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Joomla! bug Squad" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ.
>> To post to this group, send email to joomlabugsquad@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomlabugsquad+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomlabugsquad?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
> To post to this group, send email to joomlabugsquad@googlegroups.com.
> To unsubscribe from this group, send email to joomlabugsquad+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.
> On Thu, Oct 4, 2012 at 7:17 AM, Mark Dexter <dexter...@gmail.com<javascript:>> > wrote: > > Unfortunately, we don't have access to the source code for Joomlacode > > or the tracker. That is one of the reasons we have looked at trying to > > replace it, preferably with a Joomla-based system. Unfortunately, it > > takes a lot of time to research this and we all have limited time. So, > > as far as I know, there is nothing we can do to accomplish this. If > > someone else knows something more about it, please let me know.
> >> So you can quickly see if a tracker item is closed or pending or open, > etc.
> >> I offer to implement this if I can get access to the files/code.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Joomla! bug Squad" group. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ. > >> To post to this group, send email to joomlab...@googlegroups.com<javascript:>.
> >> To unsubscribe from this group, send email to > >> joomlabugsqua...@googlegroups.com <javascript:>. > >> For more options, visit this group at > >> http://groups.google.com/group/joomlabugsquad?hl=en.
> > -- > > You received this message because you are subscribed to the Google > Groups "Joomla! bug Squad" group. > > To post to this group, send email to joomlab...@googlegroups.com<javascript:>.
"Or drop Joomlacode and svn completely and just use the built in functionality of github :)" But could everyone in bugsquad comment inGit Without having to install and configure software. Also in Git is there one place where the bugs for each version of Joomla can be posted. From what I've seen of Git there is no url that an ordinary user can go to.
>> On Thu, Oct 4, 2012 at 7:17 AM, Mark Dexter <dexter...@gmail.com> wrote: >> > Unfortunately, we don't have access to the source code for Joomlacode >> > or the tracker. That is one of the reasons we have looked at trying to >> > replace it, preferably with a Joomla-based system. Unfortunately, it >> > takes a lot of time to research this and we all have limited time. So, >> > as far as I know, there is nothing we can do to accomplish this. If >> > someone else knows something more about it, please let me know.
>> >> So you can quickly see if a tracker item is closed or pending or open, >> etc.
>> >> I offer to implement this if I can get access to the files/code.
>> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "Joomla! bug Squad" group. >> >> To view this discussion on the web visit >> >> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ. >> >> To post to this group, send email to joomlab...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> joomlabugsqua...@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/joomlabugsquad?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> Groups "Joomla! bug Squad" group. >> > To post to this group, send email to joomlab...@googlegroups.com. >> > To unsubscribe from this group, send email to >> joomlabugsqua...@googlegroups.com. >> > For more options, visit this group at >> http://groups.google.com/group/joomlabugsquad?hl=en.
@Kevin I'm not sure what you mean, any one can comment on any issue in github, you just need to login and you can put both attached comments and inline comments. I do think that there will be an issue when people need to make pull requests against both the 2.5 branch and against master or just one but I the goal of course is to not have much against the 2.5 branch.
@Peter This is what we are working on. The very simple proprietary github tracker (one of the few non open source parts of github so we can't actually send improvement suggestions) is not currently adequate for managing close to 100 people with status changing privileges and does not have adequate complex search and sort capabilities (although the tagging system has real potential) and does not have a seamless way to manage the links between codeless issue reports (which are very common in the CMS) and proposed fixes [e.g. you have to manually get the issue number and type it in your comment--even for the initial reporter later submitting code they have to be very specific in how they do the link to make them connect] or for duplicate report tracking (a joomlacode feature I am probably the only person using). Also in jbs it is extremely important to track manual testing and to also to have excellent reporting capabilities. Even in the comparatively slow low volume platform tracker you see that once it's above 100 open issues it's really kind of a pain and that when people make a report and disappear the reports tend to just fade away rather then have someone else step in and fix. However we hope that is what Joomla can help us with. (Also github itself has been adding useful new APIs.)
We also need to solve the issue of attachments that are not pull requests whether sample extensions illustrating problems or screenshots.
Some of the issues relate to people needing to get better at using git hub feature such as sending pull requests to each other and pulling branches from people not just from master.
JBS has always been about social coding and I'm really anxious to get to the point where we are fully taking advantage of what github offers for that.
On Friday, October 5, 2012 7:09:11 AM UTC-4, Kevin wrote:
> "Or drop Joomlacode and svn completely and just use the built in > functionality of github :)" > But could everyone in bugsquad comment inGit Without having to install and > configure software. Also in Git is there one place where the bugs for each > version of Joomla can be posted. From what I've seen of Git there is no > url that an ordinary user can go to.
> On Friday, 5 October 2012 10:34:58 UTC+1, Peter van Westen wrote:
>> Or drop Joomlacode and svn completely and just use the built in >> functionality of github :)
>> On Friday, 5 October 2012 08:41:05 UTC+2, Samuel Moffatt wrote:
>>> What I would suggest is filing a bug with the GForge folk to add it as >>> an option to their package.
>>> On Thu, Oct 4, 2012 at 7:17 AM, Mark Dexter <dexter...@gmail.com> >>> wrote: >>> > Unfortunately, we don't have access to the source code for Joomlacode >>> > or the tracker. That is one of the reasons we have looked at trying to >>> > replace it, preferably with a Joomla-based system. Unfortunately, it >>> > takes a lot of time to research this and we all have limited time. So, >>> > as far as I know, there is nothing we can do to accomplish this. If >>> > someone else knows something more about it, please let me know.
>>> >> So you can quickly see if a tracker item is closed or pending or >>> open, etc.
>>> >> I offer to implement this if I can get access to the files/code.
>>> >> -- >>> >> You received this message because you are subscribed to the Google >>> Groups >>> >> "Joomla! bug Squad" group. >>> >> To view this discussion on the web visit >>> >> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ. >>> >> To post to this group, send email to joomlab...@googlegroups.com. >>> >> To unsubscribe from this group, send email to >>> >> joomlabugsqua...@googlegroups.com. >>> >> For more options, visit this group at >>> >> http://groups.google.com/group/joomlabugsquad?hl=en.
>>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "Joomla! bug Squad" group. >>> > To post to this group, send email to joomlab...@googlegroups.com. >>> > To unsubscribe from this group, send email to >>> joomlabugsqua...@googlegroups.com. >>> > For more options, visit this group at >>> http://groups.google.com/group/joomlabugsquad?hl=en.
What is the url on Git for the comments on J3 and where is the url for the comments on 2,5 ? All I can see is lots of individual discussions on each individual pull request page. At least with Joomla code there is only 1 url for each version of Joomla.
" *is not currently adequate for managing close to 100 people with status changing privileges*" That can get complicated but if you want to limit it to just the Dev's being able to do that ... then fine no problem with that. More work for the Devs and less work for the Testers/ticket handlers.
"*Even in the comparatively slow low volume platform tracker you see that once it's above 100 open issues it's really kind of a pain and that when people make a report and disappear the reports tend to just fade away rather then have someone else step in and fix*" Yes, but is that not true about any list with 100+ entries, no matter where the list is ?
On Friday, 5 October 2012 12:51:24 UTC+1, Elin wrote:
> @Kevin I'm not sure what you mean, any one can comment on any issue in > github, you just need to login and you can put both attached comments and > inline comments. I do think that there will be an issue when people need to > make pull requests against both the 2.5 branch and against master or just > one but I the goal of course is to not have much against the 2.5 branch.
> @Peter > This is what we are working on. The very simple proprietary github tracker > (one of the few non open source parts of github so we can't actually send > improvement suggestions) is not currently adequate for managing close to > 100 people with status changing privileges and does not have adequate > complex search and sort capabilities (although the tagging system has real > potential) and does not have a seamless way to manage the links between > codeless issue reports (which are very common in the CMS) and proposed > fixes [e.g. you have to manually get the issue number and type it in your > comment--even for the initial reporter later submitting code they have to > be very specific in how they do the link to make them connect] or for > duplicate report tracking (a joomlacode feature I am probably the only > person using). Also in jbs it is extremely important to track manual > testing and to also to have excellent reporting capabilities. Even in > the comparatively slow low volume platform tracker you see that once it's > above 100 open issues it's really kind of a pain and that when people make > a report and disappear the reports tend to just fade away rather then have > someone else step in and fix. However we hope that is what Joomla can help > us with. (Also github itself has been adding useful new APIs.)
> We also need to solve the issue of attachments that are not pull requests > whether sample extensions illustrating problems or screenshots.
> Some of the issues relate to people needing to get better at using git hub > feature such as sending pull requests to each other and pulling branches > from people not just from master.
> JBS has always been about social coding and I'm really anxious to get to > the point where we are fully taking advantage of what github offers for > that.
> Elin
> On Friday, October 5, 2012 7:09:11 AM UTC-4, Kevin wrote:
>> "Or drop Joomlacode and svn completely and just use the built in >> functionality of github :)" >> But could everyone in bugsquad comment inGit Without having to install >> and configure software. Also in Git is there one place where the bugs for >> each version of Joomla can be posted. From what I've seen of Git there is >> no url that an ordinary user can go to.
>> On Friday, 5 October 2012 10:34:58 UTC+1, Peter van Westen wrote:
>>> Or drop Joomlacode and svn completely and just use the built in >>> functionality of github :)
>>> On Friday, 5 October 2012 08:41:05 UTC+2, Samuel Moffatt wrote:
>>>> What I would suggest is filing a bug with the GForge folk to add it as >>>> an option to their package.
>>>> On Thu, Oct 4, 2012 at 7:17 AM, Mark Dexter <dexter...@gmail.com> >>>> wrote: >>>> > Unfortunately, we don't have access to the source code for Joomlacode >>>> > or the tracker. That is one of the reasons we have looked at trying >>>> to >>>> > replace it, preferably with a Joomla-based system. Unfortunately, it >>>> > takes a lot of time to research this and we all have limited time. >>>> So, >>>> > as far as I know, there is nothing we can do to accomplish this. If >>>> > someone else knows something more about it, please let me know.
>>>> >> So you can quickly see if a tracker item is closed or pending or >>>> open, etc.
>>>> >> I offer to implement this if I can get access to the files/code.
>>>> >> -- >>>> >> You received this message because you are subscribed to the Google >>>> Groups >>>> >> "Joomla! bug Squad" group. >>>> >> To view this discussion on the web visit >>>> >> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ. >>>> >> To post to this group, send email to joomlab...@googlegroups.com. >>>> >> To unsubscribe from this group, send email to >>>> >> joomlabugsqua...@googlegroups.com. >>>> >> For more options, visit this group at >>>> >> http://groups.google.com/group/joomlabugsquad?hl=en.
>>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups "Joomla! bug Squad" group. >>>> > To post to this group, send email to joomlab...@googlegroups.com. >>>> > To unsubscribe from this group, send email to >>>> joomlabugsqua...@googlegroups.com. >>>> > For more options, visit this group at >>>> http://groups.google.com/group/joomlabugsquad?hl=en.
https://github.com/joomla/joomla-cms/issues Just comment and say what version and if you are making a pull request specify the correct target branch (master for J3, 2.5 for 2.5). But that is a great example of why the github tracker is not really workable without help. While people sending code can easily indicate which branch the code is for, people making issue reports don't have an easy way to mark that (because even if jbs can apply tags new reporters won't have access to the tagging plus they won't realize that it's needed just like on any other web UI people will not read instructions that you can be sure of).
I don't understand the "you:" in your comment .. the whole point is we want to keep what we have which is close to 100 people able to change statuses. I also have no idea what 'devs' you are talking about but I'm pretty sure Mark and JM want more help not less. What we need is a solution that maps well to the current processes that we have and are satisfied with and that as much as possible fixes the ones that we aren't. The way the JBS works is pretty unusual and that has made finding a product that maps well to it difficult. We don't want JBS to have to fit a tracker we want a tracker to have to fit JBS.
Currently we have about 609 issues with some kind of open status on the main tracker on joomlacode. https://github.com/popular/starred on that list I think Rails is the only one that comes close to that although it's confusing where their numbers are coming from.
On Friday, October 5, 2012 11:40:12 AM UTC-4, Kevin wrote:
> @Elin
> What is the url on Git for the comments on J3 and where is the url for the > comments on 2,5 ? All I can see is lots of individual discussions on each > individual pull request page. At least with Joomla code there is only 1 > url for each version of Joomla.
> " *is not currently adequate for managing close to 100 people with status > changing privileges*" > That can get complicated but if you want to limit it to just the Dev's > being able to do that ... then fine no problem with that. More work for > the Devs and less work for the Testers/ticket handlers.
> "*Even in the comparatively slow low volume platform tracker you see that > once it's above 100 open issues it's really kind of a pain and that when > people make a report and disappear the reports tend to just fade away > rather then have someone else step in and fix*" > Yes, but is that not true about any list with 100+ entries, no matter > where the list is ?
> On Friday, 5 October 2012 12:51:24 UTC+1, Elin wrote:
>> @Kevin I'm not sure what you mean, any one can comment on any issue in >> github, you just need to login and you can put both attached comments and >> inline comments. I do think that there will be an issue when people need to >> make pull requests against both the 2.5 branch and against master or just >> one but I the goal of course is to not have much against the 2.5 branch.
>> @Peter >> This is what we are working on. The very simple proprietary github >> tracker (one of the few non open source parts of github so we can't >> actually send improvement suggestions) is not currently adequate for >> managing close to 100 people with status changing privileges and does not >> have adequate complex search and sort capabilities (although the tagging >> system has real potential) and does not have a seamless way to manage the >> links between codeless issue reports (which are very common in the CMS) and >> proposed fixes [e.g. you have to manually get the issue number and type it >> in your comment--even for the initial reporter later submitting code they >> have to be very specific in how they do the link to make them connect] or >> for duplicate report tracking (a joomlacode feature I am probably the only >> person using). Also in jbs it is extremely important to track manual >> testing and to also to have excellent reporting capabilities. Even in >> the comparatively slow low volume platform tracker you see that once it's >> above 100 open issues it's really kind of a pain and that when people make >> a report and disappear the reports tend to just fade away rather then have >> someone else step in and fix. However we hope that is what Joomla can help >> us with. (Also github itself has been adding useful new APIs.)
>> We also need to solve the issue of attachments that are not pull requests >> whether sample extensions illustrating problems or screenshots.
>> Some of the issues relate to people needing to get better at using git >> hub feature such as sending pull requests to each other and pulling >> branches from people not just from master.
>> JBS has always been about social coding and I'm really anxious to get to >> the point where we are fully taking advantage of what github offers for >> that.
>> Elin
>> On Friday, October 5, 2012 7:09:11 AM UTC-4, Kevin wrote:
>>> "Or drop Joomlacode and svn completely and just use the built in >>> functionality of github :)" >>> But could everyone in bugsquad comment inGit Without having to install >>> and configure software. Also in Git is there one place where the bugs for >>> each version of Joomla can be posted. From what I've seen of Git there is >>> no url that an ordinary user can go to.
>>> On Friday, 5 October 2012 10:34:58 UTC+1, Peter van Westen wrote:
>>>> Or drop Joomlacode and svn completely and just use the built in >>>> functionality of github :)
>>>> On Friday, 5 October 2012 08:41:05 UTC+2, Samuel Moffatt wrote:
>>>>> What I would suggest is filing a bug with the GForge folk to add it as >>>>> an option to their package.
>>>>> On Thu, Oct 4, 2012 at 7:17 AM, Mark Dexter <dexter...@gmail.com> >>>>> wrote: >>>>> > Unfortunately, we don't have access to the source code for >>>>> Joomlacode >>>>> > or the tracker. That is one of the reasons we have looked at trying >>>>> to >>>>> > replace it, preferably with a Joomla-based system. Unfortunately, it >>>>> > takes a lot of time to research this and we all have limited time. >>>>> So, >>>>> > as far as I know, there is nothing we can do to accomplish this. If >>>>> > someone else knows something more about it, please let me know.
>>>>> >> So you can quickly see if a tracker item is closed or pending or >>>>> open, etc.
>>>>> >> I offer to implement this if I can get access to the files/code.
>>>>> >> -- >>>>> >> You received this message because you are subscribed to the Google >>>>> Groups >>>>> >> "Joomla! bug Squad" group. >>>>> >> To view this discussion on the web visit >>>>> >> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ. >>>>> >> To post to this group, send email to joomlab...@googlegroups.com. >>>>> >> To unsubscribe from this group, send email to >>>>> >> joomlabugsqua...@googlegroups.com. >>>>> >> For more options, visit this group at >>>>> >> http://groups.google.com/group/joomlabugsquad?hl=en.
>>>>> > -- >>>>> > You received this message because you are subscribed to the Google >>>>> Groups "Joomla! bug Squad" group. >>>>> > To post to this group, send email to joomlab...@googlegroups.com. >>>>> > To unsubscribe from this group, send email to >>>>> joomlabugsqua...@googlegroups.com. >>>>> > For more options, visit this group at >>>>> http://groups.google.com/group/joomlabugsquad?hl=en.
> "*While people sending code can easily indicate which branch the code is > for, people making issue reports don't have an easy way to mark that > (because even if jbs can apply tags new reporters won't have access to the > tagging"*
That is exactly what I meant when I said
> "*But could everyone in bugsquad comment inGit Without having to install > and configure software*"
Yes there are pitfalls with Joomlacode tracker but to "*Or drop Joomlacode and svn completely and just use the built in functionality of github :)*" ... might have more pitfalls. After all if a user in the forums reports a bug then ... with the current system in Joomlacode ... it is a simple mater to report the bug after testing. And I have even managed to test a few simple patches as well.
I enjoy helping out in bugsquad but feel that it could easy to fall behind with too many changes. And wonder how many other non-developers could get left behind as well? Not trying to be obstructive of improvement ... just putting a point of view that *"Or drop Joomlacode and svn completely and just use the built in functionality of github :)"* may not be a change for the best. And explaining my thought process for why not.
On Friday, 5 October 2012 23:43:42 UTC+1, Elin wrote:
> https://github.com/joomla/joomla-cms/issues > Just comment and say what version and if you are making a pull request > specify the correct target branch (master for J3, 2.5 for 2.5). But that > is a great example of why the github tracker is not really workable without > help. While people sending code can easily indicate which branch the code > is for, people making issue reports don't have an easy way to mark that > (because even if jbs can apply tags new reporters won't have access to the > tagging plus they won't realize that it's needed just like on any other web > UI people will not read instructions that you can be sure of).
> I don't understand the "you:" in your comment .. the whole point is we > want to keep what we have which is close to 100 people able to change > statuses. I also have no idea what 'devs' you are talking about but I'm > pretty sure Mark and JM want more help not less. What we need is a solution > that maps well to the current processes that we have and are satisfied with > and that as much as possible fixes the ones that we aren't. The way the > JBS works is pretty unusual and that has made finding a product that maps > well to it difficult. We don't want JBS to have to fit a tracker we want a > tracker to have to fit JBS.
> Currently we have about 609 issues with some kind of open status on the > main tracker on joomlacode. > https://github.com/popular/starred on that list I think Rails is the > only one that comes close to that although it's confusing where their > numbers are coming from.
> Elin
> On Friday, October 5, 2012 11:40:12 AM UTC-4, Kevin wrote:
>> @Elin
>> What is the url on Git for the comments on J3 and where is the url for >> the comments on 2,5 ? All I can see is lots of individual discussions on >> each individual pull request page. At least with Joomla code there is only >> 1 url for each version of Joomla.
>> " *is not currently adequate for managing close to 100 people with >> status changing privileges*" >> That can get complicated but if you want to limit it to just the Dev's >> being able to do that ... then fine no problem with that. More work for >> the Devs and less work for the Testers/ticket handlers.
>> "*Even in the comparatively slow low volume platform tracker you see >> that once it's above 100 open issues it's really kind of a pain and that >> when people make a report and disappear the reports tend to just fade away >> rather then have someone else step in and fix*" >> Yes, but is that not true about any list with 100+ entries, no matter >> where the list is ?
>> On Friday, 5 October 2012 12:51:24 UTC+1, Elin wrote:
>>> @Kevin I'm not sure what you mean, any one can comment on any issue in >>> github, you just need to login and you can put both attached comments and >>> inline comments. I do think that there will be an issue when people need to >>> make pull requests against both the 2.5 branch and against master or just >>> one but I the goal of course is to not have much against the 2.5 branch.
>>> @Peter >>> This is what we are working on. The very simple proprietary github >>> tracker (one of the few non open source parts of github so we can't >>> actually send improvement suggestions) is not currently adequate for >>> managing close to 100 people with status changing privileges and does not >>> have adequate complex search and sort capabilities (although the tagging >>> system has real potential) and does not have a seamless way to manage the >>> links between codeless issue reports (which are very common in the CMS) and >>> proposed fixes [e.g. you have to manually get the issue number and type it >>> in your comment--even for the initial reporter later submitting code they >>> have to be very specific in how they do the link to make them connect] or >>> for duplicate report tracking (a joomlacode feature I am probably the only >>> person using). Also in jbs it is extremely important to track manual >>> testing and to also to have excellent reporting capabilities. Even in >>> the comparatively slow low volume platform tracker you see that once it's >>> above 100 open issues it's really kind of a pain and that when people make >>> a report and disappear the reports tend to just fade away rather then have >>> someone else step in and fix. However we hope that is what Joomla can help >>> us with. (Also github itself has been adding useful new APIs.)
>>> We also need to solve the issue of attachments that are not pull >>> requests whether sample extensions illustrating problems or screenshots.
>>> Some of the issues relate to people needing to get better at using git >>> hub feature such as sending pull requests to each other and pulling >>> branches from people not just from master.
>>> JBS has always been about social coding and I'm really anxious to get to >>> the point where we are fully taking advantage of what github offers for >>> that.
>>> Elin
>>> On Friday, October 5, 2012 7:09:11 AM UTC-4, Kevin wrote:
>>>> "Or drop Joomlacode and svn completely and just use the built in >>>> functionality of github :)" >>>> But could everyone in bugsquad comment inGit Without having to install >>>> and configure software. Also in Git is there one place where the bugs for >>>> each version of Joomla can be posted. From what I've seen of Git there is >>>> no url that an ordinary user can go to.
>>>> On Friday, 5 October 2012 10:34:58 UTC+1, Peter van Westen wrote:
>>>>> Or drop Joomlacode and svn completely and just use the built in >>>>> functionality of github :)
>>>>> On Friday, 5 October 2012 08:41:05 UTC+2, Samuel Moffatt wrote:
>>>>>> What I would suggest is filing a bug with the GForge folk to add it >>>>>> as >>>>>> an option to their package.
>>>>>> On Thu, Oct 4, 2012 at 7:17 AM, Mark Dexter <dexter...@gmail.com> >>>>>> wrote: >>>>>> > Unfortunately, we don't have access to the source code for >>>>>> Joomlacode >>>>>> > or the tracker. That is one of the reasons we have looked at trying >>>>>> to >>>>>> > replace it, preferably with a Joomla-based system. Unfortunately, >>>>>> it >>>>>> > takes a lot of time to research this and we all have limited time. >>>>>> So, >>>>>> > as far as I know, there is nothing we can do to accomplish this. If >>>>>> > someone else knows something more about it, please let me know.
>>>>>> > Thanks. Mark
>>>>>> > On Thu, Oct 4, 2012 at 2:35 AM, Peter van Westen >>>>>> > <peterva...@gmail.com> wrote: >>>>>> >> I think it would be useful to color code the table cells under >>>>>> 'Status' in >>>>>> >> the tracker >>>>>> >> ( >>>>>> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBr...)
>>>>>> >> So you can quickly see if a tracker item is closed or pending or >>>>>> open, etc.
>>>>>> >> I offer to implement this if I can get access to the files/code.
>>>>>> >> -- >>>>>> >> You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> >> "Joomla! bug Squad" group. >>>>>> >> To view this discussion on the web visit >>>>>> >> https://groups.google.com/d/msg/joomlabugsquad/-/zamaReIVPcQJ. >>>>>> >> To post to this group, send email to joomlab...@googlegroups.com. >>>>>> >> To unsubscribe from this group, send email to >>>>>> >> joomlabugsqua...@googlegroups.com. >>>>>> >> For more options, visit this group at >>>>>> >> http://groups.google.com/group/joomlabugsquad?hl=en.
>>>>>> > -- >>>>>> > You received this message because you are subscribed to the Google >>>>>> Groups "Joomla! bug Squad" group. >>>>>> > To post to this group, send email to joomlab...@googlegroups.com. >>>>>> > To unsubscribe from this group, send email to >>>>>> joomlabugsqua...@googlegroups.com. >>>>>> > For more options, visit this group at >>>>>> http://groups.google.com/group/joomlabugsquad?hl=en.
For both github and joomlacode forum users have to register a new account and learn how to report.
I don't see what commenting and installing software have to do with each other. If you want to make a comment use the web ui to make a comment. That's exactly the same in both.
Unlike gForge, Git hub does not have a built in form building UI for administrators so it loses in the ability to ask or even require reporters to provide crucial information like cms version, php version. database and browser. Also github does not have duplicate tracking or a way to upload files. It also does not have query building/saving and downloading to csv or xls. So advantage gForge for those items.
In github you can also make a patch+ issue a pull request right on the web. I've gotten dozens of people to make contributions by saying just go to the file, click edit, make the change and click save. So for beginners with simple change proposals github wins hands down. You don't even have to learn to work with a diff file. There is no equivalent of that in gforge+svn. Adantage github.
So for people reporting issues and making simple suggested changes in code, things are either equivalent or slightly to the advantage of github.
For people who want to test I really think it depends on what process you use. For me, pulling a patch from github or from joomlacode is the same. I apply patches in the same way and test in the same way. I keep one messy branch where I apply maybe a dozen jbs patches and then periodically, when they are going to interfere with each other, I reset the whole thing. That's exactly what I did in svn except it was one checkout. For both svn and git I installed software to help me manage things.
For people who want to write code, I think at this point the consensus seems to be that github is easier and more encouraging of collaboration.
The real issue I care personally about in a self-interested way is which system makes it easiest to manage a tracker with typically 400-600 open issues and, in fact, a number of separate things i.e. a 2.5 tracker, a trunk tracker, a feature tracker, and a security tracker, and a number of trackers with historical function, plus a large number of people working in different places. Which lets me keep the most open issues in my working memory and which makes it easiest to find an old issue when I think "I know I have seen that issue before"? Also what system is JM going to complain about least :P. For the latter I'd strongly like an open source solution since the main problem with both options we have been discussing is that the only work we can do to make it work the way we want is to use apis. From what I have seen the github apis are much easier to work with.
On Friday, October 5, 2012 7:06:05 PM UTC-4, Kevin wrote:
> "*While people sending code can easily indicate which branch the code is >> for, people making issue reports don't have an easy way to mark that >> (because even if jbs can apply tags new reporters won't have access to the >> tagging"*
> That is exactly what I meant when I said
>> "*But could everyone in bugsquad comment inGit Without having to install >> and configure software*"
> Yes there are pitfalls with Joomlacode tracker but to "*Or drop > Joomlacode and svn completely and just use the built in functionality of > github :)*" ... might have more pitfalls. After all if a user in the > forums reports a bug then ... with the current system in Joomlacode ... it > is a simple mater to report the bug after testing. And I have even managed > to test a few simple patches as well.
> I enjoy helping out in bugsquad but feel that it could easy to fall behind > with too many changes. And wonder how many other non-developers could get > left behind as well? Not trying to be obstructive of improvement ... just > putting a point of view that *"Or drop Joomlacode and svn completely and > just use the built in functionality of github :)"* may not be a change > for the best. And explaining my thought process for why not.
> On Friday, 5 October 2012 23:43:42 UTC+1, Elin wrote:
>> https://github.com/joomla/joomla-cms/issues >> Just comment and say what version and if you are making a pull request >> specify the correct target branch (master for J3, 2.5 for 2.5). But that >> is a great example of why the github tracker is not really workable without >> help. While people sending code can easily indicate which branch the code >> is for, people making issue reports don't have an easy way to mark that >> (because even if jbs can apply tags new reporters won't have access to the >> tagging plus they won't realize that it's needed just like on any other web >> UI people will not read instructions that you can be sure of).
>> I don't understand the "you:" in your comment .. the whole point is we >> want to keep what we have which is close to 100 people able to change >> statuses. I also have no idea what 'devs' you are talking about but I'm >> pretty sure Mark and JM want more help not less. What we need is a solution >> that maps well to the current processes that we have and are satisfied with >> and that as much as possible fixes the ones that we aren't. The way the >> JBS works is pretty unusual and that has made finding a product that maps >> well to it difficult. We don't want JBS to have to fit a tracker we want a >> tracker to have to fit JBS.
>> Currently we have about 609 issues with some kind of open status on the >> main tracker on joomlacode. >> https://github.com/popular/starred on that list I think Rails is the >> only one that comes close to that although it's confusing where their >> numbers are coming from.
>> Elin
>> On Friday, October 5, 2012 11:40:12 AM UTC-4, Kevin wrote:
>>> @Elin
>>> What is the url on Git for the comments on J3 and where is the url for >>> the comments on 2,5 ? All I can see is lots of individual discussions on >>> each individual pull request page. At least with Joomla code there is only >>> 1 url for each version of Joomla.
>>> " *is not currently adequate for managing close to 100 people with >>> status changing privileges*" >>> That can get complicated but if you want to limit it to just the Dev's >>> being able to do that ... then fine no problem with that. More work for >>> the Devs and less work for the Testers/ticket handlers.
>>> "*Even in the comparatively slow low volume platform tracker you see >>> that once it's above 100 open issues it's really kind of a pain and that >>> when people make a report and disappear the reports tend to just fade away >>> rather then have someone else step in and fix*" >>> Yes, but is that not true about any list with 100+ entries, no matter >>> where the list is ?
>>> On Friday, 5 October 2012 12:51:24 UTC+1, Elin wrote:
>>>> @Kevin I'm not sure what you mean, any one can comment on any issue in >>>> github, you just need to login and you can put both attached comments and >>>> inline comments. I do think that there will be an issue when people need to >>>> make pull requests against both the 2.5 branch and against master or just >>>> one but I the goal of course is to not have much against the 2.5 branch.
>>>> @Peter >>>> This is what we are working on. The very simple proprietary github >>>> tracker (one of the few non open source parts of github so we can't >>>> actually send improvement suggestions) is not currently adequate for >>>> managing close to 100 people with status changing privileges and does not >>>> have adequate complex search and sort capabilities (although the tagging >>>> system has real potential) and does not have a seamless way to manage the >>>> links between codeless issue reports (which are very common in the CMS) and >>>> proposed fixes [e.g. you have to manually get the issue number and type it >>>> in your comment--even for the initial reporter later submitting code they >>>> have to be very specific in how they do the link to make them connect] or >>>> for duplicate report tracking (a joomlacode feature I am probably the only >>>> person using). Also in jbs it is extremely important to track manual >>>> testing and to also to have excellent reporting capabilities. Even in >>>> the comparatively slow low volume platform tracker you see that once it's >>>> above 100 open issues it's really kind of a pain and that when people make >>>> a report and disappear the reports tend to just fade away rather then have >>>> someone else step in and fix. However we hope that is what Joomla can help >>>> us with. (Also github itself has been adding useful new APIs.)
>>>> We also need to solve the issue of attachments that are not pull >>>> requests whether sample extensions illustrating problems or screenshots.
>>>> Some of the issues relate to people needing to get better at using git >>>> hub feature such as sending pull requests to each other and pulling >>>> branches from people not just from master.
>>>> JBS has always been about social coding and I'm really anxious to get >>>> to the point where we are fully taking advantage of what github offers for >>>> that.
>>>> Elin
>>>> On Friday, October 5, 2012 7:09:11 AM UTC-4, Kevin wrote:
>>>>> "Or drop Joomlacode and svn completely and just use the built in >>>>> functionality of github :)" >>>>> But could everyone in bugsquad comment inGit Without having to install >>>>> and configure software. Also in Git is there one place where the bugs for >>>>> each version of Joomla can be posted. From what I've seen of Git there is >>>>> no url that an ordinary user can go to.
>>>>> On Friday, 5 October 2012 10:34:58 UTC+1, Peter van Westen wrote:
>>>>>> Or drop Joomlacode and svn completely and just use the built in >>>>>> functionality of github :)
Thank you Elin for your explanations and pov's. Much appreciated.
It would be good for everyone to not have a zillion different places where core code is being discussed/submitted. We now have the tracker, github (both code and bug reports), forum, google groups. This is a frustrating situation for many. And discourages people to get involved and get things done.
I think that the current tracker vs github situation is most frustrating to coders. And we really want to keep (I mean make) them happy :)
On Saturday, 6 October 2012 02:58:22 UTC+2, Elin wrote:
> For both github and joomlacode forum users have to register a new account > and learn how to report.
> I don't see what commenting and installing software have to do with each > other. If you want to make a comment use the web ui to make a comment. > That's exactly the same in both.
> Unlike gForge, Git hub does not have a built in form building UI for > administrators so it loses in the ability to ask or even require reporters > to provide crucial information like cms version, php version. database and > browser. Also github does not have duplicate tracking or a way to upload > files. It also does not have query building/saving and downloading to csv > or xls. So advantage gForge for those items.
> In github you can also make a patch+ issue a pull request right on the > web. I've gotten dozens of people to make contributions by saying just go > to the file, click edit, make the change and click save. So for beginners > with simple change proposals github wins hands down. You don't even have to > learn to work with a diff file. There is no equivalent of that in > gforge+svn. Adantage github.
> So for people reporting issues and making simple suggested changes in > code, things are either equivalent or slightly to the advantage of github.
> For people who want to test I really think it depends on what process you > use. For me, pulling a patch from github or from joomlacode is the same. I > apply patches in the same way and test in the same way. I keep one messy > branch where I apply maybe a dozen jbs patches and then periodically, when > they are going to interfere with each other, I reset the whole thing. > That's exactly what I did in svn except it was one checkout. For both svn > and git I installed software to help me manage things.
> For people who want to write code, I think at this point the consensus > seems to be that github is easier and more encouraging of collaboration.
> The real issue I care personally about in a self-interested way is which > system makes it easiest to manage a tracker with typically 400-600 open > issues and, in fact, a number of separate things i.e. a 2.5 tracker, a > trunk tracker, a feature tracker, and a security tracker, and a number of > trackers with historical function, plus a large number of people working in > different places. Which lets me keep the most open issues in my working > memory and which makes it easiest to find an old issue when I think "I know > I have seen that issue before"? Also what system is JM going to complain > about least :P. For the latter I'd strongly like an open source solution > since the main problem with both options we have been discussing is that > the only work we can do to make it work the way we want is to use apis. > From what I have seen the github apis are much easier to work with.
> Elin
> On Friday, October 5, 2012 7:06:05 PM UTC-4, Kevin wrote:
>> "*While people sending code can easily indicate which branch the code is >>> for, people making issue reports don't have an easy way to mark that >>> (because even if jbs can apply tags new reporters won't have access to the >>> tagging"*
>> That is exactly what I meant when I said
>>> "*But could everyone in bugsquad comment inGit Without having to >>> install and configure software*"
>> Yes there are pitfalls with Joomlacode tracker but to "*Or drop >> Joomlacode and svn completely and just use the built in functionality of >> github :)*" ... might have more pitfalls. After all if a user in the >> forums reports a bug then ... with the current system in Joomlacode ... it >> is a simple mater to report the bug after testing. And I have even managed >> to test a few simple patches as well.
>> I enjoy helping out in bugsquad but feel that it could easy to fall >> behind with too many changes. And wonder how many other non-developers >> could get left behind as well? Not trying to be obstructive of improvement >> ... just putting a point of view that *"Or drop Joomlacode and svn >> completely and just use the built in functionality of github :)"* may >> not be a change for the best. And explaining my thought process for why >> not.
>> On Friday, 5 October 2012 23:43:42 UTC+1, Elin wrote:
>>> https://github.com/joomla/joomla-cms/issues >>> Just comment and say what version and if you are making a pull request >>> specify the correct target branch (master for J3, 2.5 for 2.5). But that >>> is a great example of why the github tracker is not really workable without >>> help. While people sending code can easily indicate which branch the code >>> is for, people making issue reports don't have an easy way to mark that >>> (because even if jbs can apply tags new reporters won't have access to the >>> tagging plus they won't realize that it's needed just like on any other web >>> UI people will not read instructions that you can be sure of).
>>> I don't understand the "you:" in your comment .. the whole point is we >>> want to keep what we have which is close to 100 people able to change >>> statuses. I also have no idea what 'devs' you are talking about but I'm >>> pretty sure Mark and JM want more help not less. What we need is a solution >>> that maps well to the current processes that we have and are satisfied with >>> and that as much as possible fixes the ones that we aren't. The way the >>> JBS works is pretty unusual and that has made finding a product that maps >>> well to it difficult. We don't want JBS to have to fit a tracker we want a >>> tracker to have to fit JBS.
>>> Currently we have about 609 issues with some kind of open status on the >>> main tracker on joomlacode. >>> https://github.com/popular/starred on that list I think Rails is the >>> only one that comes close to that although it's confusing where their >>> numbers are coming from.
>>> Elin
>>> On Friday, October 5, 2012 11:40:12 AM UTC-4, Kevin wrote:
>>>> @Elin
>>>> What is the url on Git for the comments on J3 and where is the url for >>>> the comments on 2,5 ? All I can see is lots of individual discussions on >>>> each individual pull request page. At least with Joomla code there is only >>>> 1 url for each version of Joomla.
>>>> " *is not currently adequate for managing close to 100 people with >>>> status changing privileges*" >>>> That can get complicated but if you want to limit it to just the Dev's >>>> being able to do that ... then fine no problem with that. More work for >>>> the Devs and less work for the Testers/ticket handlers.
>>>> "*Even in the comparatively slow low volume platform tracker you see >>>> that once it's above 100 open issues it's really kind of a pain and that >>>> when people make a report and disappear the reports tend to just fade away >>>> rather then have someone else step in and fix*" >>>> Yes, but is that not true about any list with 100+ entries, no matter >>>> where the list is ?
>>>> On Friday, 5 October 2012 12:51:24 UTC+1, Elin wrote:
>>>>> @Kevin I'm not sure what you mean, any one can comment on any issue in >>>>> github, you just need to login and you can put both attached comments and >>>>> inline comments. I do think that there will be an issue when people need to >>>>> make pull requests against both the 2.5 branch and against master or just >>>>> one but I the goal of course is to not have much against the 2.5 branch.
>>>>> @Peter >>>>> This is what we are working on. The very simple proprietary github >>>>> tracker (one of the few non open source parts of github so we can't >>>>> actually send improvement suggestions) is not currently adequate for >>>>> managing close to 100 people with status changing privileges and does not >>>>> have adequate complex search and sort capabilities (although the tagging >>>>> system has real potential) and does not have a seamless way to manage the >>>>> links between codeless issue reports (which are very common in the CMS) and >>>>> proposed fixes [e.g. you have to manually get the issue number and type it >>>>> in your comment--even for the initial reporter later submitting code they >>>>> have to be very specific in how they do the link to make them connect] or >>>>> for duplicate report tracking (a joomlacode feature I am probably the only >>>>> person using). Also in jbs it is extremely important to track manual >>>>> testing and to also to have excellent reporting capabilities. Even in >>>>> the comparatively slow low volume platform tracker you see that once it's >>>>> above 100 open issues it's really kind of a pain and that when people make >>>>> a report and disappear the reports tend to just fade away rather then have >>>>> someone else step in and fix. However we hope that is what Joomla can help >>>>> us with. (Also github itself has been adding useful new APIs.)
>>>>> We also need to solve the issue of attachments that are not pull >>>>> requests whether sample extensions illustrating problems or screenshots.
>>>>> Some of the issues relate to people needing to get better at using git >>>>> hub feature such as sending pull requests to each other and pulling >>>>> branches from people not just from master.
>>>>> JBS has always been about social coding and I'm really anxious to get
"I don't see what commenting and installing software have to do with each other" What is the url for Git that has a list of all the Joomla pull requests so that a non dev can decide which bug they can test/comment on ? Where is the url for the list on Git where non devs can report bugs ?
"In github you can also make a patch+ issue a pull request right on the web" Now either I missed that or it has never been stated before. All the tutorials I have seen links to have required syncing the computer with Git(in some way or other.) Link to a tutorial on how to do pull requests on the web would be good thanks. Because every thing I've looked at requires all sorts of configuration before a patch can be applied.
For the umpteenth time testing a Git patch is more complex(initially) than testing an SVN patch. With svn install one piece of software, point it at the svn trunk put in user pass ... done. Download the patch right click ... done. But with Git download the software configure to sync with Git and a load of other things ... because the software that is used to test a Git patch will not work unless you have the whole caboose.
btw Tortoisesvn will download the 2.5 git branch to the computer but not the trunk.
On Saturday, 6 October 2012 01:58:22 UTC+1, Elin wrote:
> For both github and joomlacode forum users have to register a new account > and learn how to report.
> I don't see what commenting and installing software have to do with each > other. If you want to make a comment use the web ui to make a comment. > That's exactly the same in both.
> Unlike gForge, Git hub does not have a built in form building UI for > administrators so it loses in the ability to ask or even require reporters > to provide crucial information like cms version, php version. database and > browser. Also github does not have duplicate tracking or a way to upload > files. It also does not have query building/saving and downloading to csv > or xls. So advantage gForge for those items.
> In github you can also make a patch+ issue a pull request right on the > web. I've gotten dozens of people to make contributions by saying just go > to the file, click edit, make the change and click save. So for beginners > with simple change proposals github wins hands down. You don't even have to > learn to work with a diff file. There is no equivalent of that in > gforge+svn. Adantage github.
> So for people reporting issues and making simple suggested changes in > code, things are either equivalent or slightly to the advantage of github.
> For people who want to test I really think it depends on what process you > use. For me, pulling a patch from github or from joomlacode is the same. I > apply patches in the same way and test in the same way. I keep one messy > branch where I apply maybe a dozen jbs patches and then periodically, when > they are going to interfere with each other, I reset the whole thing. > That's exactly what I did in svn except it was one checkout. For both svn > and git I installed software to help me manage things.
> For people who want to write code, I think at this point the consensus > seems to be that github is easier and more encouraging of collaboration.
> The real issue I care personally about in a self-interested way is which > system makes it easiest to manage a tracker with typically 400-600 open > issues and, in fact, a number of separate things i.e. a 2.5 tracker, a > trunk tracker, a feature tracker, and a security tracker, and a number of > trackers with historical function, plus a large number of people working in > different places. Which lets me keep the most open issues in my working > memory and which makes it easiest to find an old issue when I think "I know > I have seen that issue before"? Also what system is JM going to complain > about least :P. For the latter I'd strongly like an open source solution > since the main problem with both options we have been discussing is that > the only work we can do to make it work the way we want is to use apis. > From what I have seen the github apis are much easier to work with.
> Elin
> On Friday, October 5, 2012 7:06:05 PM UTC-4, Kevin wrote:
>> "*While people sending code can easily indicate which branch the code is >>> for, people making issue reports don't have an easy way to mark that >>> (because even if jbs can apply tags new reporters won't have access to the >>> tagging"*
>> That is exactly what I meant when I said
>>> "*But could everyone in bugsquad comment inGit Without having to >>> install and configure software*"
>> Yes there are pitfalls with Joomlacode tracker but to "*Or drop >> Joomlacode and svn completely and just use the built in functionality of >> github :)*" ... might have more pitfalls. After all if a user in the >> forums reports a bug then ... with the current system in Joomlacode ... it >> is a simple mater to report the bug after testing. And I have even managed >> to test a few simple patches as well.
>> I enjoy helping out in bugsquad but feel that it could easy to fall >> behind with too many changes. And wonder how many other non-developers >> could get left behind as well? Not trying to be obstructive of improvement >> ... just putting a point of view that *"Or drop Joomlacode and svn >> completely and just use the built in functionality of github :)"* may >> not be a change for the best. And explaining my thought process for why >> not.
>> On Friday, 5 October 2012 23:43:42 UTC+1, Elin wrote:
>>> https://github.com/joomla/joomla-cms/issues >>> Just comment and say what version and if you are making a pull request >>> specify the correct target branch (master for J3, 2.5 for 2.5). But that >>> is a great example of why the github tracker is not really workable without >>> help. While people sending code can easily indicate which branch the code >>> is for, people making issue reports don't have an easy way to mark that >>> (because even if jbs can apply tags new reporters won't have access to the >>> tagging plus they won't realize that it's needed just like on any other web >>> UI people will not read instructions that you can be sure of).
>>> I don't understand the "you:" in your comment .. the whole point is we >>> want to keep what we have which is close to 100 people able to change >>> statuses. I also have no idea what 'devs' you are talking about but I'm >>> pretty sure Mark and JM want more help not less. What we need is a solution >>> that maps well to the current processes that we have and are satisfied with >>> and that as much as possible fixes the ones that we aren't. The way the >>> JBS works is pretty unusual and that has made finding a product that maps >>> well to it difficult. We don't want JBS to have to fit a tracker we want a >>> tracker to have to fit JBS.
>>> Currently we have about 609 issues with some kind of open status on the >>> main tracker on joomlacode. >>> https://github.com/popular/starred on that list I think Rails is the >>> only one that comes close to that although it's confusing where their >>> numbers are coming from.
>>> Elin
>>> On Friday, October 5, 2012 11:40:12 AM UTC-4, Kevin wrote:
>>>> @Elin
>>>> What is the url on Git for the comments on J3 and where is the url for >>>> the comments on 2,5 ? All I can see is lots of individual discussions on >>>> each individual pull request page. At least with Joomla code there is only >>>> 1 url for each version of Joomla.
>>>> " *is not currently adequate for managing close to 100 people with >>>> status changing privileges*" >>>> That can get complicated but if you want to limit it to just the Dev's >>>> being able to do that ... then fine no problem with that. More work for >>>> the Devs and less work for the Testers/ticket handlers.
>>>> "*Even in the comparatively slow low volume platform tracker you see >>>> that once it's above 100 open issues it's really kind of a pain and that >>>> when people make a report and disappear the reports tend to just fade away >>>> rather then have someone else step in and fix*" >>>> Yes, but is that not true about any list with 100+ entries, no matter >>>> where the list is ?
>>>> On Friday, 5 October 2012 12:51:24 UTC+1, Elin wrote:
>>>>> @Kevin I'm not sure what you mean, any one can comment on any issue in >>>>> github, you just need to login and you can put both attached comments and >>>>> inline comments. I do think that there will be an issue when people need to >>>>> make pull requests against both the 2.5 branch and against master or just >>>>> one but I the goal of course is to not have much against the 2.5 branch.
>>>>> @Peter >>>>> This is what we are working on. The very simple proprietary github >>>>> tracker (one of the few non open source parts of github so we can't >>>>> actually send improvement suggestions) is not currently adequate for >>>>> managing close to 100 people with status changing privileges and does not >>>>> have adequate complex search and sort capabilities (although the tagging >>>>> system has real potential) and does not have a seamless way to manage the >>>>> links between codeless issue reports (which are very common in the CMS) and >>>>> proposed fixes [e.g. you have to manually get the issue number and type it >>>>> in your comment--even for the initial reporter later submitting code they >>>>> have to be very specific in how they do the link to make them connect] or >>>>> for duplicate report tracking (a joomlacode feature I am probably the only >>>>> person using). Also in jbs it is extremely important to track manual >>>>> testing and to also to have excellent reporting capabilities. Even in >>>>> the comparatively slow low volume platform tracker you see that once it's >>>>> above 100 open issues
> "It would be good for everyone to not have a zillion different places > where core code is being discussed/submitted. > We now have the tracker, github (both code and bug reports), forum, google > groups. > This is a frustrating situation for many. And discourages people to get > involved and get things done."
Yes, devs and non devs alike will get discouraged. All the more reason not to move the reporting to Git. Git is great for devs ... and yes I can see why. But non devs need something simple quick and easy ... Joomlacode tracker provides that.
> "I think that the current tracker vs github situation is most frustrating > to coders. And we really want to keep (I mean make) them happy :)"
Yes and just as frustrating to the non devs as well. And the non devs need to be kept happy as well, otherwise the devs will be doing all the work testing, scouring the forums for bug reports, reporting the bugs, coding the fixes and testing the fixes.
If non devs are to continue helping out by scouring the forums for bug reports and reporting them in the tracker ... then there must be a flexible attitude from devs. It should be clear from my input that I am no expert yet I am no novice. My knowledge is somewhere inbetween, and can see both ends of the spectrum. We have very talented knowledgeable devs who are dedicated and put a lot of effort in. Git is a good platform for the devs but non devs need something simple so that reorting the bugs is easy. Joomlacode works ... not perfect ... but it works. * If it aint broke don't fix it !*
On Saturday, 6 October 2012 09:17:52 UTC+1, Peter van Westen wrote:
> Thank you Elin for your explanations and pov's. Much appreciated.
> It would be good for everyone to not have a zillion different places where > core code is being discussed/submitted. > We now have the tracker, github (both code and bug reports), forum, google > groups. > This is a frustrating situation for many. And discourages people to get > involved and get things done.
> I think that the current tracker vs github situation is most frustrating > to coders. And we really want to keep (I mean make) them happy :)
> On Saturday, 6 October 2012 02:58:22 UTC+2, Elin wrote:
>> For both github and joomlacode forum users have to register a new account >> and learn how to report.
>> I don't see what commenting and installing software have to do with each >> other. If you want to make a comment use the web ui to make a comment. >> That's exactly the same in both.
>> Unlike gForge, Git hub does not have a built in form building UI for >> administrators so it loses in the ability to ask or even require reporters >> to provide crucial information like cms version, php version. database and >> browser. Also github does not have duplicate tracking or a way to upload >> files. It also does not have query building/saving and downloading to csv >> or xls. So advantage gForge for those items.
>> In github you can also make a patch+ issue a pull request right on the >> web. I've gotten dozens of people to make contributions by saying just go >> to the file, click edit, make the change and click save. So for beginners >> with simple change proposals github wins hands down. You don't even have to >> learn to work with a diff file. There is no equivalent of that in >> gforge+svn. Adantage github.
>> So for people reporting issues and making simple suggested changes in >> code, things are either equivalent or slightly to the advantage of github.
>> For people who want to test I really think it depends on what process >> you use. For me, pulling a patch from github or from joomlacode is the >> same. I apply patches in the same way and test in the same way. I keep one >> messy branch where I apply maybe a dozen jbs patches and then >> periodically, when they are going to interfere with each other, I reset the >> whole thing. That's exactly what I did in svn except it was one checkout. >> For both svn and git I installed software to help me manage things.
>> For people who want to write code, I think at this point the consensus >> seems to be that github is easier and more encouraging of collaboration.
>> The real issue I care personally about in a self-interested way is which >> system makes it easiest to manage a tracker with typically 400-600 open >> issues and, in fact, a number of separate things i.e. a 2.5 tracker, a >> trunk tracker, a feature tracker, and a security tracker, and a number of >> trackers with historical function, plus a large number of people working in >> different places. Which lets me keep the most open issues in my working >> memory and which makes it easiest to find an old issue when I think "I know >> I have seen that issue before"? Also what system is JM going to complain >> about least :P. For the latter I'd strongly like an open source solution >> since the main problem with both options we have been discussing is that >> the only work we can do to make it work the way we want is to use apis. >> From what I have seen the github apis are much easier to work with.
>> Elin
>> On Friday, October 5, 2012 7:06:05 PM UTC-4, Kevin wrote:
>>> "*While people sending code can easily indicate which branch the code >>>> is for, people making issue reports don't have an easy way to mark that >>>> (because even if jbs can apply tags new reporters won't have access to the >>>> tagging"*
>>> That is exactly what I meant when I said
>>>> "*But could everyone in bugsquad comment inGit Without having to >>>> install and configure software*"
>>> Yes there are pitfalls with Joomlacode tracker but to "*Or drop >>> Joomlacode and svn completely and just use the built in functionality of >>> github :)*" ... might have more pitfalls. After all if a user in the >>> forums reports a bug then ... with the current system in Joomlacode ... it >>> is a simple mater to report the bug after testing. And I have even managed >>> to test a few simple patches as well.
>>> I enjoy helping out in bugsquad but feel that it could easy to fall >>> behind with too many changes. And wonder how many other non-developers >>> could get left behind as well? Not trying to be obstructive of improvement >>> ... just putting a point of view that *"Or drop Joomlacode and svn >>> completely and just use the built in functionality of github :)"* may >>> not be a change for the best. And explaining my thought process for why >>> not.
>>> On Friday, 5 October 2012 23:43:42 UTC+1, Elin wrote:
>>>> https://github.com/joomla/joomla-cms/issues >>>> Just comment and say what version and if you are making a pull request >>>> specify the correct target branch (master for J3, 2.5 for 2.5). But that >>>> is a great example of why the github tracker is not really workable without >>>> help. While people sending code can easily indicate which branch the code >>>> is for, people making issue reports don't have an easy way to mark that >>>> (because even if jbs can apply tags new reporters won't have access to the >>>> tagging plus they won't realize that it's needed just like on any other web >>>> UI people will not read instructions that you can be sure of).
>>>> I don't understand the "you:" in your comment .. the whole point is >>>> we want to keep what we have which is close to 100 people able to change >>>> statuses. I also have no idea what 'devs' you are talking about but I'm >>>> pretty sure Mark and JM want more help not less. What we need is a solution >>>> that maps well to the current processes that we have and are satisfied with >>>> and that as much as possible fixes the ones that we aren't. The way the >>>> JBS works is pretty unusual and that has made finding a product that maps >>>> well to it difficult. We don't want JBS to have to fit a tracker we want a >>>> tracker to have to fit JBS.
>>>> Currently we have about 609 issues with some kind of open status on the >>>> main tracker on joomlacode. >>>> https://github.com/popular/starred on that list I think Rails is the >>>> only one that comes close to that although it's confusing where their >>>> numbers are coming from.
>>>> Elin
>>>> On Friday, October 5, 2012 11:40:12 AM UTC-4, Kevin wrote:
>>>>> @Elin
>>>>> What is the url on Git for the comments on J3 and where is the url for >>>>> the comments on 2,5 ? All I can see is lots of individual discussions on >>>>> each individual pull request page. At least with Joomla code there is only >>>>> 1 url for each version of Joomla.
>>>>> " *is not currently adequate for managing close to 100 people with >>>>> status changing privileges*" >>>>> That can get complicated but if you want to limit it to just the Dev's >>>>> being able to do that ... then fine no problem with that. More work for >>>>> the Devs and less work for the Testers/ticket handlers.
>>>>> "*Even in the comparatively slow low volume platform tracker you see >>>>> that once it's above 100 open issues it's really kind of a pain and that >>>>> when people make a report and disappear the reports tend to just fade away >>>>> rather then have someone else step in and fix*" >>>>> Yes, but is that not true about any list with 100+ entries, no matter >>>>> where the list is ?
>>>>> On Friday, 5 October 2012 12:51:24 UTC+1, Elin wrote:
>>>>>> @Kevin I'm not sure what you mean, any one can comment on any issue >>>>>> in github, you just need to login and you can put both attached comments >>>>>> and inline comments. I do think that there will be an issue when people >>>>>> need to make pull requests against both the 2.5 branch and against master >>>>>> or just one but I the goal of course is to not have much against the 2.5 >>>>>> branch.
>>>>>> @Peter >>>>>> This is what we are working on.
> Thank you Elin for your explanations and pov's. Much appreciated.
> It would be good for everyone to not have a zillion different places where
> core code is being discussed/submitted.
> We now have the tracker, github (both code and bug reports), forum, google
> groups.
> This is a frustrating situation for many. And discourages people to get
> involved and get things done.
> I think that the current tracker vs github situation is most frustrating
> to
> coders. And we really want to keep (I mean make) them happy :)
Finally someone that has the balls to take this head on.
Kevin: "But non devs need something simple quick and easy ... Joomlacode tracker provides that." Man, I have no idea how you can say that. But discussing it doesn't seem to solve anything. So WTF for Michael Babker and onwards and upwards with his new tracker :)
This thread is closed as far as I am concerned. The initial question was about adding a feature to the joomlacode tracker. Answer: Nope, can't be done, code is closed.
> > Thank you Elin for your explanations and pov's. Much appreciated.
> > It would be good for everyone to not have a zillion different places > where > > core code is being discussed/submitted. > > We now have the tracker, github (both code and bug reports), forum, > google > > groups. > > This is a frustrating situation for many. And discourages people to get > > involved and get things done.
> > I think that the current tracker vs github situation is most frustrating > > to > > coders. And we really want to keep (I mean make) them happy :)
> Finally someone that has the balls to take this head on.
> Kevin: "But non devs need something simple quick and easy ... Joomlacode > tracker provides that." > Man, I have no idea how you can say that. But discussing it doesn't seem > to solve anything. So WTF for Michael Babker and onwards and upwards with > his new tracker :)
> This thread is closed as far as I am concerned. The initial question was > about adding a feature to the joomlacode tracker. > Answer: Nope, can't be done, code is closed.
> On Saturday, 6 October 2012 17:56:48 UTC+2, Nick Savov wrote:
>> > Thank you Elin for your explanations and pov's. Much appreciated.
>> > It would be good for everyone to not have a zillion different places >> where >> > core code is being discussed/submitted. >> > We now have the tracker, github (both code and bug reports), forum, >> google >> > groups. >> > This is a frustrating situation for many. And discourages people to get >> > involved and get things done.
>> > I think that the current tracker vs github situation is most >> frustrating >> > to >> > coders. And we really want to keep (I mean make) them happy :)
Yup agree on all counts, Michael is solving things. Still I'm posting some comments below to consider (he already know these).
Kevin,
I have explained how to use the web ui to make a pull request in at least 20 issues in the cms tracker and online many times. Not only that but it is prominently explained in git hub plus ... that EDIT button is right there on every file. https://github.com/blog/905-edit-like-an-ace
No special software is required to apply that diff, it's a diff just like any other p1 style diff.
This is what i do at the command line
patch -p1 < 477.diff
That is I do not even use git or eclipse or anything else to apply patches.
If you are just going to say no no no there is not much anyone can do to make things better. You really have to be willing to try new things or else you would still be on Joomla 1.0, and that would not be good. I'm sympathetic to resistance to change, change in the tracker will mean a lot more to me and what I do for Joomla every day than it will for almost anyone else except JM and Mark. But I'm trying to be highly open to different options and as most people I'm sure remember I did a form last year for people to submit information about their experiences with any trackers. If you want to argue that GForge has advantages that is great but you need to actually do that, not just say "I have for 6 months or more refused to even glance at the interface for the alternatives" which is what your questions indicate is the case. -------------------
For people who day in and day out do the work of the cms if a new tracker makes it harder to get work done and causes a big loss in functionality that we use to do our work that's a problem. If you think that there are backlogs now, you need to assume that using straight github they will be worse because of the loss of functionality. So while it might be easier for sending code, it will likely be harder for getting code in. Hence why we need a Joomla or other frontend for managing it and make it actually usable. That is why we have to move carefully, not because people are somehow wanting to say "no."
For example, even with a paid account Github its native ACL is much more primitive than the ACL in gForge or Joomla 1.5. I personally do not have privileges to manage issues on Github, it is 100% up to Mark, JM, Andy and Rouven. So right there you need to count on cutting out my chunk out of the handling of tracker issues. Not only me, you need to cut out the whole JBS from participation in tracker management, and they carry most of that load--much much more than me cumulatively-- distributed over many hard working people. All that we have built in terms of low barrier to entry participation in bug triaging and tracker management goes out the window. I do not believe that would be a positive step. This project has gained way more than it has lost by broadening participation in that. So does making it marginally easier for intermittent code contributors who don't participate in the work of testing and giving feed back to code (the actual work of the tracker) worth giving all that up?
As another example, I just want to mention one issue that people may not be aware of but that I am very concerned about. In GForge if someone wrongly reports a security issue to the public tracker an admin can immediately make it disappear by moving it to the security tracker. Github has no real concept of making issues disappear and no way to move an issue from one repo to another repo. So what are we going to do when that happens and it takes a few days (or more) to determine the correct way to fix something? We will potentially have lots of sites hacked.
Finally in one of the many threads I saw someone say "it does milestones, it does assignments' ... well we don't use mile stones and we don't assign issues to people so .. . how we move forward has to reflect how this highly successful JBS team-- which has had the main responsibility for releasing this crazily popular software for 5 years-- operates.
Just some additional food for thought. It is not that people are not thinking hard about options and working hard on implementing them, it is that this is very complex much more complex than people who haven't spent time on it probably understand.
On Saturday, October 6, 2012 8:21:16 AM UTC-4, Kevin wrote:
> "I don't see what commenting and installing software have to do with each > other" > What is the url for Git that has a list of all the Joomla pull requests so > that a non dev can decide which bug they can test/comment on ? > Where is the url for the list on Git where non devs can report bugs ?
> "In github you can also make a patch+ issue a pull request right on the > web" > Now either I missed that or it has never been stated before. All the > tutorials I have seen links to have required syncing the computer with > Git(in some way or other.) > Link to a tutorial on how to do pull requests on the web would be good > thanks. Because every thing I've looked at requires all sorts of > configuration before a patch can be applied.
> For the umpteenth time testing a Git patch is more complex(initially) than > testing an SVN patch. With svn install one piece of software, point it at > the svn trunk put in user pass ... done. Download the patch right click > ... done. But with Git download the software configure to sync with Git > and a load of other things ... because the software that is used to test a > Git patch will not work unless you have the whole caboose.
> btw Tortoisesvn will download the 2.5 git branch to the computer but not > the trunk.
> On Saturday, 6 October 2012 01:58:22 UTC+1, Elin wrote:
>> For both github and joomlacode forum users have to register a new account >> and learn how to report.
>> I don't see what commenting and installing software have to do with each >> other. If you want to make a comment use the web ui to make a comment. >> That's exactly the same in both.
>> Unlike gForge, Git hub does not have a built in form building UI for >> administrators so it loses in the ability to ask or even require reporters >> to provide crucial information like cms version, php version. database and >> browser. Also github does not have duplicate tracking or a way to upload >> files. It also does not have query building/saving and downloading to csv >> or xls. So advantage gForge for those items.
>> In github you can also make a patch+ issue a pull request right on the >> web. I've gotten dozens of people to make contributions by saying just go >> to the file, click edit, make the change and click save. So for beginners >> with simple change proposals github wins hands down. You don't even have to >> learn to work with a diff file. There is no equivalent of that in >> gforge+svn. Adantage github.
>> So for people reporting issues and making simple suggested changes in >> code, things are either equivalent or slightly to the advantage of github.
>> For people who want to test I really think it depends on what process >> you use. For me, pulling a patch from github or from joomlacode is the >> same. I apply patches in the same way and test in the same way. I keep one >> messy branch where I apply maybe a dozen jbs patches and then >> periodically, when they are going to interfere with each other, I reset the >> whole thing. That's exactly what I did in svn except it was one checkout. >> For both svn and git I installed software to help me manage things.
>> For people who want to write code, I think at this point the consensus >> seems to be that github is easier and more encouraging of collaboration.
>> The real issue I care personally about in a self-interested way is which >> system makes it easiest to manage a tracker with typically 400-600 open >> issues and, in fact, a number of separate things i.e. a 2.5 tracker, a >> trunk tracker, a feature tracker, and a security tracker, and a number of >> trackers with historical function, plus a large number of people working in >> different places. Which lets me keep the most open issues in my working >> memory and which makes it easiest to find an old issue when I think "I know >> I have seen that issue before"? Also what system is JM going to complain >> about least :P. For the latter I'd strongly like an open source solution >> since the main problem with both options we have been discussing is that >> the only work we can do to make it work the way we want is to use apis. >> From what I have seen the github apis are much easier to work with.
>> Elin
>> On Friday, October 5, 2012 7:06:05 PM UTC-4, Kevin wrote:
>>> "*While people sending code can easily indicate which branch the code >>>> is for, people making issue reports don't have an easy way to mark that >>>> (because even if jbs can apply tags new reporters won't have access to the >>>> tagging"*
>>> That is exactly what I meant when I said
>>>> "*But could everyone in bugsquad comment inGit Without having to >>>> install and configure software*"
>>> Yes there are pitfalls with Joomlacode tracker but to "*Or drop >>> Joomlacode and svn completely and just use the built in functionality of >>> github :)*" ... might have more pitfalls. After all if a user in the >>> forums reports a bug then ... with the current system in Joomlacode ... it >>> is a simple mater to report the bug after testing. And I have even managed >>> to test a few
> Kevin: "But non devs need something simple quick and easy ... Joomlacode > tracker provides that." > Man, I have no idea how you can say that
> I can say that because I am a non dev and one of the many people who helps
check problems in the forums. Also I can say that as one of the many people that checks to see if the reported bugs are user error or actual bugs. If you want non devs to carry on helping out with the basic work of sifting out the bugs from user error then don't move the tracker to Git. Joomlacode is not perfect but non devs just need a list that they can report bugs to ... a url that they can put in their Browser where they can just post their results.
"But discussing it doesn't seem to solve anything" Yes it does ... without discussion changes can be made that do not take into account everyone's view point.
> Finally someone that has the balls to take this head on.
> Kevin: "But non devs need something simple quick and easy ... Joomlacode > tracker provides that." > Man, I have no idea how you can say that. But discussing it doesn't seem > to solve anything. So WTF for Michael Babker and onwards and upwards with > his new tracker :)
> This thread is closed as far as I am concerned. The initial question was > about adding a feature to the joomlacode tracker. > Answer: Nope, can't be done, code is closed.
> On Saturday, 6 October 2012 17:56:48 UTC+2, Nick Savov wrote:
>> > Thank you Elin for your explanations and pov's. Much appreciated.
>> > It would be good for everyone to not have a zillion different places >> where >> > core code is being discussed/submitted. >> > We now have the tracker, github (both code and bug reports), forum, >> google >> > groups. >> > This is a frustrating situation for many. And discourages people to get >> > involved and get things done.
>> > I think that the current tracker vs github situation is most >> frustrating >> > to >> > coders. And we really want to keep (I mean make) them happy :)
"I have explained how to use the web ui to make a pull request in at least 20 issues in the cms tracker and online many times. Not only that but it is prominently explained in git hub plus ... that EDIT button is right there on every file." That is for devs who want to create/edit patches not for non devs who just want to test
"No special software is required to download this file https://github.com/joomla/joomla-cms/pull/477.diff you do save as, just like any other file on the web." But to apply that patch to a local copy requires the whole rigmarole of installing software that uaes the file to patch to a local copy. The software that applies that patch has to be setup to Git before the file can be patched. ... But with an SVN Patch the software that runs the patch is installed without any major configuration. That is a BIG difference for non devs and if you can't see that then I'm sorry because it means non devs are being left behind.
Yes ... when it is only one file changed then non devs can get the complete changed file(from Git) and use it to replace the one on their local copy. But when the patch contains a/ and b/ in the paths and several files have been changed ... then to replace those so that a regular program can run the patch just over complicates things for non devs.
Also I asked for a link to Git that listed all the pull requests where new bugs could also be reported.
I am getting very frustrated about this ... if the Tracker goes the same w\y as the testing of patches has then a lot of us non devs will be excluded. If you want just the devs to handle all the bug reporting then go ahead and change the system. Git is for the devs not the non devs
Putting the Tracker on a CMS would work if the system was the same. But using Git for Tracking bugs will exclude a lot of people.
On Sunday, 7 October 2012 07:43:55 UTC+1, Elin wrote:
> Peter,
> Yup agree on all counts, Michael is solving things. Still I'm posting some > comments below to consider (he already know these).
> Kevin,
> I have explained how to use the web ui to make a pull request in at least > 20 issues in the cms tracker and online many times. Not only that but it > is prominently explained in git hub plus ... that EDIT button is right > there on every file. > https://github.com/blog/905-edit-like-an-ace
> No special software is required to apply that diff, it's a diff just like > any other p1 style diff.
> This is what i do at the command line
> patch -p1 < 477.diff
> That is I do not even use git or eclipse or anything else to apply > patches.
> If you are just going to say no no no there is not much anyone can do to > make things better. You really have to be willing to try new things or else > you would still be on Joomla 1.0, and that would not be good. I'm > sympathetic to resistance to change, change in the tracker will mean a lot > more to me and what I do for Joomla every day than it will for almost > anyone else except JM and Mark. But I'm trying to be highly open to > different options and as most people I'm sure remember I did a form last > year for people to submit information about their experiences with any > trackers. If you want to argue that GForge has advantages that is great > but you need to actually do that, not just say "I have for 6 months or > more refused to even glance at the interface for the alternatives" which > is what your questions indicate is the case. > -------------------
> For people who day in and day out do the work of the cms if a new tracker > makes it harder to get work done and causes a big loss in functionality > that we use to do our work that's a problem. If you think that there are > backlogs now, you need to assume that using straight github they will be > worse because of the loss of functionality. So while it might be easier for > sending code, it will likely be harder for getting code in. Hence why we > need a Joomla or other frontend for managing it and make it actually > usable. That is why we have to move carefully, not because people are > somehow wanting to say "no."
> For example, even with a paid account Github its native ACL is much > more primitive than the ACL in gForge or Joomla 1.5. I personally do not > have privileges to manage issues on Github, it is 100% up to Mark, JM, Andy > and Rouven. So right there you need to count on cutting out my chunk out > of the handling of tracker issues. Not only me, you need to cut out the > whole JBS from participation in tracker management, and they carry most of > that load--much much more than me cumulatively-- distributed over many hard > working people. All that we have built in terms of low barrier to entry > participation in bug triaging and tracker management goes out the window. I > do not believe that would be a positive step. This project has gained way > more than it has lost by broadening participation in that. So does making > it marginally easier for intermittent code contributors who don't > participate in the work of testing and giving feed back to code (the > actual work of the tracker) worth giving all that up?
> As another example, I just want to mention one issue that people may not > be aware of but that I am very concerned about. In GForge if someone > wrongly reports a security issue to the public tracker an admin can > immediately make it disappear by moving it to the security tracker. > Github has no real concept of making issues disappear and no way to move > an issue from one repo to another repo. So what are we going to do when > that happens and it takes a few days (or more) to determine the correct > way to fix something? We will potentially have lots of sites hacked.
> Finally in one of the many threads I saw someone say "it does milestones, > it does assignments' ... well we don't use mile stones and we don't assign > issues to people so .. . how we move forward has to reflect how this > highly successful JBS team-- which has had the main responsibility for > releasing this crazily popular software for 5 years-- operates.
> Just some additional food for thought. It is not that people are not > thinking hard about options and working hard on implementing them, it is > that this is very complex much more complex than people who haven't spent > time on it probably understand.
> Elin
> On Saturday, October 6, 2012 8:21:16 AM UTC-4, Kevin wrote:
>> "I don't see what commenting and installing software have to do with each >> other" >> What is the url for Git that has a list of all the Joomla pull requests >> so that a non dev can decide which bug they can test/comment on ? >> Where is the url for the list on Git where non devs can report bugs ?
>> "In github you can also make a patch+ issue a pull request right on the >> web" >> Now either I missed that or it has never been stated before. All the >> tutorials I have seen links to have required syncing the computer with >> Git(in some way or other.) >> Link to a tutorial on how to do pull requests on the web would be good >> thanks. Because every thing I've looked at requires all sorts of >> configuration before a patch can be applied.
>> For the umpteenth time testing a Git patch is more complex(initially) >> than testing an SVN patch. With svn install one piece of software, point >> it at the svn trunk put in user pass ... done. Download the patch right >> click ... done. But with Git download the software configure to sync with >> Git and a load of other things ... because the software that is used to >> test a Git patch will not work unless you have the whole caboose.
>> btw Tortoisesvn will download the 2.5 git branch to the computer but not >> the trunk.
>> On Saturday, 6 October 2012 01:58:22 UTC+1, Elin wrote:
>>> For both github and joomlacode forum users have to register a new >>> account and learn how to report.
>>> I don't see what commenting and installing software have to do with each >>> other. If you want to make a comment use the web ui to make a comment. >>> That's exactly the same in both.
>>> Unlike gForge, Git hub does not have a built in form building UI for >>> administrators so it loses in the ability to ask or even require reporters >>> to provide crucial information like cms version, php version. database and >>> browser. Also github does not have duplicate tracking or a way to upload >>> files. It also does not have query building/saving and downloading to csv >>> or xls. So advantage gForge for those items.
>>> In github you can also make a patch+ issue a pull request right on the >>> web. I've gotten dozens of people to make contributions by saying just go >>> to the file, click edit, make the change and click save. So for beginners >>> with simple change proposals github wins hands down. You don't even have to >>> learn to work with a diff file. There is no equivalent of that in >>> gforge+svn. Adantage github.
>>> So for people reporting issues and making simple suggested changes in >>> code, things are either equivalent or slightly to the advantage of github.
>>> For people who want to test I really think it depends on what process >>> you use. For me, pulling a patch from github or from joomlacode is the >>> same. I apply patches in the same way and test in the same way. I keep one >>> messy branch where I apply maybe a dozen jbs patches and then >>> periodically, when they are going to interfere with each other, I reset
If you use TortoiseGit, it makes it very easy to test git patches and you
can be up and running within minutes.
Also, hopefully the new tracker will be easier for developers and
non-developers to use than the current tracker is, so hopefully we'll have
the best of both worlds.
@all,
As Peter mentioned, the original question was answered, so it's probably
best to close this one and start a new topic for any side discussions.
Kind regards,
Nick
> "I have explained how to use the web ui to make a pull request in at
least
> 20 issues in the cms tracker and online many times. Not only that but it
is prominently explained in git hub plus ... that EDIT button is right
there on every file."
> That is for devs who want to create/edit patches not for non devs who
just
> want to test
> "No special software is required to download this file
> https://github.com/joomla/joomla-cms/pull/477.diff > you do save as, just like any other file on the web."
> But to apply that patch to a local copy requires the whole rigmarole of
installing software that uaes the file to patch to a local copy. The
software that applies that patch has to be setup to Git before the file
can
> be patched. ... But with an SVN Patch the software that runs the patch
is
> installed without any major configuration. That is a BIG difference for
non devs and if you can't see that then I'm sorry because it means non
devs
> are being left behind.
> Yes ... when it is only one file changed then non devs can get the complete
> changed file(from Git) and use it to replace the one on their local
copy.
> But when the patch contains a/ and b/ in the paths and several files
have
> been changed ... then to replace those so that a regular program can run
the patch just over complicates things for non devs.
> Also I asked for a link to Git that listed all the pull requests where
new
> bugs could also be reported.
> I am getting very frustrated about this ... if the Tracker goes the same
w\y as the testing of patches has then a lot of us non devs will be
excluded. If you want just the devs to handle all the bug reporting
then
> go ahead and change the system. Git is for the devs not the non devs
Putting the Tracker on a CMS would work if the system was the same. But
using Git for Tracking bugs will exclude a lot of people.
> On Sunday, 7 October 2012 07:43:55 UTC+1, Elin wrote:
>> Peter,
>> Yup agree on all counts, Michael is solving things. Still I'm posting some
>> comments below to consider (he already know these).
>> Kevin,
>> I have explained how to use the web ui to make a pull request in at least
>> 20 issues in the cms tracker and online many times. Not only that but
it
>> is prominently explained in git hub plus ... that EDIT button is right
>> https://github.com/blog/905-edit-like-an-ace >> Where is a list of pull requests to comment on?
>> https://github.com/joomla/joomla-cms/pulls >> Where is the place to make reports without code?
>> https://github.com/joomla/joomla-cms/issues >> No special software is required to download this file
>> https://github.com/joomla/joomla-cms/pull/477.diff >> you do save as, just like any other file on the web.
>> No special software is required to apply that diff, it's a diff just like
>> any other p1 style diff.
>> This is what i do at the command line
>> patch -p1 < 477.diff
>> That is I do not even use git or eclipse or anything else to apply
patches.
>> If you are just going to say no no no there is not much anyone can do
to
>> make things better. You really have to be willing to try new things or
else
>> you would still be on Joomla 1.0, and that would not be good. I'm
sympathetic to resistance to change, change in the tracker will mean a
lot
>> more to me and what I do for Joomla every day than it will for almost
anyone else except JM and Mark. But I'm trying to be highly open to
different options and as most people I'm sure remember I did a form
last
>> year for people to submit information about their experiences with any
trackers. If you want to argue that GForge has advantages that is
great
>> but you need to actually do that, not just say "I have for 6 months or
more refused to even glance at the interface for the alternatives"
which
>> is what your questions indicate is the case.
>> -------------------
>> For people who day in and day out do the work of the cms if a new tracker
>> makes it harder to get work done and causes a big loss in
functionality
>> that we use to do our work that's a problem. If you think that there
are
>> backlogs now, you need to assume that using straight github they will
be
>> worse because of the loss of functionality. So while it might be easier
for
>> sending code, it will likely be harder for getting code in. Hence why
we
>> need a Joomla or other frontend for managing it and make it actually
usable. That is why we have to move carefully, not because people are
somehow wanting to say "no."
>> For example, even with a paid account Github its native ACL is much
more primitive than the ACL in gForge or Joomla 1.5. I personally do
not
>> have privileges to manage issues on Github, it is 100% up to Mark, JM,
Andy
>> and Rouven. So right there you need to count on cutting out my chunk out
>> of the handling of tracker issues. Not only me, you need to cut out the
whole JBS from participation in tracker management, and they carry most
of
>> that load--much much more than me cumulatively-- distributed over many
hard
>> working people. All that we have built in terms of low barrier to
entry
>> participation in bug triaging and tracker management goes out the
window. I
>> do not believe that would be a positive step. This project has gained way
>> more than it has lost by broadening participation in that. So does making
>> it marginally easier for intermittent code contributors who don't
participate in the work of testing and giving feed back to code (the
actual work of the tracker) worth giving all that up?
>> As another example, I just want to mention one issue that people may
not
>> be aware of but that I am very concerned about. In GForge if someone
wrongly reports a security issue to the public tracker an admin can
immediately make it disappear by moving it to the security tracker.
Github has no real concept of making issues disappear and no way to
move
>> an issue from one repo to another repo. So what are we going to do when
>> that happens and it takes a few days (or more) to determine the
correct
>> way to fix something? We will potentially have lots of sites hacked.
Finally in one of the many threads I saw someone say "it does
>> milestones,
>> it does assignments' ... well we don't use mile stones and we don't assign
>> issues to people so .. . how we move forward has to reflect how this
highly successful JBS team-- which has had the main responsibility for
releasing this crazily popular software for 5 years-- operates. Just
some additional food for thought. It is not that people are not
thinking hard about options and working hard on implementing them, it
is
>> that this is very complex much more complex than people who haven't spent
>> time on it probably understand.
>> Elin
>> On Saturday, October 6, 2012 8:21:16 AM UTC-4, Kevin wrote:
>>> "I don't see what commenting and installing software have to do with each
>>> other"
>>> What is the url for Git that has a list of all the Joomla pull
requests
>>> so that a non dev can decide which bug they can test/comment on ?
Where is the url for the list on Git where non devs can report bugs ?
"In github you can also make a patch+ issue a pull request right on
the
>>> web"
>>> Now either I missed that or it has never been stated before. All the
tutorials I have seen links to have required syncing the computer with
Git(in some way or other.)
>>> Link to a tutorial on how to do pull requests on the web would be good
thanks. Because every thing I've looked at requires all sorts of
configuration before a patch can be applied.
>>> For the umpteenth time testing a Git patch is more complex(initially)
than testing an SVN patch. With svn install one piece of software,
point
>>> it at the svn trunk put in user pass ... done. Download the patch right
>>> click ... done. But with Git download the software configure to sync
with
>>> Git and a load of other things ... because the software that is used
to
>>> test a Git patch will not work unless you have the whole caboose. btw
Tortoisesvn will download the 2.5 git branch to the computer but not
>>> the trunk.
>>> On Saturday, 6 October 2012 01:58:22 UTC+1, Elin wrote:
>>>> For both github and joomlacode forum users have to register a new
account and learn how to report.
>>>> I don't see what commenting and installing software have to do with each
>>>> other. If you want to make a comment use the web ui to make a
comment.
>>>> That's exactly the same in both.
>>>> Unlike gForge, Git hub does not have a built in form building UI for
administrators so it loses in the ability to ask or even require
reporters
>>>> to provide crucial information like cms version, php version.
database and
>>>> browser. Also github does not have duplicate tracking or a way to
upload
>>>> files. It also does not have query building/saving and downloading to
csv
>>>> or xls. So advantage gForge for those items.
>>>> In github you can also make a patch+ issue a pull request right on
the
>>>> web. I've gotten dozens of people to make contributions by saying
just
>>>> go
>>>> to the file, click edit, make the change and click save. So for
beginners
>>>> with simple change proposals github wins hands down. You don't even
> If you use TortoiseGit, it makes it very easy to test git patches and you > can be up and running within minutes.
> Also, hopefully the new tracker will be easier for developers and > non-developers to use than the current tracker is, so hopefully we'll have > the best of both worlds.
> @all, > As Peter mentioned, the original question was answered, so it's probably > best to close this one and start a new topic for any side discussions.
> Kind regards, > Nick
> > "I have explained how to use the web ui to make a pull request in at > least > > 20 issues in the cms tracker and online many times. Not only that but it > is prominently explained in git hub plus ... that EDIT button is right > there on every file." > > That is for devs who want to create/edit patches not for non devs who > just > > want to test > > "No special software is required to download this file > > https://github.com/joomla/joomla-cms/pull/477.diff > > you do save as, just like any other file on the web." > > But to apply that patch to a local copy requires the whole rigmarole of > installing software that uaes the file to patch to a local copy. The > software that applies that patch has to be setup to Git before the file > can > > be patched. ... But with an SVN Patch the software that runs the patch > is > > installed without any major configuration. That is a BIG difference for > non devs and if you can't see that then I'm sorry because it means non > devs > > are being left behind. > > Yes ... when it is only one file changed then non devs can get the > complete > > changed file(from Git) and use it to replace the one on their local > copy. > > But when the patch contains a/ and b/ in the paths and several files > have > > been changed ... then to replace those so that a regular program can run > the patch just over complicates things for non devs. > > Also I asked for a link to Git that listed all the pull requests where > new > > bugs could also be reported. > > I am getting very frustrated about this ... if the Tracker goes the same > w\y as the testing of patches has then a lot of us non devs will be > excluded. If you want just the devs to handle all the bug reporting > then > > go ahead and change the system. Git is for the devs not the non devs > Putting the Tracker on a CMS would work if the system was the same. But > using Git for Tracking bugs will exclude a lot of people. > > On Sunday, 7 October 2012 07:43:55 UTC+1, Elin wrote: > >> Peter, > >> Yup agree on all counts, Michael is solving things. Still I'm posting > some > >> comments below to consider (he already know these). > >> Kevin, > >> I have explained how to use the web ui to make a pull request in at > least > >> 20 issues in the cms tracker and online many times. Not only that but > it > >> is prominently explained in git hub plus ... that EDIT button is right > there on every file. > >> https://github.com/blog/905-edit-like-an-ace > >> Where is a list of pull requests to comment on? > >> https://github.com/joomla/joomla-cms/pulls > >> Where is the place to make reports without code? > >> https://github.com/joomla/joomla-cms/issues > >> No special software is required to download this file > >> https://github.com/joomla/joomla-cms/pull/477.diff > >> you do save as, just like any other file on the web. > >> No special software is required to apply that diff, it's a diff just > like > >> any other p1 style diff. > >> This is what i do at the command line > >> patch -p1 < 477.diff > >> That is I do not even use git or eclipse or anything else to apply > patches. > >> If you are just going to say no no no there is not much anyone can do > to > >> make things better. You really have to be willing to try new things or > else > >> you would still be on Joomla 1.0, and that would not be good. I'm > sympathetic to resistance to change, change in the tracker will mean a > lot > >> more to me and what I do for Joomla every day than it will for almost > anyone else except JM and Mark. But I'm trying to be highly open to > different options and as most people I'm sure remember I did a form > last > >> year for people to submit information about their experiences with any > trackers. If you want to argue that GForge has advantages that is > great > >> but you need to actually do that, not just say "I have for 6 months or > more refused to even glance at the interface for the alternatives" > which > >> is what your questions indicate is the case. > >> ------------------- > >> For people who day in and day out do the work of the cms if a new > tracker > >> makes it harder to get work done and causes a big loss in > functionality > >> that we use to do our work that's a problem. If you think that there > are > >> backlogs now, you need to assume that using straight github they will > be > >> worse because of the loss of functionality. So while it might be easier > for > >> sending code, it will likely be harder for getting code in. Hence why > we > >> need a Joomla or other frontend for managing it and make it actually > usable. That is why we have to move carefully, not because people are > somehow wanting to say "no." > >> For example, even with a paid account Github its native ACL is much > more primitive than the ACL in gForge or Joomla 1.5. I personally do > not > >> have privileges to manage issues on Github, it is 100% up to Mark, JM, > Andy > >> and Rouven. So right there you need to count on cutting out my chunk > out > >> of the handling of tracker issues. Not only me, you need to cut out the > whole JBS from participation in tracker management, and they carry most > of > >> that load--much much more than me cumulatively-- distributed over many > hard > >> working people. All that we have built in terms of low barrier to > entry > >> participation in bug triaging and tracker management goes out the > window. I > >> do not believe that would be a positive step. This project has gained > way > >> more than it has lost by broadening participation in that. So does > making > >> it marginally easier for intermittent code contributors who don't > participate in the work of testing and giving feed back to code (the > actual work of the tracker) worth giving all that up? > >> As another example, I just want to mention one issue that people may > not > >> be aware of but that I am very concerned about. In GForge if someone > wrongly reports a security issue to the public tracker an admin can > immediately make it disappear by moving it to the security tracker. > Github has no real concept of making issues disappear and no way to > move > >> an issue from one repo to another repo. So what are we going to do > when > >> that happens and it takes a few days (or more) to determine the > correct > >> way to fix something? We will potentially have lots of sites hacked. > Finally in one of the many threads I saw someone say "it does > >> milestones, > >> it does assignments' ... well we don't use mile stones and we don't > assign > >> issues to people so .. . how we move forward has to reflect how this > highly successful JBS team-- which has had the main responsibility for > releasing this crazily popular software for 5 years-- operates. Just > some additional food for thought. It is not that people are not > thinking hard about options and working hard on implementing them, it > is > >> that this is very complex much more complex than people who haven't > spent > >> time on it probably understand. > >> Elin > >> On Saturday, October 6, 2012 8:21:16 AM UTC-4, Kevin wrote: > >>> "I don't see what commenting and installing software have to do with > each > >>> other" > >>> What is the url for Git that has a list of all the Joomla pull > requests > >>> so that a non dev can decide which bug they can test/comment on ? > Where is the url for the list on Git where non devs can report bugs ? > "In github you can also make a patch+ issue a pull request right on > the > >>> web" > >>> Now either I missed that or it has never been stated before. All the > tutorials I have seen links to have required syncing the computer with > Git(in some way or other.) > >>> Link to a tutorial on how to do pull requests on the web would be good > thanks. Because every thing I've looked at requires all sorts of > configuration before a patch can be applied. > >>> For the umpteenth time testing a Git patch is more complex(initially) > than testing an SVN patch. With svn install one piece of software, > point > >>> it at the svn trunk put in user pass ... done. Download the patch > right > >>> click ... done. But with Git download the software configure to sync > with > >>> Git and a load of other things ... because the software that is used > to > >>> test a Git patch will not work unless you have the whole caboose. btw > Tortoisesvn will download the 2.5 git branch to the computer but not > >>> the trunk. > >>> On Saturday, 6 October 2012 01:58:22 UTC+1, Elin wrote: > >>>> For both github and joomlacode forum users have to register a new > account and learn how to report. > >>>> I don't see what commenting and installing software have to do with > each > >>>> other. If you want to make a comment use the web ui to make a > comment. > >>>> That's exactly the same in both. > >>>> Unlike gForge, Git hub does not have a built in form building UI for > administrators so it loses in the ability to ask or even require > reporters
