Please check out the following documentation which should be of help:
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.
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.
> "I have explained how to use the web ui to make a pull request in at
> 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
> want to test
> "No special software is required to download this file
> 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
> be patched. ... But with an SVN Patch the software that runs the patch
> 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
> 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
> But when the patch contains a/ and b/ in the paths and several files
> 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
> 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
> 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:
>> Yup agree on all counts, Michael is solving things. Still I'm posting some
>> comments below to consider (he already know these).
>> 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
>> is prominently explained in git hub plus ... that EDIT button is right
there on every file.
sympathetic to resistance to change, change in the tracker will mean a
>> 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
>> year for people to submit information about their experiences with any
trackers. If you want to argue that GForge has advantages that is
>> 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"
>> 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
>> that we use to do our work that's a problem. If you think that there
>> backlogs now, you need to assume that using straight github they will
>> worse because of the loss of functionality. So while it might be easier
>> sending code, it will likely be harder for getting code in. Hence why
>> 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
>> have privileges to manage issues on Github, it is 100% up to Mark, JM,
>> 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
>> that load--much much more than me cumulatively-- distributed over many
>> working people. All that we have built in terms of low barrier to
>> participation in bug triaging and tracker management goes out the
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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
>>> What is the url for Git that has a list of all the Joomla pull
>>> 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
>>> 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,
>>> 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
>>> Git and a load of other things ... because the software that is used
>>> 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
>>>> 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
>>>> to provide crucial information like cms version, php version.
>>>> browser. Also github does not have duplicate tracking or a way to
>>>> files. It also does not have query building/saving and downloading to
>>>> or xls. So advantage gForge for those items.
>>>> In github you can also make a patch+ issue a pull request right on
>>>> web. I've gotten dozens of people to make contributions by saying
>>>> to the file, click edit, make the change and click save. So for
>>>> with simple change proposals github wins hands down. You don't even
read more »