From contact at dvisionfactory.com Fri Dec 1 13:31:08 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Fri, 01 Dec 2006 18:31:08 +0000 Subject: [Retrospectiva-general] Something for the weekend - Announcement of Retrospectiva [Collaboa fork] Message-ID: <457074EC.1050703@dvisionfactory.com> Hi! I would like to announce the first development release of Retrospectiva, a web based project management tool for software development projects, originally based on Collaboa. Features: Simple but very flexible extension interface Issue tracking Code browser (Subversion SVN) Changeset and revision management Wiki (Extension) Announcement Blog (Extension) Multiple repositories and projects Multiple built-in SPAM filtering techniques Short notes: I have reworked Collaboa from the ground up, to make it more maintainable and understandable. Not much of the old code has survived, so the both projects are not compatible to each other, BUT there is a simple way to migrate the old Collaboa database to the new format. I could write a (ActiveRecord) migration script if there;s a significant interest in transferring old data to Retrospectiva. Please visit www.retrospectiva.org for more announcements, guides and details. For questions and suggestions, please use the mailing list on http://rubyforge.org/mail/?group_id=2685. Dimitrij From esad at esse.at Fri Dec 1 21:09:28 2006 From: esad at esse.at (Esad Hajdarevic) Date: Sat, 02 Dec 2006 03:09:28 +0100 Subject: [Retrospectiva-general] first impressions Message-ID: <4570E058.1050404@esse.at> Hi! After taking a first look at retrospectiva, here are some comments: 1. Why not implement tickets and svn (changesets and code browser) as extensions too? I didn't manage to get R running locally yet, so I'm not sure if these can be disabled at all? Are extensions global or per-project? (There are projects for which I'd like to have wiki and some, smaller ones, don't require it) 2. The bottom bar with RSS feeds is not that useful to be always present. You usually add the RSS feed once and forget it. Why not use the established orange RSS symbol too? 3. Why not move "Add new Ticket" to Tickets submenu? If we rework (read: make it compacter and simpler) the new ticket dialog, it could even be shown dynamically on the same page. 4. Changesets page looks empty. Why not add the files added/changed and relative times (5 minutes ago instead of Dec 02 2006 * 02:08).? 5. I was considering writing a "discussion" extension, which would be a built-in forum for the project. Do you have any ideas or suggestion regarding such feature? 6. Under what license/copyright are the contributed extensions going to be published? Dimitrij, have you considered switching the license to more liberal MIT? Otherwise, the projects looks very promising, especially the extensions interface! Keep up with the good work, Esad From contact at dvisionfactory.com Sat Dec 2 07:49:21 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Sat, 02 Dec 2006 12:49:21 +0000 Subject: [Retrospectiva-general] first impressions Message-ID: <45717651.5080004@dvisionfactory.com> Hi! Thanks for the response! > 1. Why not implement tickets and svn (changesets and code browser) as > extensions too? > I didn't manage to get R running locally yet, so I'm not sure if these > can be disabled at all? > Code browser can be disabled, by setting the ENABLE_SUBVERSION constant to false in the environment.rb. I will add a "unless const_defined" condition, so afterwards everyone should be able to override this constant in config.rb! In general: sure these component can easily be extracted, but I - personally - consider (at least) bug tracking as a core component for the management of a project. Do you disagree? > Are extensions global or per-project? (There are projects for which I'd > like to have wiki > and some, smaller ones, don't require it) > Usually, extensions are global, because there is no *safe* way to 'unrequire' a module in ruby online (without restarting the server). That's also the reason why the extension management needs to be done offline (by the script/rxm console app). To solve your problem, it would easily be possible to "hide" extension compontents on a per-project basis. That would be something I also would like to have in v1.0. File a new "enhancement" ticket on retrospectiva.org, and ... let's see! > 2. The bottom bar with RSS feeds is not that useful to be always > present. You usually > add the RSS feed once and forget it. Why not use the established orange > RSS symbol too? > I think that is a question of personal preference. I prefer it the current way ;-). > 3. Why not move "Add new Ticket" to Tickets submenu? If we rework (read: > make it compacter > and simpler) the new ticket dialog, it could even be shown dynamically > on the same page. > Again, a question of personal preference. I consider this arrangement as more clear. > 4. Changesets page looks empty. Why not add the files added/changed and > relative times > (5 minutes ago instead of Dec 02 2006 * 02:08).? > That was a bug, it has been already solved, "files added/changed" are now shown! Relative times would be really easy to add. File a "enhancement" Ticket! > 5. I was considering writing a "discussion" extension, which would be a > built-in forum > for the project. Do you have any ideas or suggestion regarding such feature? > Feel free to do it. I would really appreciate your help. If you need any hints on extension writing, do not hesitate to ask. You can also summarise your gained "extension writing experiences" in the Wiki so others can benefit from them. I have currently no plans for such a feature, my current goal is the stablisation of Retrospectiva for v1.0. > 6. Under what license/copyright are the contributed extensions going to > be published? > Dimitrij, have you considered switching the license to more liberal MIT? > Why is everyone asking me for that? So let's start a discussion! How could the project benefit from switching to the MIT license? I mainly see disadvantages. > Otherwise, the projects looks very promising, especially the extensions > interface! > Thanks! > Keep up with the good work, I will try! Keep supporting me ;-)! Cheers (LG), Dimitrij From esad at esse.at Sat Dec 2 14:00:20 2006 From: esad at esse.at (Esad Hajdarevic) Date: Sat, 02 Dec 2006 20:00:20 +0100 Subject: [Retrospectiva-general] first impressions In-Reply-To: <45717651.5080004@dvisionfactory.com> References: <45717651.5080004@dvisionfactory.com> Message-ID: <4571CD44.2020500@esse.at> Hi! > In general: sure these component can easily be extracted, but I - > personally - consider (at least) bug tracking as a core component for > the management of a project. Do you disagree? > It is essential, but having it implemented as an extension would allow users to write a replacement if they're not satisfied with the current implementation. However, this is not priority, I would leave that for 1.1 release. > To solve your problem, it would easily be possible to "hide" extension > compontents on a per-project basis. That would be something I also would > like to have in v1.0. File a new "enhancement" ticket on > retrospectiva.org, and ... let's see! > > You are right, I've already filed a ticket. But let's please allow everything to be configured (shown/hidden) a not make assumptions on what is "essential" and let user decide it. > I think that is a question of personal preference. I prefer it the > current way ;-). > It really looks cool, but have you really given it a second thought - it is always present (some kind of status bar), but is rarely used. Why not make it a some kind of status bar where update messages are shown? We could make it an options, but in the long run having a lot of this configurable details would lead to a very big/cluttered configuration screen. >> 3. Why not move "Add new Ticket" to Tickets submenu? If we rework (read: >> make it compacter >> and simpler) the new ticket dialog, it could even be shown dynamically >> on the same page. >> >> > Again, a question of personal preference. I consider this arrangement as > more clear. > I think this will become necessary as we add more features to the ticketing such as custom reports, but it's not necessary now. > That was a bug, it has been already solved, "files added/changed" are > now shown! Relative times would be really easy to add. File a > "enhancement" Ticket! > Added new ticket for that. Can you update the www.retrospectiva.org to the newest revision or at least show which version is it running? Cheers, Esad From contact at dvisionfactory.com Sun Dec 3 06:13:54 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Sun, 03 Dec 2006 11:13:54 +0000 Subject: [Retrospectiva-general] Retrospectiva first thoughts In-Reply-To: References: Message-ID: <4572B172.8060504@dvisionfactory.com> Jamie Wilkinson wrote: > Hey Dimitrij, > > Having trouble subscribing to the mailing list but wanted to share some initial user-end thoughts Great to see the ROR project management banner picked up again! > > I haven't poked into the code much yet, please excuse any obvious questions: > > - This is awesome > - Extensions = super awesome. Maybe place them in /vendor/extensions? Awesome either way. > - My install would be home to a number of different projects, each with its own admins. Playing around with the permissions setup is revealing that the 'admin' perm is unsticky for non-admin users (on purpose?). Can adminship be assigned per-project? e.g. I am a contributor to Retrospectiva but the admin of XProject > - More perms: no 'releases' perm for users -- only the admin can issue releases > - I'd love to work some code in that allows one to use Rspectiva (getting carpal tunnel from the long title!) as a *complete* subversion management tool, meaning it to manipulate actual repositories, manage the user and access policy files, and do dumps & loads -- love to write an extension to this effect, although there's a bit of redundancy w/ the actual "repositories" functionality... be nice if it said "hey, no repository exists at this path, do you want to create it?" kind of thing. > - Awesome! Glad to see some competition for Trac & Collaboa :) > > Will tool around some more tomorrow and let you know what I find! > -jamie Hi! 1.) Please try to re-subscribe to the mailing list, so others could benefit from our discussion. 2.) Thanks for the compliments. > - My install would be home to a number of different projects, each > with its own admins. Playing around with the permissions setup is > revealing that the 'admin' perm is unsticky for non-admin users (on > purpose?). Can adminship be assigned per-project? e.g. I am a > contributor to Retrospectiva but the admin of XProject Something similar is planned for v1.1, I really want a stable release 1.0, so I try to avoid to implement too many more features. > - More perms: no 'releases' perm for users -- only the admin can issue > releases Sorry, but I do not really understand that one. Could you describe me a use case scenario? > - I'd love to work some code in that allows one to use Rspectiva > (getting carpal tunnel from the long title!) as a *complete* > subversion management tool, meaning it to manipulate actual > repositories, manage the user and access policy files, and do dumps & > loads -- love to write an extension to this effect, although there's a > bit of redundancy w/ the actual "repositories" functionality... be > nice if it said "hey, no repository exists at this path, do you want > to create it?" kind of thing. That is a great extension idea and there are no more redundancies, since ActionSubversion +has left+ the project. Cheers Dimitrij From contact at dvisionfactory.com Sun Dec 3 06:23:36 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Sun, 03 Dec 2006 11:23:36 +0000 Subject: [Retrospectiva-general] first impressions References: 45717651.5080004@dvisionfactory.com Message-ID: <4572B3B8.30506@dvisionfactory.com> > > It is essential, but having it implemented as an extension would allow > users to write a replacement > if they're not satisfied with the current implementation. That is already possible with the current version of the extension interface. Model extensions can be placed in the /ext directory (look on my extension code), controller extensions can be made (the usual rails way), by: # extension/my/some_controller_extension.rb module SomeControllerExtension def self.included(base) base.extend(ClassMethods) end module ClassMethods ... end end SomeController.send(:include, SomeController) # extension/my/ext_info.rb # hook up code require 'some_controller_extension' > Can you update the www.retrospectiva.org to > the newest revision or at least > show which version is it running? Usually retrospectiva.org is always running the latest SVN revision. Sometimes, before I commit new code to SVN, I use the non-published version to make some late tests (memory issue tests, etc.). Cheers Dimitrij From esad at esse.at Sun Dec 3 08:22:03 2006 From: esad at esse.at (Esad Hajdarevic) Date: Sun, 03 Dec 2006 14:22:03 +0100 Subject: [Retrospectiva-general] ticket/revision references Message-ID: <4572CF7B.9020608@esse.at> Hi! How do I reference to a ticket or to a revision in the ticket/svn commit messages? You know, something that gets automatically replaced with the URL to the right changeset/ticket? Esad From contact at dvisionfactory.com Sun Dec 3 12:15:14 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Sun, 03 Dec 2006 17:15:14 +0000 Subject: [Retrospectiva-general] ticket/revision references Message-ID: <45730622.70200@dvisionfactory.com> The Regex-String for Changesets is \[\d+\] and for Tickets \[#\d+\]. So [12] will be matched as Changeset and [#12] as Ticket (both also require the actual presence of a record). See http://retrospectiva.org/browse/trunk/app/helpers/application_helper.rb - format_internal_links(markup) (line 187) for details. See http://retrospectiva.org/ticket/10 and http://retrospectiva.org/changeset/28 for an example. Dimitrij From jamie-list at tramchase.com Sun Dec 3 12:46:12 2006 From: jamie-list at tramchase.com (Jamie Wilkinson) Date: Sun, 3 Dec 2006 12:46:12 -0500 Subject: [Retrospectiva-general] Retrospectiva first thoughts (adminship, svnadmin extension) In-Reply-To: <4572B172.8060504@dvisionfactory.com> References: <4572B172.8060504@dvisionfactory.com> Message-ID: <8E5FF854-EA40-4834-A837-6F9711A06B73@tramchase.com> >> Can adminship be assigned per-project? e.g. I am a >> contributor to Retrospectiva but the admin of XProject > Something similar is planned for v1.1, I really want a stable release > 1.0, so I try to avoid to implement too many more features. Cool, no worries. Putting the code out there is certainly more important than being 100% feature-complete at this point >> - More perms: no 'releases' perm for users -- only the admin can >> issue >> releases > Sorry, but I do not really understand that one. Could you describe > me a > use case scenario? What I meant was that "releases" stuff is only available in the admin page, which is only available to the admin. More tooling around today revealed that the releases stuff isn't publicly exposed yet so it's a moot point. Relating to my idea about a 'literal' subversion admin extension, could "issuing a release" be hooked into the actual 'svn copy' needed to issue a new tag? -jamie From esad at esse.at Sun Dec 3 17:36:13 2006 From: esad at esse.at (Esad Hajdarevic) Date: Sun, 03 Dec 2006 23:36:13 +0100 Subject: [Retrospectiva-general] ticket/revision references In-Reply-To: <45730622.70200@dvisionfactory.com> References: <45730622.70200@dvisionfactory.com> Message-ID: <4573515D.4030809@esse.at> Dimitrij Denissenko wrote: > The Regex-String for Changesets is \[\d+\] and for Tickets \[#\d+\]. So > [12] will be matched as Changeset and [#12] as Ticket (both also require > the actual presence of a record). > What do you think of using r\d+ for revisions (like r130) and simply #\d+ (#16) for tickets? Esad From jamie-list at tramchase.com Mon Dec 4 00:47:51 2006 From: jamie-list at tramchase.com (Jamie Wilkinson) Date: Mon, 4 Dec 2006 00:47:51 -0500 Subject: [Retrospectiva-general] ticket/revision references In-Reply-To: <4573515D.4030809@esse.at> References: <45730622.70200@dvisionfactory.com> <4573515D.4030809@esse.at> Message-ID: +1 to r\d Any arguments to not do both? -jamie On Dec 3, 2006, at 5:36 PM, Esad Hajdarevic wrote: > Dimitrij Denissenko wrote: >> The Regex-String for Changesets is \[\d+\] and for Tickets \[#\d+ >> \]. So >> [12] will be matched as Changeset and [#12] as Ticket (both also >> require >> the actual presence of a record). >> > > What do you think of using r\d+ for revisions (like r130) and simply > #\d+ (#16) for tickets? > > Esad > _______________________________________________ > Retrospectiva-general mailing list > Retrospectiva-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/retrospectiva-general From christoph.sturm at gmail.com Tue Dec 5 00:34:49 2006 From: christoph.sturm at gmail.com (Christoph Sturm) Date: Tue, 5 Dec 2006 06:34:49 +0100 Subject: [Retrospectiva-general] schema converting from collaboa. Message-ID: <11dae57c0612042134i73195d8r8122c77120329e4b@mail.gmail.com> Hey! I tested the schema conversion from collaboa, and have some comments: 1. please put the migration file into the svn repository, because then its easier to get it from a server, and its possible to create patches for it. 2. remove_column :user_projects, "authorized", :boolean should be changed to remove_column :user_projects, "authorized" 3. after migration no user can log in because the sha1 generator has a different seed in retrospeciva than in collaboa: this can be fixed by changing user.rb: Index: app/models/user.rb =================================================================== --- app/models/user.rb (revision 30) +++ app/models/user.rb (working copy) @@ -73,7 +73,7 @@ end def self.hash_crypt(pass) - Digest::SHA1.hexdigest("+++{{#{pass}}}---") + Digest::SHA1.hexdigest("c-o-l-l-a-b-o-a--#{pass}--") end private The migration doesnt set schema_version, so running rake migrate after the migration fails. (my guess is it should set the schemaversion to 37). 4. retrospectiva runs very unstable with this migrated database. viewing a ticket results in a internal server error. undefined method `name' for nil:NilClass On line #23 of app/views/tickets/show.rhtml 20: 21: 22: Priority: 23: <%= @ticket.priority.name -%> 24: Milestone: 25: <%= @ticket.milestone.name unless @ticket.milestone.blank? -%> 26: and after fixing that i get the next error here: ActionView::TemplateError (Symbol as array index) on line #11 of app/views/tickets/_ticket_change.rhtml: 8: <% if ticket_change.has_changes? || ticket_change.has_attachment? -%> 9:
    10: <% ticket_change.changes.each_pair do |attribute, change| -%> 11:
  • <%= attribute.humanize %>: <%= format_ticket_change(change) %>
    • 12: <% end -%> 13: <% if ticket_change.has_attachment? -%> 14:
  • Attachment added: With a fresh database viewing tickets works. With the fresh database i have the problem that i dont see any changesets (repository browsing works) regards chris -- christoph.sturm at gmail.com From contact at dvisionfactory.com Tue Dec 5 08:18:38 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Tue, 05 Dec 2006 13:18:38 +0000 Subject: [Retrospectiva-general] schema converting from collaboa. Message-ID: <457571AE.8070500@dvisionfactory.com> Hi Chris! Thanks for testing the schema conversion. As suggested, it is a part of the trunk now. The new script fixes: > 2. remove_column :user_projects, "authorized", :boolean > should be changed to > remove_column :user_projects, "authorized" and > The migration doesnt set schema_version and > viewing a ticket results in a internal server error. > undefined method `name' for nil:NilClass > On line #23 of app/views/tickets/show.rhtml I would need your debug output to be able to fix: > ActionView::TemplateError (Symbol as array index) on line #11 of Now to your specific problem: > With the fresh database i have the problem that i dont see any > changesets (repository browsing works) Have you tried to run 'ruby script/sync_changesets'. If it doesn't help, try to add debug logger statements to the sync_changesets method in model/repository.rb (first of all check the 'revisions_to_sync' variable). You can also try to run (at your own risk :-)) 'ruby script/sync_changesets -t'. This will truncate the 'changesets' and the 'changes' table and completely re-sync the repository(ies). Cheers Dimitrij From contact at dvisionfactory.com Tue Dec 5 08:41:55 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Tue, 05 Dec 2006 13:41:55 +0000 Subject: [Retrospectiva-general] Licence debate Message-ID: <45757723.20602@dvisionfactory.com> Hi! First of all, thanks for your appreciation! I am sorry to tell you that this stupid licensing discussion, which is obviously my fault, since I should have spent more time reflecting it, has already left its marks (eg. I am not welcome at the Collaboa mailing list anymore), but please keep alway in mind, that I made Retrospectiva just within 4 weekends, so there was not much time for reflection. You (as well as Chis) are absolutely right about my intentions: I just want to make a good piece of software and I simply don't (didn't) care about all this licensing stuff at all, I decided to use the GPL, basically just because I like the idea of 'copyleft'. If everybody is suggesting to switch to the MIT, no problem, I will do it, as long as it is a benefit for the project. As far as I can see, it IS actually the "easiest in this situation". Just a few more question to whom it may concern: - As you might have noticed, I am not an expert on licensing at all! So does anybody see any negative impacts of "switching to MIT" for Retrospectiva in the long run? - Do you have any other helpful suggestions about license types and models? Thanks Dimitrij > Hi Dimitri. > I just want to say, I think its great you are working on retrospectiva. > Even tho it is a fork from collaboa their are bound to be lots of > crossover/similar issues. > I sincerley hope that this licensing issue doesn't leave any grudges. > It does appear that if you don't care much about licensing the easiest thing > to do would be to just use MIT, not that its best or anything, just that it > might be easiest in this situation. > In any case, thanks for releasing the work you have done for the rest of us > to look at and use. > ~Michael Fairchild > > On 12/4/06, Christoph Sturm > wrote: > >/ > />/ hey dim! > />/ > />/ you should really try to understand johans points. What you are doing > />/ right now is just violate his license. > />/ > />/ to fix that you must basically license retrospectiva under the MIT > />/ license, and everywhere where you declare your copyright you must also > />/ declare his. > />/ > />/ What i find a bit strange is that you insinst on using the gpl > />/ licence, but also state that actually you dont really care about > />/ licensing at all, and would prefer to spend your time coding. > />/ > />/ regards > />/ chris > />/ > />/ On 12/3/06, Dimitrij Denissenko > wrote: > />/ > Dear Johan! > />/ > > />/ > Once again, it is NOT MY INTENTION to violate any licenses or to > />/ > disrespect any previous work. Far from it, I would like to please > />/ > everybody as good as it gets. I would strongly disagree that 95% of the > />/ > code is yours, although the ideas (or names) may have not changes, the > />/ > code has, I have reformulated almost every single line (except the > />/ > views). Finally the number does not make any difference, either 10% or > />/ > 95%, I agree, some code lines of Retrospectiva are STILL YOUR CODE, I > />/ > perfectly respect that, and I am also prepared to fulfill all your > />/ > suggestions to handle your code appropriately. > />/ > > />/ > On the other hand I would also like to point out that my main objective > />/ > is to develop a FREE and fully working application. My time is short (I > />/ > am developing Retrospectiva in my spare time) and I want to use it for > />/ > Retrospectiva and its users, instead of being hassled with legal stuff, > />/ > so I really hope for your understanding at this point. Now, if you feel > />/ > passed over in any way, tell me what to do (and how to achieve it), I am > />/ > sure we will find an excellent compromise, but please refrain from doing > />/ > following comments: > />/ > > I'm sad when people in the otherwise nice and respectful ruby- > />/ > > community can't deal with that. > />/ > These are libellous and there's really no reason to get rude. I would > />/ > like to have a constructive discussion instead. > />/ > > />/ > With best regards, > />/ > Dimitrij > />/ > _______________________________________________ > />/ > Collaboa-talk mailing list > />/ > Collaboa-talk at lists.collaboa.org > />/ > http://lists.collaboa.org/mailman/listinfo/collaboa-talk > />/ > > />/ > />/ > />/ -- > />/ christoph.sturm at gmail.com > />/ _______________________________________________ > />/ Collaboa-talk mailing list > />/ Collaboa-talk at lists.collaboa.org > />/ http://lists.collaboa.org/mailman/listinfo/collaboa-talk > />/ > /> From christoph.sturm at gmail.com Tue Dec 5 09:36:50 2006 From: christoph.sturm at gmail.com (Christoph Sturm) Date: Tue, 5 Dec 2006 15:36:50 +0100 Subject: [Retrospectiva-general] how to run the testsuite Message-ID: <11dae57c0612050636j2c9ad245q3d6dec3629d9fa64@mail.gmail.com> hey guys! in rails projects i normally run the test suite with just "rake". in collaboa this doesnt work and it looks like the test db doesnt get initialized. so how do i run it? thanks chris From contact at dvisionfactory.com Tue Dec 5 10:18:38 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Tue, 05 Dec 2006 15:18:38 +0000 Subject: [Retrospectiva-general] how to run the testsuite Message-ID: <45758DCE.4030600@dvisionfactory.com> I (currently) use (I am working on the integration tests. The functional tests will also follow soon): rake test:units Before that I use rake db:test:clone_structure to clone db structure from development to test If you do not have a development DB and want to clone from production DB use rake RAILS_ENV=production db:test:clone_structure instead. From christoph.sturm at gmail.com Tue Dec 5 10:35:58 2006 From: christoph.sturm at gmail.com (Christoph Sturm) Date: Tue, 5 Dec 2006 16:35:58 +0100 Subject: [Retrospectiva-general] user management Message-ID: <11dae57c0612050735m219bdadct2cd916c975e757ea@mail.gmail.com> Hey guys! i was thinking a bit about user management, and I would like to propose some changes / features: * let users register on the website. It would be great if users could just generate an account themselves, and use that to post on the wiki, file tickets, etc Maybe we need to implement user groups for that to work, but for now we could just create another user called "authenticated", and assign rights to it. Every user that registers on the site gets those rights then. the "submitted by" fields in tasks should then refer to a real user id instead of being just strings. We could then offer rss feeds with all tickets "reported by me" and "assigned to me". But the primary reason why I am proposing this is to get more community feedback on sites like retrospectiva.org. If all people that tried to install retrospectiva in the last days were able to just edit the wiki, they could fix stuff and write howtos there while installing. Its good that retrospectiva "eats its own dogfood", because so we can see directly on the retrospeciva.org site if something works or if it doesnt. And getting an easy way to let people edit the wiki would be a great thing. what do you guys think? regards chris From contact at dvisionfactory.com Tue Dec 5 11:11:17 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Tue, 05 Dec 2006 16:11:17 +0000 Subject: [Retrospectiva-general] user management Message-ID: <45759A25.9060306@dvisionfactory.com> I think it is a great idea, but we definitely need Groups/Roles for that. I plan all this for the 1.1 release, I already did a similar thing for another project and could easily reuse my code and knowledge for Retrospectiva. Currently I am very aware of implementing too many new features, because I really want to have a stable release first. By the way, the wiki is on retrospectiva.org is open to public. Feel free to write down your experiences, I would really appreciate that (and any other help). Cheers Dimitrij > Hey guys! > > i was thinking a bit about user management, and I would like to > propose some changes / features: > > * let users register on the website. > It would be great if users could just generate an account themselves, > and use that to post on the wiki, file tickets, etc > Maybe we need to implement user groups for that to work, but for now > we could just create another user called "authenticated", and assign > rights to it. Every user that registers on the site gets those rights > then. > the "submitted by" fields in tasks should then refer to a real user id > instead of being just strings. > We could then offer rss feeds with all tickets "reported by me" and > "assigned to me". > > But the primary reason why I am proposing this is to get more > community feedback on sites like retrospectiva.org. If all people that > tried to install retrospectiva in the last days were able to just edit > the wiki, they could fix stuff and write howtos there while > installing. > Its good that retrospectiva "eats its own dogfood", because so we can > see directly on the retrospeciva.org site if something works or if it > doesnt. > And getting an easy way to let people edit the wiki would be a great thing. > > what do you guys think? > > regards > chris From christoph.sturm at gmail.com Tue Dec 5 11:33:24 2006 From: christoph.sturm at gmail.com (Christoph Sturm) Date: Tue, 5 Dec 2006 17:33:24 +0100 Subject: [Retrospectiva-general] user management In-Reply-To: <45759A25.9060306@dvisionfactory.com> References: <45759A25.9060306@dvisionfactory.com> Message-ID: <11dae57c0612050833t22622c73nd8d2a62309c90667@mail.gmail.com> Hey dim! On 12/5/06, Dimitrij Denissenko wrote: > I think it is a great idea, but we definitely need Groups/Roles for > that. I plan all this for the 1.1 release, I already did a similar thing > for another project and could easily reuse my code and knowledge for > Retrospectiva. Currently I am very aware of implementing too many new > features, because I really want to have a stable release first. good point. but I think making the change now has also some benefits: After 1.0 people will start using retrospectiva and create a lot of data in their db, and we need to support migrating this data without data loss. if the tasks have no dependency to the user that created them, it will be difficult to construct this association once we support it. Thats why i would propose to make a light variant without user roles now for 1.0 * user can register themselves and * they get the rights of the public user (or we create another user called "default" that defines what rights users get by default) * registering is mandatory for creating tickets. and * tickets have a relationship to the user that submitted it. then it would also be possible to fix http://retrospectiva.org/ticket/23 I could work on this if you need help regards chris > > By the way, the wiki is on retrospectiva.org is open to public. Feel > free to write down your experiences, I would really appreciate that (and > any other help). > > Cheers > Dimitrij > > > Hey guys! > > > > i was thinking a bit about user management, and I would like to > > propose some changes / features: > > > > * let users register on the website. > > It would be great if users could just generate an account themselves, > > and use that to post on the wiki, file tickets, etc > > Maybe we need to implement user groups for that to work, but for now > > we could just create another user called "authenticated", and assign > > rights to it. Every user that registers on the site gets those rights > > then. > > the "submitted by" fields in tasks should then refer to a real user id > > instead of being just strings. > > We could then offer rss feeds with all tickets "reported by me" and > > "assigned to me". > > > > But the primary reason why I am proposing this is to get more > > community feedback on sites like retrospectiva.org. If all people that > > tried to install retrospectiva in the last days were able to just edit > > the wiki, they could fix stuff and write howtos there while > > installing. > > Its good that retrospectiva "eats its own dogfood", because so we can > > see directly on the retrospeciva.org site if something works or if it > > doesnt. > > And getting an easy way to let people edit the wiki would be a great thing. > > > > what do you guys think? > > > > regards > > chris > > > _______________________________________________ > Retrospectiva-general mailing list > Retrospectiva-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/retrospectiva-general > -- christoph.sturm at gmail.com From contact at dvisionfactory.com Tue Dec 5 12:33:35 2006 From: contact at dvisionfactory.com (Dimitrij Denissenko) Date: Tue, 05 Dec 2006 17:33:35 +0000 Subject: [Retrospectiva-general] user management References: 45759A25.9060306@dvisionfactory.com Message-ID: <4575AD6F.7060202@dvisionfactory.com> Hi! > After 1.0 people will start using retrospectiva and create a lot of > data in their db, and we need to support migrating this data without > data loss. if the tasks have no dependency to the user that created them, it will > be difficult to construct this association once we support it. > You are right! > Thats why i would propose to make a light variant without user roles now for 1.0 > > * user can register themselves > That shouldn't be a problem at all! > * they get the rights of the public user (or we create another user > called "default" that defines what rights users get by default) > That one is a bit tricky! I don't want to add another dummy user, so until we get a Group-Based permission system self-registered users will have the same rights as Public. > * registering is mandatory for creating tickets. > Hmmm .... that should be configurable. > * tickets have a relationship to the user that submitted it. I am already working on that! Cheers Dimitrij From jamie-list at tramchase.com Tue Dec 5 15:59:49 2006 From: jamie-list at tramchase.com (Jamie Wilkinson) Date: Tue, 5 Dec 2006 15:59:49 -0500 Subject: [Retrospectiva-general] Licence debate In-Reply-To: <45757723.20602@dvisionfactory.com> References: <45757723.20602@dvisionfactory.com> Message-ID: <599E3AD0-C0A6-46C1-9B4E-836504FCFC91@tramchase.com> Disclaimer: I am not a lawyer! All this largely derived from past experiences, please correct as you see fit :) (this is open-source after all) I am not personally a fan of the MIT & BSD licenses, which are only a small step away from being completely public domain. They simply require maintenance of the copyright notice, and the BSD license forbids using the author's name without permission. I am a fan of copyleft licenses mostly to predicate unsanctioned sale of the software or reuse of the code in commercial apps. Also it encourage contribution of code back to the project, or at least requires future forks to also be open source, keeping the app alive and open in one form of another. I prefer something like the Mozilla Public License over the GPL, though, but I think that's probably mostly psychological. From what I understand it is perfectly acceptable to include the MIT- licensed Collaboa code in Retrospectiva as long as the original license is re-printed in the applicable file's headers (regardless of how much code has been changed). GPL (or MPL, or whatever) could then be added to the files, providing some copyleft protection. Outside of legality it's really just giving credit where credit is due, and a quick cut & paste job (I would be happy to do it for you) 2c, -jamie On Dec 5, 2006, at 8:41 AM, Dimitrij Denissenko wrote: > Hi! > > First of all, thanks for your appreciation! I am sorry to tell you > that > this stupid licensing discussion, which is obviously my fault, since I > should have spent more time reflecting it, has already left its marks > (eg. I am not welcome at the Collaboa mailing list anymore), but > please > keep alway in mind, that I made Retrospectiva just within 4 > weekends, so > there was not much time for reflection. You (as well as Chis) are > absolutely right about my intentions: I just want to make a good piece > of software and I simply don't (didn't) care about all this licensing > stuff at all, I decided to use the GPL, basically just because I like > the idea of 'copyleft'. > > If everybody is suggesting to switch to the MIT, no problem, I will do > it, as long as it is a benefit for the project. As far as I can > see, it > IS actually the "easiest in this situation". > > Just a few more question to whom it may concern: > - As you might have noticed, I am not an expert on licensing at > all! So > does anybody see any negative impacts of "switching to MIT" for > Retrospectiva in the long run? > - Do you have any other helpful suggestions about license types > and models? > > Thanks > Dimitrij > >> Hi Dimitri. >> I just want to say, I think its great you are working on >> retrospectiva. >> Even tho it is a fork from collaboa their are bound to be lots of >> crossover/similar issues. >> I sincerley hope that this licensing issue doesn't leave any grudges. >> It does appear that if you don't care much about licensing the >> easiest thing >> to do would be to just use MIT, not that its best or anything, >> just that it >> might be easiest in this situation. >> In any case, thanks for releasing the work you have done for the >> rest of us >> to look at and use. >> ~Michael Fairchild >> >> On 12/4/06, Christoph Sturm > lists.collaboa.org/mailman/listinfo/collaboa-talk>> wrote: >>> / >> />/ hey dim! >> />/ >> />/ you should really try to understand johans points. What you >> are doing >> />/ right now is just violate his license. >> />/ >> />/ to fix that you must basically license retrospectiva under the >> MIT >> />/ license, and everywhere where you declare your copyright you >> must also >> />/ declare his. >> />/ >> />/ What i find a bit strange is that you insinst on using the gpl >> />/ licence, but also state that actually you dont really care about >> />/ licensing at all, and would prefer to spend your time coding. >> />/ >> />/ regards >> />/ chris >> />/ >> />/ On 12/3/06, Dimitrij Denissenko > > wrote: >> />/ > Dear Johan! >> />/ > >> />/ > Once again, it is NOT MY INTENTION to violate any licenses >> or to >> />/ > disrespect any previous work. Far from it, I would like to >> please >> />/ > everybody as good as it gets. I would strongly disagree that >> 95% of the >> />/ > code is yours, although the ideas (or names) may have not >> changes, the >> />/ > code has, I have reformulated almost every single line >> (except the >> />/ > views). Finally the number does not make any difference, >> either 10% or >> />/ > 95%, I agree, some code lines of Retrospectiva are STILL >> YOUR CODE, I >> />/ > perfectly respect that, and I am also prepared to fulfill >> all your >> />/ > suggestions to handle your code appropriately. >> />/ > >> />/ > On the other hand I would also like to point out that my >> main objective >> />/ > is to develop a FREE and fully working application. My time >> is short (I >> />/ > am developing Retrospectiva in my spare time) and I want to >> use it for >> />/ > Retrospectiva and its users, instead of being hassled with >> legal stuff, >> />/ > so I really hope for your understanding at this point. Now, >> if you feel >> />/ > passed over in any way, tell me what to do (and how to >> achieve it), I am >> />/ > sure we will find an excellent compromise, but please >> refrain from doing >> />/ > following comments: >> />/ > > I'm sad when people in the otherwise nice and respectful >> ruby- >> />/ > > community can't deal with that. >> />/ > These are libellous and there's really no reason to get >> rude. I would >> />/ > like to have a constructive discussion instead. >> />/ > >> />/ > With best regards, >> />/ > Dimitrij >> />/ > _______________________________________________ >> />/ > Collaboa-talk mailing list >> />/ > Collaboa-talk at lists.collaboa.org > lists.collaboa.org/mailman/listinfo/collaboa-talk> >> />/ > http://lists.collaboa.org/mailman/listinfo/collaboa-talk >> />/ > >> />/ >> />/ >> />/ -- >> />/ christoph.sturm at gmail.com > mailman/listinfo/collaboa-talk> >> />/ _______________________________________________ >> />/ Collaboa-talk mailing list >> />/ Collaboa-talk at lists.collaboa.org > mailman/listinfo/collaboa-talk> >> />/ http://lists.collaboa.org/mailman/listinfo/collaboa-talk >> />/ >> /> > > _______________________________________________ > Retrospectiva-general mailing list > Retrospectiva-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/retrospectiva-general