Re: [gitorious] Gitorious Versioning
On Thu, Aug 2, 2012 at 3:37 AM, Ken Dreyer ktdre...@ktdreyer.com wrote: On Wed, Aug 1, 2012 at 4:17 AM, dpwrussell r...@dpwrussell.com wrote: I see that there is the concept of versioning for some time now in Gitorious, but all the installation instructions I have seen involve a checkout from mainline (If versioning is active I'd have expected a checkout of a certain version branch). I've noticed this also, and from a package management perspective this is not really ideal... I think the main reason people do this is that Gitorious development happens pretty quickly, so master is now quite different than what was tagged as v2.2.1. Various Gitorious guides out there on the internet recommend running master because that's what gets all the latest features and bugfixes. Gitorious AS doesn't really do backports to stable branches. You basically have to pick whatever tag git describe tells you (which is unfortunately seven months old now) and freeze there, or else just go with the tip of master. Speaking as a packager, even if we didn't have backports and multiple supported branches, it would be cool if Gitorious AS cut new versions a bit more often. If that were the case, who knows, we might get a step closer to ending the plethora of guides on the internet that say clone mainline and run whatever commit you land on :) Sorry, we've been lazy :-( The next scheduled minor version will introduce LDAP-backed authorization, and should be out within a couple of week. I've spent ages looking, but I can't find out which version I'm running To find what version you're running, look in lib/gitorious.rb Or use the included rake task (`[bundle exec] rake versioning:changelog`), it will list all known versions and highlight which of them you're currently using. or what the roadmap is for releases. Where is this information? As for a release roadmap, I'm not sure there is an official one, but there's plenty of items on the Wishlist and Todo wiki pages. My colleague Thomas just (re-)mentioned that we should do a roadmap this morning, it's something we really need. Cheers, - Marius -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning
On Thu, Aug 2, 2012 at 3:37 AM, Ken Dreyer ktdre...@ktdreyer.com wrote: Speaking as a packager, even if we didn't have backports and multiple supported branches, it would be cool if Gitorious AS cut new versions a bit more often. If that were the case, who knows, we might get a step closer to ending the plethora of guides on the internet that say clone mainline and run whatever commit you land on :) Ken, While we're at the packaging topic: I saw some posts on a Fedora mailing list that you're working on packaging Gitorious for Fedora, that would be really great! Any news? Need help? Cheers, - Marius -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning
Thanks, I discovered I was in fact on 2.2.1 and could just enable private repositories. -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
[gitorious] Gitorious Versioning
I see that there is the concept of versioning for some time now in Gitorious, but all the installation instructions I have seen involve a checkout from mainline (If versioning is active I'd have expected a checkout of a certain version branch). I've spent ages looking, but I can't find out which version I'm running or what the roadmap is for releases. Where is this information? Particularly I'm interested in expressive permissions and I read that this was a part of 2.2 release, but I can't find out what version we're on now, or when that might be released. Thanks, Douglas -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning
On Wed, Aug 1, 2012 at 4:17 AM, dpwrussell r...@dpwrussell.com wrote: I see that there is the concept of versioning for some time now in Gitorious, but all the installation instructions I have seen involve a checkout from mainline (If versioning is active I'd have expected a checkout of a certain version branch). I've noticed this also, and from a package management perspective this is not really ideal... I think the main reason people do this is that Gitorious development happens pretty quickly, so master is now quite different than what was tagged as v2.2.1. Various Gitorious guides out there on the internet recommend running master because that's what gets all the latest features and bugfixes. Gitorious AS doesn't really do backports to stable branches. You basically have to pick whatever tag git describe tells you (which is unfortunately seven months old now) and freeze there, or else just go with the tip of master. Speaking as a packager, even if we didn't have backports and multiple supported branches, it would be cool if Gitorious AS cut new versions a bit more often. If that were the case, who knows, we might get a step closer to ending the plethora of guides on the internet that say clone mainline and run whatever commit you land on :) I've spent ages looking, but I can't find out which version I'm running To find what version you're running, look in lib/gitorious.rb or what the roadmap is for releases. Where is this information? As for a release roadmap, I'm not sure there is an official one, but there's plenty of items on the Wishlist and Todo wiki pages. -Ken -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
So, please, take a look at ditz: http://ditz.rubyforge.org/ It's ruby. It has plugable system. It offers UI. And it's a distributed issue tracking. I have looked at it, and I find it very interesting. If memory serves me right, I think the missing piece in Ditz was the UI. But that can be built on top of it later anyway I guess. Anyway, we're now concentrating on getting issues.gitorious.org up and running, and then we'll deal with issue tracking integration for projects later. Christian -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
2011/7/5 Christian Johansen christ...@cjohansen.no: As for the discussion on issue tracking and Gitorious in general: I agree that if/when issue tracking becomes a part of Gitorious (pluggable in some way) - i.e. something we offer projects hosted with us - shipping something which is distributed is key. We've been mulling over this a lot, and even looked at a few such systems backed by Git. I don't know yet exactly how it would work, but I want an issue tracking system that: stores issues in plain text (so they can be put in Git) can be distributed has a CLI for programmer efficiency has pluggable nice UI for stake-holders Obviously, as Rodrigo said, we likely won't be able to build something like that any time soon, but for what it's worth, these are some of my ideas on the topic. So, please, take a look at ditz: http://ditz.rubyforge.org/ It's ruby. It has plugable system. It offers UI. And it's a distributed issue tracking. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
I'm impressed! One just probably need a bugs branch to get things working and gitorious can look into this and show issues related to the repo (or project if needed). Thanks for the pointer. On 05/07/2011 16:53, Guilhem Bonnefille wrote: 2011/7/5 Christian Johansenchrist...@cjohansen.no: As for the discussion on issue tracking and Gitorious in general: I agree that if/when issue tracking becomes a part of Gitorious (pluggable in some way) - i.e. something we offer projects hosted with us - shipping something which is distributed is key. We've been mulling over this a lot, and even looked at a few such systems backed by Git. I don't know yet exactly how it would work, but I want an issue tracking system that: stores issues in plain text (so they can be put in Git) can be distributed has a CLI for programmer efficiency has pluggable nice UI for stake-holders Obviously, as Rodrigo said, we likely won't be able to build something like that any time soon, but for what it's worth, these are some of my ideas on the topic. So, please, take a look at ditz: http://ditz.rubyforge.org/ It's ruby. It has plugable system. It offers UI. And it's a distributed issue tracking -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
I don't see any advantage in having a distributed issue tracker, maybe there are some, but I think issue tracking is a central and unique service. You don't want (at least I don't see a reason for) QA, testing and management to have a clone of your repositories for adding bug reports. And you definitely don't want to have some issues added to a fork and not the main repository. Having a pluggable system, for supporting chiliproject, redmine, jira, bugzilla, or some other issue tracker is probably the best solution on the long run. Just my 2 cents. Cheers, Pedro On Tue, Jul 5, 2011 at 2:59 AM, Christian Johansen christ...@cjohansen.nowrote: Hi Rodrigo, Thanks for the initiative! See my responses below. First of all, since I'm moving my job I'm using my free time and energy focusing on this change, so I'm delaying the OpenID test writing for now, sorry. Nothing to be sorry about. Thanks for keeping us updated. Mailing list are ineffective as an issue tracking system and Gitorious definitely needs an issue tracking system. Writing a good tracking system from scratch and integrating it to Gitorious is too much work. That means it won't happen any time soon. It also means more code to maintain. Agreed. So, I'd like to suggest that we created a chiliproject.gitorious.org or issues.gitorious.org for managing Gitorious issues, versioning and roadmap. This is a great suggestion. We've been delaying a decision in issue tracking for a long while, and I think it's time to just pick something and get started. We can always move later. These version numbering suggestions will of course depend on Gitorious priority, demand and availability from developers that will work on each feature. But we'll be able to get more feedback and contributions this way... Relying only in a mailing system is a very poor feedback solution. A roadmap of some sort is a good idea. I don't think we'll be able to pin features down in such a detailed way, but we could at least advertise features in planning, have a discussion about them and indicate timespan for deployment of such features. We will also get started on documenting changesets and version numbers ASAP. I will look at getting a Chiliproject setup up and running shortly, maybe I have some more feedback after that. As for the discussion on issue tracking and Gitorious in general: I agree that if/when issue tracking becomes a part of Gitorious (pluggable in some way) - i.e. something we offer projects hosted with us - shipping something which is distributed is key. We've been mulling over this a lot, and even looked at a few such systems backed by Git. I don't know yet exactly how it would work, but I want an issue tracking system that: - stores issues in plain text (so they can be put in Git) - can be distributed - has a CLI for programmer efficiency - has pluggable nice UI for stake-holders Obviously, as Rodrigo said, we likely won't be able to build something like that any time soon, but for what it's worth, these are some of my ideas on the topic. Christian -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
2011/7/3 Rodrigo Rosenfeld Rosas rr.ro...@gmail.com: Then, I would like to start a discussion of a feature I always missed in Gitorious. That discussion is also in alignment with the recent concerns about Gitorious versioning. Mailing list are ineffective as an issue tracking system and Gitorious definitely needs an issue tracking system. Writing a good tracking system from scratch and integrating it to Gitorious is too much work. That means it won't happen any time soon. It also means more code to maintain. Using an external issue-tracking system integrated to Gitorious, as the Ruby language does with Redmine, seems to be the way to go for now. Of course, external issue-tracking is probably the most simple solution. But why not promoting more and more distributed model? I know that many distributed issue tracking tools exist. Why not selecting and integrating one with gitorious? This would give gitorious many advantages over other solution. At the same time, you can regularly ignore my proposition as I do not have any spare time to invest on this topic. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
Em 04-07-2011 09:43, Guilhem Bonnefille escreveu: 2011/7/3 Rodrigo Rosenfeld Rosasrr.ro...@gmail.com: Then, I would like to start a discussion of a feature I always missed in Gitorious. That discussion is also in alignment with the recent concerns about Gitorious versioning. Mailing list are ineffective as an issue tracking system and Gitorious definitely needs an issue tracking system. Writing a good tracking system from scratch and integrating it to Gitorious is too much work. That means it won't happen any time soon. It also means more code to maintain. Using an external issue-tracking system integrated to Gitorious, as the Ruby language does with Redmine, seems to be the way to go for now. Of course, external issue-tracking is probably the most simple solution. But why not promoting more and more distributed model? I know that many distributed issue tracking tools exist. Why not selecting and integrating one with gitorious? This would give gitorious many advantages over other solution. Could you be more specific? Is there any specific tool you're talking about. The ones I've seen cannot be compared to Redmine or Chiliproject powerness... What kind of benefits do you see in those distributed issue tracking alternatives? -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
Em 04-07-2011 13:27, Guilhem Bonnefille escreveu: 2011/7/4 Rodrigo Rosenfeld Rosasrr.ro...@gmail.com: Em 04-07-2011 09:43, Guilhem Bonnefille escreveu: 2011/7/3 Rodrigo Rosenfeld Rosasrr.ro...@gmail.com: Then, I would like to start a discussion of a feature I always missed in Gitorious. That discussion is also in alignment with the recent concerns about Gitorious versioning. Mailing list are ineffective as an issue tracking system and Gitorious definitely needs an issue tracking system. Writing a good tracking system from scratch and integrating it to Gitorious is too much work. That means it won't happen any time soon. It also means more code to maintain. Using an external issue-tracking system integrated to Gitorious, as the Ruby language does with Redmine, seems to be the way to go for now. Of course, external issue-tracking is probably the most simple solution. But why not promoting more and more distributed model? I know that many distributed issue tracking tools exist. Why not selecting and integrating one with gitorious? This would give gitorious many advantages over other solution. Could you be more specific? Is there any specific tool you're talking about. The ones I've seen cannot be compared to Redmine or Chiliproject powerness... What kind of benefits do you see in those distributed issue tracking alternatives? The simple answer: the same benefits as distributed version control. The longer: - synced with source code - stored in the history (backup, local/forked bugs...) - simply editable (vi/emacs is enough) The matter is the lack of high level GUI. And, IMHO, a tool like gitorious can do this. Exactly! That is why I still would go with Redmine or Chiliproject since their UI is awesome and UI is critical for this kind of system IMHO. Also, delegating such a task to Gitorious is way too much extra work to maintain IMHO and I would instead prefer some mountable application based solution now that Rails 3.1 will support this concept as some frameworks already do for Python, for instance... -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
[gitorious] Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
Hi there! First of all, since I'm moving my job I'm using my free time and energy focusing on this change, so I'm delaying the OpenID test writing for now, sorry. Then, I would like to start a discussion of a feature I always missed in Gitorious. That discussion is also in alignment with the recent concerns about Gitorious versioning. Mailing list are ineffective as an issue tracking system and Gitorious definitely needs an issue tracking system. Writing a good tracking system from scratch and integrating it to Gitorious is too much work. That means it won't happen any time soon. It also means more code to maintain. Using an external issue-tracking system integrated to Gitorious, as the Ruby language does with Redmine, seems to be the way to go for now. Have been using Redmine for 4 years now (and its fork Chiliproject more recently), I can tell you it is a comprehensive issue tracking system, supporting roadmap, versioning, wiki, forum, documents, attachments, VCS (SCM) integration and several interesting plugins like scrum-pm and many others. It is amazing for various reasons (I'll list only the ones I think apply to Gitorious, skipping subprojects, time-tracking, etc): - clean interface (really!) - fast (specially from a user's perspective) - easy to install and set up - a lot customizable (really!) - flexible role-based access control and flow settings - gantt/calendar - easily extensible with plugins - translated to several languages (user preference) - notifications by e-mail of issues and activities being watched according to user's preference - RSS feeds for lots of items like project tasks, my tasks, news, commits, activities among others It has good test coverage and I've never seen any problem with Redmine or Chiliproject itself (I use some other plugins that are neither well written nor have a test suite). I would recommend Chiliproject over Redmine for some reasons: - Chiliproject fork seems to have more contributors; - the main repository is tracked with Git (Redmine is tracked with Subversion), which makes it easy to contribute in my opinion; - dependencies are managed with Bundler already (both still use Rails 2.3). So, I'd like to suggest that we created a chiliproject.gitorious.org or issues.gitorious.org for managing Gitorious issues, versioning and roadmap. Of course that, being a separate application, it would only apply to Gitorious itself and not for projects hosted in Gitorious.org, but that is a start already. We can include this integrated issue tracking system per Gitorious project in some roadmap. We could start registering some planning already, like the suggested roadmap (I'm using the 3 numbering scheme, but it doesn't matter for what I'm talking about): Version 1.0.0 - current version Version 1.1.0: - migration to Rails 3 - migration to Devise - replacing of several plugins by new ones and new APIs like the ones written for searching and queuing. Version 1.2.0: - support for more authentication systems integration, like LDAP and others supported by OmniAuth Version 1.3.0: - JRuby support - one-click-install Version 1.4.0: - support for multiple languages instead of defining a single language in gitorious.yml - changing locales/language.rb to locales/language.yml (maybe this should go to 1.1.0 or 1.2.0) - add some integrated issue tracking system per project These version numbering suggestions will of course depend on Gitorious priority, demand and availability from developers that will work on each feature. But we'll be able to get more feedback and contributions this way... Relying only in a mailing system is a very poor feedback solution. Thoughts? -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
