> Hi Kevin,

> Please check out the following documentation which should be of help:
> http://docs.joomla.org/Git_for_Testers_and_Trackers

> 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
> >>>> 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 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.
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Sam Moffatt
> >>>>>>>>>>> http://pasamio.id.au
> >>>>>>>>>>> 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.
> > --
> > 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/-/pZjzMLjIEbwJ.
> > 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.