trac-hacks group on GitHub

[RjOllos]

Many users have chosen to host their plugins on GitHub, with a stub page on trac-hacks that points to the GitHub project. The idea of creating a trac-hacks organization on GitHub (0) came to mind again when discussing with a user whether to move some plugins to GitHub (1).

The general idea I have is to try to add users hosting plugins on GitHub to the organization, and to associate their repository with the organization. The aim will be to leave users in control of their repositories, but also allow the trac-hacks admin team to assist with passing ownership of repositories and granting access to other users, in cases that the repository owner gives permission for access or chooses to abandon the repository. This would give us the ability to extend the AdoptingHacks (3) policies to plugins hosted on GitHub.

Other advantages would be, making it easier for users to find plugins hosted on GitHub, and allow us to extend our index (3) to plugins hosted on GitHub.

It's not clear to me yet what is going to work best as far as creating teams. We could create a single developers team, have a team for each trac-hacks user (e.g. team "mitar" for mitar's plugins [4]) or a team for each plugin. Having a team for each plugin would give the most control over granting access to a single user for a single repository. Later on, I hope we can extend the capabilities to integrate trac-hacks with GitHub and sync repositories between trac-hacks and GitHub. There are lots of possibilities there and hopefully there is interest from developers to create the features.

I'm hoping to get feedback from other developers and users, in terms of what the best approaches might be. If we develop a good approach for handling plugins on GitHub, we can later extend it in a similar way to BitBucket, SourceForget, GoogleCode or whatever other sites are relevant and provide the necessary organization capabilities.

(0) https://github.com/orgs/trac-hacks
(1) http://trac-hacks.org/ticket/11832#comment:1
(2) http://trac-hacks.org/wiki/AdoptingHacks
(3) http://trac-hacks.org/wiki/HackIndex
(4) http://trac-hacks.org/wiki/mitar

[Christopher Nelson]

> Many users have chosen to host their plugins on GitHub, with a stub page on
> trac-hacks that points to the GitHub project. The idea of creating a
> trac-hacks organization on GitHub (0) came to mind again when discussing
> with a user whether to move some plugins to GitHub (1).

> ...

I'm a daily git user who struggles though Svn on T-H because I believe
in the one stop shopping it provides. If there was a critical mass of
T-H users on GitHub, I would enthusiastically migrate my plugins.

[Olemis Lang]

I'm not very fond of git at all , TBH . It does not integrate well
with Trac , or at least not as well as mercurial plugin . Working with
git is a bit of pain too , and you know ... hg is powered by Python .
Therefore since few days before PyCon 2014 , we have been maintaining
and synchronizing our own hg mirrors @ bitbucket.org .

I did not announce before in spite of been sure about synchronization
. That seems to be working fine now . Should you notice any issues
please let me know .

JFTR , looking forward we plan to hook those repositories into our
blood-hound.net instance too . So we'll be maintaining them long-term
and are interested in your feedback for improving what we've got so
far .

[...]

--
Regards,

Olemis - @olemislc

Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

[Olemis Lang]

Sorry , missing link

https://bitbucket.org/trac-hacks

for further details please read below

[Saint Germain]

Hello Olemis,

I've had a look (I wanted to contribute a plugin which integrates
Trac/Bloodhound with Piwik) but it seems that there are a lot of dead
links in :
http://blood-hound.net/products

For instance the "Bloodhound meets Django" looks very interesting but
all links are dead...

Best regards,

[Olemis Lang]

On Mon, Jun 23, 2014 at 7:54 AM, Saint Germain <sain...@gmail.com> wrote:

On 22 June 2014 19:16, Olemis Lang <ole...@gmail.com> wrote:
> On 6/22/14, Olemis Lang <ole...@gmail.com> wrote:
>> On 6/22/14, Christopher Nelson <chris.ne...@gmail.com> wrote:

 [...]

>> since few days before PyCon 2014 , we have been maintaining
>> and synchronizing our own hg mirrors @ bitbucket.org .
>>

[...] 

>> JFTR , looking forward we plan to hook those repositories into our
>> blood-hound.net instance too . So we'll be maintaining them long-term
>> and are interested in your feedback for improving what we've got so
>> far .
>>
> Sorry , missing link
>
> https://bitbucket.org/trac-hacks
>
> for further details please read below

Hello Olemis,

Hi !

 

I've had a look (I wanted to contribute a plugin which integrates
Trac/Bloodhound with Piwik) but it seems that there are a lot of dead
links in :
http://blood-hound.net/products

If you talk about : "Missing connector for neighborhood ..." issue , yes , it's true . We are working on fixing that .

 

