Web Site Infrastructure Discussion

Discussion about using a project management tool like Redmine. Would likely replace bugzilla, and some wiki functionality. It seems likely the main OE web site would remain in mediawiki.

Redmine

Benefits/Losses

• Benefits
  • easy to automatically reference issues from commits: refs #123
  • easy to close issues from commits: closes #123
  • everything is in one place, milestones, tickets, wiki, and it is easy to cross reference everything. With everything in one place, it is more likely that all the tools will get used.
  • one place to look for all project activity, Issue changes, wiki edits, source code changes, etc
  • very good multiple project support
  • additional features such as news, roadmap, etc.
• Losses
  • Redmine does not have a concept of workflow in tickets (not sure we use this anyway)
  • what to do with the wiki? With two wikis, it is very clumsy to have stuff in two places.
  • spam protection, security. Mediawiki and bugzilla are robust apps. Redmine is relatively new.
  • bug linking, example: http://bugs.openembedded.net/show_bug.cgi?id=3591
• To think about
  • Redmine is geared toward "projects" where everyone is working toward the same goal. OSS projects typically involve a lot of people with different goals. Would there be any benefit to integration?
  • would roadmap planning help us set goals for the next release and get more people working toward common goals? As OE is combination of many things, I'm not sure this is applicable.

IRC Discussion

That started this.

07:21 < zecke> cbrake: do you use the accounting part of it?
07:21 < otavio> accounting of what?
07:21 < cbrake> zecke: I use the time estimation part, percent done, but I don't log time on task.
07:22 < otavio> ah
07:22 < cbrake> zecke: my needs are primarialy to estimate remaining work on a project.
07:22 < otavio> cbrake: same here
07:22 < otavio> cbrake: we don't use the time planning
07:22 < otavio> cbrake: but few internal projects, when we hire external consultants, we use
07:23 < zecke> cbrake: yes, that is good enough. Do you manage to update this information? Or, is your busines context forcing you to update it anyway?
07:23 < cbrake> zecke: the Gantt chart stuff is pretty elementary, but is still fairly useful for mapping out tasks on a weekly basis
07:24 < cbrake> zecke: not sure I understand your question
07:25 < zecke> cbrake: The issue most of the time is updating the information once the project is going
07:25 < zecke> cbrake: combining this with the fact that humans are lazy, most projects I know stop the book keeping... so how easy is it to keep the
               information up to date?
07:26 < cbrake> zecke: yes thats a problem to keep up to date, and I'm as lazy as the next :-)
07:26 < cbrake> zecke: but redmine is the least painful method I've found so far -- UI is excellent.  Even small things like back arrow is truely back
                instead of the last for change, etc.
07:27 < cbrake> zecke: I do other things that help me like record every commit in a ticket (redmine can do some of this automatically), but it forces me to
                look at tickets often, and keep everything up to date.
07:28 < cbrake> zecke: that is probably the most useful process I've found yet -- every commit references a ticket, and the ticket lists all changsets.
07:29 < cbrake> zecke: its tough to get people to buy into that, but when they do, it really works well.
07:30 < Crofton|work> gm
07:31 < CIA-5> Koen Kooi <koen@openembedded.org> org.openembedded.dev * rd74bc04b79 openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder:
               add geda
07:34 < CIA-5> Koen Kooi <koen@openembedded.org> org.openembedded.dev * rf0678db614 openembedded.git/packages/xorg-xserver/ (xorg-xserver-common.inc
               xserver-xorg_1.5.3.bb): xserver xorg: split of Xfbdev to make it parallel installable with kdrive
07:35 < otavio> cbrake: and it is quite easy to close a ticket too; using commits. That is very helpful too :-)
07:36 < otavio> zecke: redmine does a great job and is much more active then trac and other alternatives.
07:36 < otavio> zecke: even though trac still has a larger installed  basic, redmine has evolved fastly
07:37 < cbrake> otavio: interesting, I'll have to get that working
07:38 < otavio> cbrake: same place where you adds refs, there is a place to add the closes and other words to be used to close  a ticket.
07:39 < otavio> cbrake: it is quite easy
07:41 < cbrake> otavio: ok, I see that.  So is the sytax simply: closes 342
07:41 < cbrake> otavio: what is "plugonrails" ?
07:42 < Crofton|work> you guys aren't thinking we should use this for OE?
07:43  * Crofton|work really likes the idea, but isn't sure how well it would in practice for a large diverse group
07:43 < otavio> cbrake: closes #342
07:43 < otavio> cbrake: it is a place where we put our internal plugins to others to use
07:43 < cbrake> Crofton|work: I'm not sure it would add much value to OE.  I'm more talking in the context of smaller, commercial projects
07:43 < Crofton|work> yeah
07:43 < otavio> cbrake: we use rails for our client painel
07:44  * Crofton|work thinks OE might benefit from it, but implementation would be challenging
07:45 < cbrake> Crofton|work: one of the challenges with commercial projects is they move fast, and there has to be close teamwork and high visibility to
                build trust.  Redmine helps build this.  It seems like OSS projects are somewhat different.
07:46 < cbrake> * perhaps transparency is a better word
07:46 < Crofton|work> similar but different
07:46 < Crofton|work> on commercial projects everyone has the same goal
07:46 < cbrake> with OSS projects, there is by default transparency, where with commercial projects its often very difficult to achive this
07:47 < Crofton|work> on OSS projects there are different goals for each participant
07:47 < cbrake> nod
07:48 < zecke> pb_: ping
07:48 < otavio> right but different goals doesn't means we shouldn't have a milestone, bug tracking, bug assignation and like
07:49 < otavio> and bugzilla makes it somewhat boring, while new tools (redmine included) makes it easier and neat
07:49 < Crofton|work> otavio, agreed
07:50 < Crofton|work> bugzilla is very good at managing bugs
07:50 < cbrake> otavio: interesting point
07:51 < cbrake> media wiki and bugzilla are obviously more capable as stand-alone tools, so the question is the integration of the tools worth more than the
                features we would lose?
07:51 < Crofton|work> I really like having good history (beyond commit messages) for all commits, but I have been accused of being a control freak at times
                      :)
07:51 < otavio> cbrake: I believe it is worth
07:52 < otavio> cbrake: I never like bugzilla mostly because it doesn't help to track project improvement. It just track issues
07:52 < otavio> cbrake: a project is more the issues ...
07:53 < otavio> cbrake: and redmine, trac and others make all this integrated. It is easy to find what is needed to be done
07:54 < otavio> cbrake: I dislike media wiki and bugzilla and prefer a integrated and a single environment for all this.
07:54 < otavio> cbrake: this also makes easier to write supporting tools to integrate with it
07:56 < Crofton|work> I have seen good rsults with people using trac
07:56 < cbrake> otavio: I think I agree, and I've had lots of good experience using trac/redmine.
07:56 < Crofton|work> but any tool system is only as good as it users
07:56 < Crofton|work> do you knwo a good redmine example?
07:57 < cbrake> well, why don't we paste this discussion on a wiki page, and start listing pluses/minuses and see what everyone else thinks.
07:57  * Crofton|work was going to say post to the list, but maybe trying to flesh the ideas out on a wiki page would be good
07:58 < cbrake> I think we need a clear list of benefits and losses.
08:01 < Crofton|work> yeah