Greetings.
So, looking at fedorahosted, I thought I would start some discussion about where we are and where we need to go short and longer term.
Right now hosted03/04 are rhel6 and still in puppet. Short term, I would very much like to move them to ansible, and ideally to rhel7.
I looked into the trac situation upstream. We are currently using 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats out, but it looks like that might be the last release in the 0.12 series (or there might be a 0.12.7, but thats likely to be it). They are looking at doing releases yearly if they can manage, so 1.2 would appear later this year, then 1.3, etc. It's not clear how long 1.0 will be supported really. At least a year, but not clear after that.
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in epel7. This will take a bit longer since there's so many plugins, but shouldn't really be that hard.
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we move ones that want to progit, eventually we have a flag day and move the rest).
6. Some other brilliant plan. ;)
Thoughts? ideas? will also add this to the gobby doc to discuss in meeting.
kevin
On 3 March 2015 at 13:22, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
So, looking at fedorahosted, I thought I would start some discussion about where we are and where we need to go short and longer term.
Right now hosted03/04 are rhel6 and still in puppet. Short term, I would very much like to move them to ansible, and ideally to rhel7.
I looked into the trac situation upstream. We are currently using 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats out, but it looks like that might be the last release in the 0.12 series (or there might be a 0.12.7, but thats likely to be it). They are looking at doing releases yearly if they can manage, so 1.2 would appear later this year, then 1.3, etc. It's not clear how long 1.0 will be supported really. At least a year, but not clear after that.
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in epel7. This will take a bit longer since there's so many plugins, but shouldn't really be that hard.
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
- a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move the rest).
5 sounds like the most likely. There are a lot of work flows which groups are using with the current trac. If they didn't.. they would have probably moved over to github by now. Having the old boxes on ansible is probably faster by at least 18 months over getting people moved to the newer system.
- Some other brilliant plan. ;)
Thoughts? ideas? will also add this to the gobby doc to discuss in meeting.
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 3 Mar 2015 13:30:26 -0700 Stephen John Smoogen smooge@gmail.com wrote:
On 3 March 2015 at 13:22, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
So, looking at fedorahosted, I thought I would start some discussion about where we are and where we need to go short and longer term.
Right now hosted03/04 are rhel6 and still in puppet. Short term, I would very much like to move them to ansible, and ideally to rhel7.
I looked into the trac situation upstream. We are currently using 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats out, but it looks like that might be the last release in the 0.12 series (or there might be a 0.12.7, but thats likely to be it). They are looking at doing releases yearly if they can manage, so 1.2 would appear later this year, then 1.3, etc. It's not clear how long 1.0 will be supported really. At least a year, but not clear after that.
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in epel7. This will take a bit longer since there's so many plugins, but shouldn't really be that hard.
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
- a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move the rest).
5 sounds like the most likely. There are a lot of work flows which groups are using with the current trac. If they didn't.. they would have probably moved over to github by now. Having the old boxes on ansible is probably faster by at least 18 months over getting people moved to the newer system.
I refuse to use github because I personally think its very bad for us as a open and transparent community and project that prides itself on making sure everyone can mimic what we do exactly to use something closed and proprietary. For my own projects I think I would mostly be okay with progit though something would be needed for ticketing for releng, wiki space would be good for some projects but is not really needed on all projects. some like mash only have a git repo on fedorahosted, there is no associated trac. I think 4 or 5 would both be viable.
Dennis
On Tue, Mar 03, 2015 at 10:17:41PM -0600, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 3 Mar 2015 13:30:26 -0700 Stephen John Smoogen smooge@gmail.com wrote:
On 3 March 2015 at 13:22, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
So, looking at fedorahosted, I thought I would start some discussion about where we are and where we need to go short and longer term.
Right now hosted03/04 are rhel6 and still in puppet. Short term, I would very much like to move them to ansible, and ideally to rhel7.
I looked into the trac situation upstream. We are currently using 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats out, but it looks like that might be the last release in the 0.12 series (or there might be a 0.12.7, but thats likely to be it). They are looking at doing releases yearly if they can manage, so 1.2 would appear later this year, then 1.3, etc. It's not clear how long 1.0 will be supported really. At least a year, but not clear after that.
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in epel7. This will take a bit longer since there's so many plugins, but shouldn't really be that hard.
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
- a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move the rest).
5 sounds like the most likely. There are a lot of work flows which groups are using with the current trac. If they didn't.. they would have probably moved over to github by now. Having the old boxes on ansible is probably faster by at least 18 months over getting people moved to the newer system.
I refuse to use github because I personally think its very bad for us as a open and transparent community and project that prides itself on making sure everyone can mimic what we do exactly to use something closed and proprietary. For my own projects I think I would mostly be okay with progit though something would be needed for ticketing for releng, wiki space would be good for some projects but is not really needed on all projects. some like mash only have a git repo on fedorahosted, there is no associated trac. I think 4 or 5 would both be viable.
[Sorry for catching up late to this thread.]
I'm not comfortable yet with the idea of taking on the service build-out that (3) represents above. That's a lot of commitment for something I don't think we can call critical path. Github may be a closed/paid service solution but it doesn't affect the public availability, transparency or forkability of any of our code. And a long-term investment in chasing that solution as a Fedora-specific service to replace hosted is not necessarily the best use of our resources.
On Tuesday, March 10, 2015 05:56:58 PM Paul W. Frields wrote:
On Tue, Mar 03, 2015 at 10:17:41PM -0600, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 3 Mar 2015 13:30:26 -0700
Stephen John Smoogen smooge@gmail.com wrote:
On 3 March 2015 at 13:22, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
So, looking at fedorahosted, I thought I would start some discussion about where we are and where we need to go short and longer term.
Right now hosted03/04 are rhel6 and still in puppet. Short term, I would very much like to move them to ansible, and ideally to rhel7.
I looked into the trac situation upstream. We are currently using 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats out, but it looks like that might be the last release in the 0.12 series (or there might be a 0.12.7, but thats likely to be it). They are looking at doing releases yearly if they can manage, so 1.2 would appear later this year, then 1.3, etc. It's not clear how long 1.0 will be supported really. At least a year, but not clear after that.
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide
something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
epel7. This will take a bit longer since there's so many plugins,
but shouldn't really be that hard.
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
- a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move the rest).
5 sounds like the most likely. There are a lot of work flows which groups are using with the current trac. If they didn't.. they would have probably moved over to github by now. Having the old boxes on ansible is probably faster by at least 18 months over getting people moved to the newer system.
I refuse to use github because I personally think its very bad for us as a open and transparent community and project that prides itself on making sure everyone can mimic what we do exactly to use something closed and proprietary. For my own projects I think I would mostly be okay with progit though something would be needed for ticketing for releng, wiki space would be good for some projects but is not really needed on all projects. some like mash only have a git repo on fedorahosted, there is no associated trac. I think 4 or 5 would both be viable.
[Sorry for catching up late to this thread.]
I'm not comfortable yet with the idea of taking on the service build-out that (3) represents above. That's a lot of commitment for something I don't think we can call critical path. Github may be a closed/paid service solution but it doesn't affect the public availability, transparency or forkability of any of our code. And a long-term investment in chasing that solution as a Fedora-specific service to replace hosted is not necessarily the best use of our resources.
We can agree to disagree here. I think without a good viable open source option we will be locked into a closed proprietary platform. if github jacks up the price or closes down, yes we still have our clones and can put the data elsewhere. but there will be nowhere else viable to put the data, additionally we are saying its okay to compromise our principles when it suits us and puts us on a slippery road. I do not think we should have or want a Fedora specific service. we could potentially use some new service not only for for fedorahosted but for pkgs git. having a good way for people to develop test and send patches to others seems like a huge win to me. I am sure we could probably work cross distro to have a universal solution with a big developer base.
Dennis
Dennis
On Tue, Mar 10, 2015 at 09:26:59PM -0500, Dennis Gilmore wrote:
On Tuesday, March 10, 2015 05:56:58 PM Paul W. Frields wrote:
On Tue, Mar 03, 2015 at 10:17:41PM -0600, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 3 Mar 2015 13:30:26 -0700
Stephen John Smoogen smooge@gmail.com wrote:
On 3 March 2015 at 13:22, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
So, looking at fedorahosted, I thought I would start some discussion about where we are and where we need to go short and longer term.
Right now hosted03/04 are rhel6 and still in puppet. Short term, I would very much like to move them to ansible, and ideally to rhel7.
I looked into the trac situation upstream. We are currently using 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats out, but it looks like that might be the last release in the 0.12 series (or there might be a 0.12.7, but thats likely to be it). They are looking at doing releases yearly if they can manage, so 1.2 would appear later this year, then 1.3, etc. It's not clear how long 1.0 will be supported really. At least a year, but not clear after that.
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide
something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
epel7. This will take a bit longer since there's so many plugins,
but shouldn't really be that hard.
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
- a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move the rest).
5 sounds like the most likely. There are a lot of work flows which groups are using with the current trac. If they didn't.. they would have probably moved over to github by now. Having the old boxes on ansible is probably faster by at least 18 months over getting people moved to the newer system.
I refuse to use github because I personally think its very bad for us as a open and transparent community and project that prides itself on making sure everyone can mimic what we do exactly to use something closed and proprietary. For my own projects I think I would mostly be okay with progit though something would be needed for ticketing for releng, wiki space would be good for some projects but is not really needed on all projects. some like mash only have a git repo on fedorahosted, there is no associated trac. I think 4 or 5 would both be viable.
[Sorry for catching up late to this thread.]
I'm not comfortable yet with the idea of taking on the service build-out that (3) represents above. That's a lot of commitment for something I don't think we can call critical path. Github may be a closed/paid service solution but it doesn't affect the public availability, transparency or forkability of any of our code. And a long-term investment in chasing that solution as a Fedora-specific service to replace hosted is not necessarily the best use of our resources.
We can agree to disagree here. I think without a good viable open source option we will be locked into a closed proprietary platform.
Define "locked"? If we're able to take our data (and even issues) and go elsewhere, where's the lock-in?
I would agree with you if this were about email, wiki, file storage, or some other data type. The DVCS factor clearly separates Github from being an issue of lock-in or a slippery slope. I don't know of another type of data store where there's transparent, potentially infinite mirroring to prevent lock-in.
if github jacks up the price or closes down, yes we still have our clones and can put the data elsewhere. but there will be nowhere else viable to put the data
That's not how I read the above. I don't believe Kevin suggested that e.g. git.fedorahosted.org is dying or needs to shut down imminently, or that Trac was no longer working. I think the discussion is about the long term roadmap for Trac, which is a living and breathing (albeit slow moving AFAICT) upstream project we don't have to maintain ourselves.
additionally we are saying its okay to compromise our principles when it suits us and puts us on a slippery road. I do not think we should have or want a Fedora specific service. we could potentially use some new service not only for for fedorahosted but for pkgs git.
Has someone already looked at Gitlab's hosted offering? I understand the reasons it's difficult to host our own instance, so I'm referring to gitlab.com itself.
having a good way for people to develop test and send patches to others seems like a huge win to me. I am sure we could probably work cross distro to have a universal solution with a big developer base.
Define "big"? Working cross distro is a fine idea, but it only puts us in front of the small percentage of developers working in distro communities. Most of them are elsewhere, and Github is one of the largest communities of developers, as Matthew Miller has pointed out in his FPL presentations.
None of this seems to address the resource problem. Github gives us a frictionless and transparent way to collaborate, it can't steal our code, and the Fedora Engineering team doesn't have the cost of maintaining it in the long run.
So, to recap...
1. We will move fedorahosted to rhel7 soon (with trac, same as it is now)
2. progit isn't a priority, as we have a ton of things to do and thats a bit of a sidetrack from those. It however is an open source project and people will continue to work on and improve it. We will continue to ask for feedback and make it better and advertise it more.
3. Down the road a while when progit is better we will decide when/if it can replace the fedorahosted setup and/or if we can move things that currently use github back to progit (either before or after any fedorahosted migration).
Does that all sound correct?
kevin
On Wednesday, March 11, 2015 09:39:09 AM Kevin Fenzi wrote:
So, to recap...
- We will move fedorahosted to rhel7 soon (with trac, same as it is
now)
- progit isn't a priority, as we have a ton of things to do and thats
a bit of a sidetrack from those. It however is an open source project and people will continue to work on and improve it. We will continue to ask for feedback and make it better and advertise it more.
- Down the road a while when progit is better we will decide when/if
it can replace the fedorahosted setup and/or if we can move things that currently use github back to progit (either before or after any fedorahosted migration).
Does that all sound correct?
That sounds fine to me
Dennis
On Tue, Mar 03, 2015 at 01:30:26PM -0700, Stephen John Smoogen wrote:
On 3 March 2015 at 13:22, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
So, looking at fedorahosted, I thought I would start some discussion about where we are and where we need to go short and longer term.
Right now hosted03/04 are rhel6 and still in puppet. Short term, I would very much like to move them to ansible, and ideally to rhel7.
I looked into the trac situation upstream. We are currently using 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats out, but it looks like that might be the last release in the 0.12 series (or there might be a 0.12.7, but thats likely to be it). They are looking at doing releases yearly if they can manage, so 1.2 would appear later this year, then 1.3, etc. It's not clear how long 1.0 will be supported really. At least a year, but not clear after that.
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in epel7. This will take a bit longer since there's so many plugins, but shouldn't really be that hard.
I'd vote for 1 or 2 as things we can accomplish shorter-term.
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
- a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move the rest).
5 sounds like the most likely. There are a lot of work flows which groups are using with the current trac. If they didn't.. they would have probably moved over to github by now. Having the old boxes on ansible is probably faster by at least 18 months over getting people moved to the newer system.
I'm not sure progit is going to be ready to wholesale replace fedorahosted anytime soon. Perhaps we can 'promote' it though to get more of an idea of where its at, say give it a domain name at progit.cloud.fedoraproject.org ? Let's get a few more people/projects using it.
I'm not sure that adding wiki features and trying to get parity with trac's ticketing system are going to be simple. A barebones implementation could be done, but there will be a long stream of support/RFE tickets that follow if we head down that road.
On Wed, Mar 04, 2015 at 11:12:30AM -0500, Ralph Bean wrote:
On Tue, Mar 03, 2015 at 01:30:26PM -0700, Stephen John Smoogen wrote:
On 3 March 2015 at 13:22, Kevin Fenzi kevin@scrye.com wrote:
So, as I see it, our options are:
1 Just move to ansible, leave on rhel6 for now until we decide something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in epel7. This will take a bit longer since there's so many plugins, but shouldn't really be that hard.
I'd vote for 1 or 2 as things we can accomplish shorter-term.
Depending on how is/hard it is, I'd vote for this as well (see below).
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
4 a combo of 2 and 3 (ie, offer trac and progit both)
- a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move the rest).
5 sounds like the most likely. There are a lot of work flows which groups are using with the current trac. If they didn't.. they would have probably moved over to github by now. Having the old boxes on ansible is probably faster by at least 18 months over getting people moved to the newer system.
I'm not sure progit is going to be ready to wholesale replace fedorahosted anytime soon. Perhaps we can 'promote' it though to get more of an idea of where its at, say give it a domain name at progit.cloud.fedoraproject.org ? Let's get a few more people/projects using it.
While I kinda hope progit gets to a state where it is used and useful, I do not see our trac instances all moving away any time soon (thus the vote for 1 or/and 2).
Having progit.dev.fedoraproject and later maybe progit.fedoraproject.org would already help (I'd rather have .dev. than .cloud. in the url as I believe it is more indicative of the state of the application there). I am planning on blogging and calling for testers once I got around fixing what I still want to fix (unit-tests and finish the git integration for tickets, git integration for pull-request is on the roadmap but I won't wait for it before calling for testers). More people testing will likely also help finding out how usable the system is.
I'm not sure that adding wiki features and trying to get parity with trac's ticketing system are going to be simple. A barebones implementation could be done, but there will be a long stream of support/RFE tickets that follow if we head down that road.
Regarding progit, it will not grow a wiki feature but offers the possibility to have a doc repo containing text, html, markdown or rest files (the last two will be rendered, the first two display).
For the ticketing system, we currently have: Tags: Assigned: Blocking: Depends on: Status: So there won't be a roadmap as there is in trac, but this can be implemented using the Tags, issue dependency is in, as well as assigning issues.
Do we need something else?
Pierre
On Wed, 4 Mar 2015 23:09:03 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
While I kinda hope progit gets to a state where it is used and useful, I do not see our trac instances all moving away any time soon (thus the vote for 1 or/and 2).
Fair enough.
Having progit.dev.fedoraproject and later maybe progit.fedoraproject.org would already help (I'd rather have .dev. than .cloud. in the url as I believe it is more indicative of the state of the application there). I am planning on blogging and calling for testers once I got around fixing what I still want to fix (unit-tests and finish the git integration for tickets, git integration for pull-request is on the roadmap but I won't wait for it before calling for testers). More people testing will likely also help finding out how usable the system is.
Also very reasonable.
It might be good to settle on a new name first? That way there's 'buzz' about it and you don't have to change it after people know it.
Regarding progit, it will not grow a wiki feature but offers the possibility to have a doc repo containing text, html, markdown or rest files (the last two will be rendered, the first two display).
I think that would actually meet the needs of the folks that are using the trac wiki pretty nicely.
For the ticketing system, we currently have: Tags: Assigned: Blocking: Depends on: Status: So there won't be a roadmap as there is in trac, but this can be implemented using the Tags, issue dependency is in, as well as assigning issues.
Do we need something else?
Possibly some way to have sensitive/private tickets?
There may be some small number of people using the roadmap feature (ie, mark 10 tickets for a milestone, when they are solved the release happens, etc)
Ability to mass modify tickets (so you could say "new release, please retest your bug with this version")
libravatar support.
Ability to 'watch' all tickets for a project, ie see all comments to a list or list of addresses.
Templates for some kinds of requests?
Way to attach to tickets? I guess tho that could be done by PR's really most of the time.
There may be other things, but those are the ones that leap to mind.
kevin
On Wed, Mar 04, 2015 at 07:27:59PM -0700, Kevin Fenzi wrote:
On Wed, 4 Mar 2015 23:09:03 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
Having progit.dev.fedoraproject and later maybe progit.fedoraproject.org would already help (I'd rather have .dev. than .cloud. in the url as I believe it is more indicative of the state of the application there). I am planning on blogging and calling for testers once I got around fixing what I still want to fix (unit-tests and finish the git integration for tickets, git integration for pull-request is on the roadmap but I won't wait for it before calling for testers). More people testing will likely also help finding out how usable the system is.
Also very reasonable.
It might be good to settle on a new name first? That way there's 'buzz' about it and you don't have to change it after people know it.
Yes, I clearly need to figure this out soon!
Regarding progit, it will not grow a wiki feature but offers the possibility to have a doc repo containing text, html, markdown or rest files (the last two will be rendered, the first two display).
I think that would actually meet the needs of the folks that are using the trac wiki pretty nicely.
Cool :)
For the ticketing system, we currently have: Tags: Assigned: Blocking: Depends on: Status: So there won't be a roadmap as there is in trac, but this can be implemented using the Tags, issue dependency is in, as well as assigning issues.
Do we need something else?
Possibly some way to have sensitive/private tickets?
http://209.132.184.222/progit/issue/49
There may be some small number of people using the roadmap feature (ie, mark 10 tickets for a milestone, when they are solved the release happens, etc)
I think this can be achieved with tags: http://209.132.184.222/progit/issues?tags=doc list the ticket opened and with this tag
Ability to mass modify tickets (so you could say "new release, please retest your bug with this version")
I'd consider this be part of the API
libravatar support.
Already there: http://209.132.184.222/progit/blob/master/progit/__init__.py#_366 and http://209.132.184.222/progit/blob/master/progit/lib/__init__.py#_831
Ability to 'watch' all tickets for a project, ie see all comments to a list or list of addresses.
http://209.132.184.222/progit/issue/50
Templates for some kinds of requests?
Not sure about this but: http://209.132.184.222/progit/issue/51
Way to attach to tickets? I guess tho that could be done by PR's really most of the time.
Oh yeah, definitely :) http://209.132.184.222/progit/issue/52 This would also help to report problem with screenshot :)
As for Ralph: http://209.132.184.222/progit/issue/53
Thanks all :) Feel free to drop in any tickets you like to comment or patch things :)
Pierre
On Tue, Mar 3, 2015 at 9:23 PM Kevin Fenzi kevin@scrye.com wrote:
1 Just move to ansible, leave on rhel6 for now until we decide something better.
2 Move to ansible and rhel7, and build out trac-1.0 and plugins in epel7. This will take a bit longer since there's so many plugins, but shouldn't really be that hard.
+1
3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready to replace trac though. I think it might need wiki features and also more ticket handling stuff, since some of our projects use trac ticketing heavily.
We also have projects which don't use git as vcs.
infrastructure@lists.fedoraproject.org