For instance the "Bloodhound meets Django" looks very interesting but
all links are dead...

 

 

--
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor

[Olemis Lang]

On Mon, Jun 23, 2014 at 10:12 AM, Olemis Lang <ole...@gmail.com> wrote:

Hi !

 

I've had a look (I wanted to contribute a plugin which integrates
Trac/Bloodhound with Piwik) but it seems that there are a lot of dead
links in :
http://blood-hound.net/products

If you talk about : "Missing connector for neighborhood ..." issue , yes , it's true . We are working on fixing that .

 

For instance the "Bloodhound meets Django" looks very interesting but
all links are dead...

 

 

blood-hound.net is not open to users yet . It will be once we deploy OpenId plugin and finish a few pending tasks , we are working on that too . 

p.s. I apologize since this part of the conversation is OT in trac-dev ML .

[Tetsuya Morimoto]

Hi,

I agree on moving plugin repositories into github. I think we can learn from how to manage Jenkins plugin (https://github.com/jenkinsci). I heard that Jenkins organization has all users including each owners/maintainers and give proper permission to ones for their plugin repository.

thanks,

Tetsuya

[RjOllos]

On Thursday, July 17, 2014 2:32:55 AM UTC-7, Tetsuya Morimoto wrote:

Hi,

I agree on moving plugin repositories into github. I think we can learn from how to manage Jenkins plugin (https://github.com/jenkinsci). I heard that Jenkins organization has all users including each owners/maintainers and give proper permission to ones for their plugin repository.

thanks,

Tetsuya

My proposal at least was never about moving repositories into GitHub. It was about aggregating all the trac plugins on GitHub and merging that with trac-hacks.org so that we have one giant index for Trac plugins.

With regard to Trac-Hacks only providing SVN hosting, I hope we can eventually offer Hg and Git repositories as well, but the TracHacksPlugin will need some enhancements to support offering the user a choice of repository types. 

[W. Martin Borgert]

On 2014-06-22 12:12, Olemis Lang wrote:
> I'm not very fond of git at all , TBH . It does not integrate well
> with Trac ,

OT: This is a major problem for Trac. Nothing against hg, but Git
is currently the most successful VCS. If Trac will not improve
its Git support, people will move away from Trac, not from Git.

[Christopher Nelson]

I am a Trac diehard but if you just couldn't use git with it, I would
absolutely keep git; I can't live without it.

We use a custom git hook that links our commits to tickets and are
very happy with it but it did require programming on our part. It was
based originally on a sample that used to be part of the Trac
distribution but has since been removed. That seemed an odd choice.
(There's nothing proprietary about our hook and we'd be glad to give
it back but the file its based on is gone so I don't know where to put
it.)

[Ryan Ollos]

Have you tried Trac 1.0.2? There have been many Git-related fixes:

http://trac.edgewall.org/query?component=plugin%2Fgit&milestone=1.0.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority

[Peter Suter]

On 03.12.2014 16:40, Christopher Nelson wrote:
>> On 2014-06-22 12:12, Olemis Lang wrote:
>>> I'm not very fond of git at all , TBH . It does not integrate well
>>> with Trac ,
>> OT: This is a major problem for Trac. Nothing against hg, but Git
>> is currently the most successful VCS. If Trac will not improve
>> its Git support, people will move away from Trac, not from Git.

Could you give more details about what you mean? Why does git not
integrate well? How would improved git support look like? What's missing
that hg has?

> We use a custom git hook that links our commits to tickets and are
> very happy with it but it did require programming on our part. It was
> based originally on a sample that used to be part of the Trac
> distribution but has since been removed. That seemed an odd choice.
> (There's nothing proprietary about our hook and we'd be glad to give
> it back but the file its based on is gone so I don't know where to put
> it.)

What file disappeared from where?

Jun has also created Git hook scripts. [1] I'm sure he would welcome
improvements and other feedback.

[1] http://trac.edgewall.org/ticket/10730#comment:11

[W. Martin Borgert]

Quoting Peter Suter <pets...@gmail.com>:
> On 03.12.2014 16:40, Christopher Nelson wrote:
>>> On 2014-06-22 12:12, Olemis Lang wrote:
>>>> I'm not very fond of git at all , TBH . It does not integrate well
>>>> with Trac ,
>>> OT: This is a major problem for Trac. Nothing against hg, but Git
>>> is currently the most successful VCS. If Trac will not improve
>>> its Git support, people will move away from Trac, not from Git.
>
> Could you give more details about what you mean? Why does git not
> integrate well? How would improved git support look like? What's
> missing that hg has?

Olemis Lang can probably compare git with hg in Trac.

For me, there are two problems:

1. No nice integration. With typical/simple hooks, the same commits
get referenced (#refs) in tickets again and again when merging and
branching. Worse, if you had a commit closed by a commit
(#closes), but had to reopen later, it gets closed again just by a
merge!

What is missing is a list of commits already processed, so that
Trac doesn't list the same commit multiple times. Or a more
flexible approach, e.g. if one maintains ticket specific branches,
link all changes in the respective branch in the ticket, but also
show merges into master or a release branch.

Good hook scripts for different workflows should be part of the
Trac distribution in the contrib directory.

2. Performance for large repositories. Try to import the linux kernel
source and actually use it. It works neither with nor without
cache, it is too slow to use. Cache creation took many hours on my
notebook computer, btw.

Cheers

[Olemis Lang]

On 12/4/14, W. Martin Borgert <deb...@debian.org> wrote:
> Quoting Peter Suter <pets...@gmail.com>:
>> On 03.12.2014 16:40, Christopher Nelson wrote:
>>>> On 2014-06-22 12:12, Olemis Lang wrote:
>>>>> I'm not very fond of git at all , TBH . It does not integrate well
>>>>> with Trac ,
>>>> OT: This is a major problem for Trac. Nothing against hg, but Git
>>>> is currently the most successful VCS. If Trac will not improve
>>>> its Git support, people will move away from Trac, not from Git.
>>
>> Could you give more details about what you mean? Why does git not
>> integrate well? How would improved git support look like? What's
>> missing that hg has?
>
> Olemis Lang can probably compare git with hg in Trac.
>
> For me, there are two problems:
>
> 1. No nice integration. With typical/simple hooks, the same commits
> get referenced (#refs) in tickets again and again when merging and
> branching. Worse, if you had a commit closed by a commit
> (#closes), but had to reopen later, it gets closed again just by a
> merge!
>
> What is missing is a list of commits already processed, so that
> Trac doesn't list the same commit multiple times. Or a more
> flexible approach, e.g. if one maintains ticket specific branches,
> link all changes in the respective branch in the ticket, but also
> show merges into master or a release branch.
>

It's impossible to describe this aspect better .

> Good hook scripts for different workflows should be part of the
> Trac distribution in the contrib directory.
>

In this case I'm assuming that "workflow" is about repository layouts
like this one ... ?

http://nvie.com/posts/a-successful-git-branching-model/

> 2. Performance for large repositories. Try to import the linux kernel
> source and actually use it. It works neither with nor without
> cache, it is too slow to use. Cache creation took many hours on my
> notebook computer, btw.
>

Yes , and performance is not just about speed but also about stability
. Eventually the Trac service has to be restarted due to issues
*reminiscent* to dangling references or everlasting open file
descriptors .

There is also the fact about supporting more sophisticated features
e.g. TracMercurial supports patch queues repositories and other
advanced aspects whereas e.g. I'm not sure of how well git plugin will
deal with sub repositories .

Nevertheless I'm biased since I use hg most of the time and git only
when I have no other choice . In the later case often when it comes to
third-party private repositories which are not connected to Trac as
issue tracker . In the near future I really hope that Trac can offer
something similar to Bitbucket , for instance , when it comes to
providing useful tools and uniform access that works for both hg & git
; or similar to Gitlab et al. when it comes to supporting advanced yet
useful features .

[Peter Suter]

> OT: This is a major problem for Trac. Nothing against hg, but Git
> is currently the most successful VCS. If Trac will not improve
> its Git support, people will move away from Trac, not from Git.

I forgot to mention I agree this is very important for Trac. But I don't
use Git much myself and such improvements must be driven by users and
their experience.

Thanks for sharing your experience.

On 04.12.2014 10:40, W. Martin Borgert wrote:
> 1. No nice integration. With typical/simple hooks, the same commits
> get referenced (#refs) in tickets again and again when merging and
> branching. Worse, if you had a commit closed by a commit
> (#closes), but had to reopen later, it gets closed again just by a
> merge!
>
> What is missing is a list of commits already processed, so that
> Trac doesn't list the same commit multiple times. Or a more
> flexible approach, e.g. if one maintains ticket specific branches,
> link all changes in the respective branch in the ticket, but also
> show merges into master or a release branch.
>
> Good hook scripts for different workflows should be part of the
> Trac distribution in the contrib directory.

I also agree that including good scripts would be great. The current
situation seems confusing.
I suspect Jun's scripts in #10730 [1] are already much better than the
alternatives, so I hope people try them and discuss which scripts are
recommended and should be included in Trac.

[1] http://trac.edgewall.org/ticket/10730#comment:11