here are the plans Christoph Zwerschke and I came up with for future
development of the TG 1 branch.
Feel free to dicuss, give suggestions and comments!
Cheers, Chris
TurboGears 1.5 Planning
=======================
Team
----
- Ken Kuhlman
- Christoph Zwerschke
- Christopher Arndt
- who else?
Release manager role shared by Christoph Zwerschke and Chris Arndt
Project Infrastructure
----------------------
- Reclaim SVN repository?
- Migrate Trac and SVN to new server
- Separate tags/branches/trunk structure for TG1 and TG2
- Revive turbogears-trunk and make distinction between users and
development
mailing list clear.
Development Process
-------------------
- Commit to 1.5 branch and back-port to 1.1 branch
- Only backport to 1.0 branch if *really* necessary (ticket required).
- Use more branches
New Features
------------
- CP 3.1 support (Ken Kuhlmann)
- Genshi support for TG widgets (Christoph Zwerschke)
- (Start) Sphinx docs (Chris Arndt)
Refactoring
-----------
- make util module into a a package
- remove feeds package
- deprecate scheduler package
- reorganize quickstart templates (Chris Arndt, already started)
- database options loading
- lazy template engine loading (Chris Arndt)
Maybe:
- refactor commands package
- refactor i18n package (maybe replace with Babel?)
- rewrite test configuration loading
Plans
----
- TG 1.1.1 release in 2nd half of November (I have added a milestone
in Trac and started moving tickets into it)
- migration of TG Trac and SVN to dedicated server afterwards
- present development plans on mailing list (this is what you read
now)
- Start discussion about the relationship of TG 1 and TG2 and the
(poor) maintenance state of the TG2 branch.
- TG 1.5 alpha release planned for early January 2010
> - Ken Kuhlman > - Christoph Zwerschke > - Christopher Arndt > - who else?
> Release manager role shared by Christoph Zwerschke and Chris Arndt
> Project Infrastructure > ----------------------
> - Reclaim SVN repository? > - Migrate Trac and SVN to new server
Why is this necessary? Can't the 1.x branch stay where it is currently?
> - Separate tags/branches/trunk structure for TG1 and TG2
> - Revive turbogears-trunk and make distinction between users and > development mailing list clear.
What exactly needs revival? turbogears-trunk is alive and well AFAIK. Or you mean an ML that is dedicated to the 1.x branch?
> Development Process > -------------------
> - Commit to 1.5 branch and back-port to 1.1 branch
I'd say once 1.5 is out 1.1 users should be encouraged to migrate to it. Back-porting things is a pain and if everyone is told that they should use the latest stable release back-porting will not be so important. I have been using tg from 0.9 or so and have always upgraded to the latest stable release without lot of issues, now I'm at 1.1. If everyone does this we can save lot of time for you guys by not requiring back-ports.
> - Only backport to 1.0 branch if *really* necessary (ticket required).
I'd say this shouldn't happen and if people are made understand that this indeed is not a priority people will either be happy with the current 1.0 or migrate to 1.5 (once it's out).
> - CP 3.1 support (Ken Kuhlmann) > - Genshi support for TG widgets (Christoph Zwerschke) > - (Start) Sphinx docs (Chris Arndt)
> Refactoring > -----------
> - make util module into a a package > - remove feeds package > - deprecate scheduler package
Oh wait! And what should we use instead? I'm currently heavily relying on the scheduler module, but if there is a better alternative I'd be happy to migrate.
If this would make writing custom tg-admin commands easier, I'm all for it.
Cheers, Daniel
> - refactor i18n package (maybe replace with Babel?) > - rewrite test configuration loading
> Plans > ----
> - TG 1.1.1 release in 2nd half of November (I have added a milestone > in Trac and started moving tickets into it) > - migration of TG Trac and SVN to dedicated server afterwards > - present development plans on mailing list (this is what you read > now) > - Start discussion about the relationship of TG 1 and TG2 and the > (poor) maintenance state of the TG2 branch. > - TG 1.5 alpha release planned for early January 2010
On 4 Nov., 12:56, Daniel Fetchinson <fetchin...@googlemail.com> wrote:
> > - Migrate Trac and SVN to new server
> Why is this necessary? Can't the 1.x branch stay where it is currently?
It's just a new machine, the structure would remain the same. Further
SVN reorganization is another matter to be dicussed separately (e.g.
what should happen with the currently orphaned trunk?)
> > - Revive turbogears-trunk and make distinction between users and
> > development mailing list clear.
> What exactly needs revival? turbogears-trunk is alive and well AFAIK.
I don't think so. I have often posted questions or tried to discuss
sth on turbogears-trunk in the past months and didn't get any answers
or very little feedback. I get the impression that many devs do not
even read turbogears-trunk properly anymore. I also think we should
make a clear distinction between the main list for *users* of
TurboGears (i.e. people developing *with* TG) and turbogears-trunk for
TG developers (i.e. people developing/contributing *to* TG). It would
be better, IMHO, if the lists where called "turbogears-users" and
"turbogears-devel", but it would not be practical to change this at
this stage.
> Or you mean an ML that is dedicated to the 1.x branch?
That's another matter to consider. Should we have seperate mailing
lists for TG1 and TG2? for the moment, i think not. But we should
evaluate this again in a few months.
> > - Commit to 1.5 branch and back-port to 1.1 branch
> I'd say once 1.5 is out 1.1 users should be encouraged to migrate to
> it. Back-porting things is a pain...
I just meant to say, that commits should go to the TG 1.5 branch by
default now. But we need to maintain the 1.1 branch for a while, since
CP3 will introduce some changes, which makes porting your apps a
little bit more involved than a 1.0 -> 1.1 migration.
> > - Only backport to 1.0 branch if *really* necessary (ticket required).
> I'd say this shouldn't happen and if people are made understand that
> this indeed is not a priority people will either be happy with the
> current 1.0 or migrate to 1.5 (once it's out).
Yep, this is really only for important bug-fixes and security issues.
That's why there needs to be a ticket for every commit to the 1.0
branch, so the importance of the patch can be evaluated.
> > - deprecate scheduler package
> Oh wait! And what should we use instead?
It will be an external project. See my recent post on the trunk ml on
this topic (you DO read the trunk ml, do you? ;) ).
>> Why is this necessary? Can't the 1.x branch stay where it is currently?
> It's just a new machine, the structure would remain the same. Further > SVN reorganization is another matter to be dicussed separately (e.g. > what should happen with the currently orphaned trunk?)
>> > - Revive turbogears-trunk and make distinction between users and >> > development mailing list clear.
>> What exactly needs revival? turbogears-trunk is alive and well AFAIK.
> I don't think so. I have often posted questions or tried to discuss > sth on turbogears-trunk in the past months and didn't get any answers > or very little feedback. I get the impression that many devs do not > even read turbogears-trunk properly anymore. I also think we should > make a clear distinction between the main list for *users* of > TurboGears (i.e. people developing *with* TG) and turbogears-trunk for > TG developers (i.e. people developing/contributing *to* TG). It would > be better, IMHO, if the lists where called "turbogears-users" and > "turbogears-devel", but it would not be practical to change this at > this stage.
>> Or you mean an ML that is dedicated to the 1.x branch?
> That's another matter to consider. Should we have seperate mailing > lists for TG1 and TG2? for the moment, i think not. But we should > evaluate this again in a few months.
>> > - Commit to 1.5 branch and back-port to 1.1 branch
>> I'd say once 1.5 is out 1.1 users should be encouraged to migrate to >> it. Back-porting things is a pain...
> I just meant to say, that commits should go to the TG 1.5 branch by > default now. But we need to maintain the 1.1 branch for a while, since > CP3 will introduce some changes, which makes porting your apps a > little bit more involved than a 1.0 -> 1.1 migration.
>> > - Only backport to 1.0 branch if *really* necessary (ticket required).
>> I'd say this shouldn't happen and if people are made understand that >> this indeed is not a priority people will either be happy with the >> current 1.0 or migrate to 1.5 (once it's out).
> Yep, this is really only for important bug-fixes and security issues. > That's why there needs to be a ticket for every commit to the 1.0 > branch, so the importance of the patch can be evaluated.
>> > - deprecate scheduler package
>> Oh wait! And what should we use instead?
> It will be an external project. See my recent post on the trunk ml on > this topic (you DO read the trunk ml, do you? ;) ).
Yep, I did read that post :)
It was not clear from the item 'deprecate scheduler package' that you simply mean to replace the shipped tg scheduler module with this external one. This change would of course be fine!
> - refactor commands package
> - refactor i18n package (maybe replace with Babel?)
> - rewrite test configuration loading
> Plans
> ----
> - TG 1.1.1 release in 2nd half of November (I have added a milestone
> in Trac and started moving tickets into it)
> - migration of TG Trac and SVN to dedicated server afterwards
again why svn?
> - present development plans on mailing list (this is what you read
> now)
> - Start discussion about the relationship of TG 1 and TG2 and the
> (poor) maintenance state of the TG2 branch.
The 2.1 branch has had a ton of commits recently and the 2.0 branch is
in "maintenance mode" and 2.0.4 will come out only if a security
release is needed.
Thanks again for putting this together.. it's great!
On Wed, Nov 4, 2009 at 4:04 AM, Chris Arndt <chris.ar...@web.de> wrote: > Project Infrastructure > ----------------------
> - Reclaim SVN repository?
+1. TG2 isn't using the trunk, so it should be recycled back into the 1.x line.
> - Migrate Trac and SVN to new server > - Separate tags/branches/trunk structure for TG1 and TG2
> - Revive turbogears-trunk and make distinction between users and > development > mailing list clear.
+0 This was more important when the TG community was larger, but it's still a good idea. I doubt that we can put an end to chatter about alpha & pre-alpha releases on the user's list, though.
> Development Process > -------------------
> - Commit to 1.5 branch and back-port to 1.1 branch
Sweet. I'll post an updated diff between the branches to #1955 ("Ensure 1.1 changes get applied to 1.5") and then close it. (Just as soon as we get that test_json issue fixed).
- Only backport to 1.0 branch if *really* necessary (ticket required).
> - refactor commands package > - refactor i18n package (maybe replace with Babel?) > - rewrite test configuration loading
> Plans > ----
> - TG 1.1.1 release in 2nd half of November (I have added a milestone > in Trac and started moving tickets into it) > - migration of TG Trac and SVN to dedicated server afterwards > - present development plans on mailing list (this is what you read > now) > - Start discussion about the relationship of TG 1 and TG2 and the > (poor) maintenance state of the TG2 branch. > - TG 1.5 alpha release planned for early January 2010
+10.
Also, I don't think I'm going to make 1.5 for #1952 ("Backport RESTful dispatch"). Should I move it to 1.x?
>> - Genshi support for TG widgets (Christoph Zwerschke)
> why? isn't the long term goal to migrate to toscawidgets and eventually to tw2?
Sure. But one of the main reasons why people use the TG1 branch is that they do *not* want to migrate, because it is time consuming and error prone. I have projects which make heavy use of TG widgets; migrating them to TW/TW2 would be a major issue. If I did this, I could just as well migrate the whole app to TG2. And it's just incosistent that the default templating engine of TG>1.1 is Genshi, but widgets can only work with Kid. Using Genshi page templates with Kid based widgets also leads to some nasty compatibility issues: ET(...) needs to be called. This is done automatically in newer versions, but it's still ugly.
Independent from that, TG1 should of course also support TW/TW2.
On 5 Nov., 04:37, Jorge Vargas <jorge.var...@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 4:04 AM, Chris Arndt <chris.ar...@web.de> wrote:
> > - Reclaim SVN repository?
> > - Migrate Trac and SVN to new server
> > - Separate tags/branches/trunk structure for TG1 and TG2
> I believe it was agreed some time ago we'll migrate to mercurial, why
> go back to svn?
TG2 did the move. I don't suggest that TG2 move back to SVN, but I'am
against moving TG1 into hg anytime soon.
To be honest, I was never happy with the way the decision of migrating
TG2 to hg decision was made and I still don't see what advantages it
has brought. On the contrary, there exists considerable confusion now
where the official repo is (do the 2.0 docs even mention the hg
repository?) and it is poorly maintained (e.g. missing tags for
official releases).
> > - Revive turbogears-trunk and make distinction between users and
> > development mailing list clear.
> I do not think this need "reviving" simply a lot of discussion is
> currently happening on IRC.
IRC is not an optimal medium for development discussion, IMHO. It is
not archived properly, unstructured and hard to search. Ideally,
development discussion and decisions should be documented in the docs
or the ticket system, but a mailing list is the next best thing.
> > - migration of TG Trac and SVN to dedicated server afterwards
> again why svn?
See above.
> > - Start discussion about the relationship of TG 1 and TG2 and the
> > (poor) maintenance state of the TG2 branch.
- The 2.0.3 release is STILL not listed on PyPI.
- There are more than 30 tickets pertaining to TG2 on the turbogears
trac, which have not had a milestone assigned and it looks like they
are not being attended to
See http://trac.turbogears.org/query?status=!closed&group=version&milesto... I mentioned this several times on the mailing list, but nothing
happens.
> Are you still looking at the svn repository for this?
>>> - Genshi support for TG widgets (Christoph Zwerschke)
>> why? isn't the long term goal to migrate to toscawidgets and eventually to >> tw2?
> Sure. But one of the main reasons why people use the TG1 branch is that > they do *not* want to migrate, because it is time consuming and error > prone.
Exactly. I don't need tw/tw2 at all, I'm perfectly happy with tg widgets. Currently I'm using kid but I actually might migrate to genshi for performance reasons at which point genshi support for tg widgets would be great. But in the foreseeable future I'll be perfectly happy with kid and tg widgets as is.
Cheers, Daniel
> I have projects which make heavy use of TG widgets; migrating > them to TW/TW2 would be a major issue. If I did this, I could just as > well migrate the whole app to TG2. And it's just incosistent that the > default templating engine of TG>1.1 is Genshi, but widgets can only work > with Kid. Using Genshi page templates with Kid based widgets also leads > to some nasty compatibility issues: ET(...) needs to be called. This is > done automatically in newer versions, but it's still ugly.
> Independent from that, TG1 should of course also support TW/TW2.
>> > - Reclaim SVN repository? >> > - Migrate Trac and SVN to new server >> > - Separate tags/branches/trunk structure for TG1 and TG2
>> I believe it was agreed some time ago we'll migrate to mercurial, why >> go back to svn?
> TG2 did the move. I don't suggest that TG2 move back to SVN, but I'am > against moving TG1 into hg anytime soon.
> To be honest, I was never happy with the way the decision of migrating > TG2 to hg decision was made and I still don't see what advantages it > has brought. On the contrary, there exists considerable confusion now > where the official repo is (do the 2.0 docs even mention the hg > repository?) and it is poorly maintained (e.g. missing tags for > official releases).
>> > - Revive turbogears-trunk and make distinction between users and >> > development mailing list clear.
>> I do not think this need "reviving" simply a lot of discussion is >> currently happening on IRC.
> IRC is not an optimal medium for development discussion, IMHO. It is > not archived properly, unstructured and hard to search. Ideally, > development discussion and decisions should be documented in the docs > or the ticket system, but a mailing list is the next best thing.
+1 In an optimal world a large chunk of the development discussion happens on the mailing list. That way users who are interested in the development process (like me) have all the information they need in a simple archivable and searchable format.
> - The 2.0.3 release is STILL not listed on PyPI. > - There are more than 30 tickets pertaining to TG2 on the turbogears > trac, which have not had a milestone assigned and it looks like they > are not being attended to > See > http://trac.turbogears.org/query?status=!closed&group=version&milesto... > I mentioned this several times on the mailing list, but nothing > happens.
>> Are you still looking at the svn repository for this?
Ken Kuhlman wrote: > Also, I don't think I'm going to make 1.5 for #1952 ("Backport RESTful > dispatch"). Should I move it to 1.x?
Methinks no. Instead we should create a 1.5a1 release milestone and move tickets into it (one at a time), about which we are confident that we can resolve them before this release.
> IRC is not an optimal medium for development discussion, IMHO. It is > not archived properly, unstructured and hard to search. Ideally, > development discussion and decisions should be documented in the docs > or the ticket system, but a mailing list is the next best thing.
You are so right about this. For starters, I'm not even *allowed* to go to IRC at work. So from the about potentially 16-18h a day, I could only stay on IRC for about half of them. But then there is the issue of timezones, the fact that permanently following a chat in the hope of something interesting or relevant happening is massively distracting (to me at least), the interleaved discussions of others...
I don't mind the occasional IRC conference. But even that I can't guarantee to attend. Real Live and such.
And where are the results of those discussions you guys have? Can I read them? Can I comment on them? Can I *work* on them? No.
So I'm feeling I'm cut out of the development efforts. The public visibility of those is reduced, as no one can follow discussions and decisions by searching through ML or TRAC. Which might give the impression to others that the project isn't very much alive.
For me this resulted in not doing anything anymore, except fixing maybe concrete bugs I encounter when working with TG2.
The whole HG vs. Mercurial issue I also don't see as benefitial - but I can cope with it.
>> IRC is not an optimal medium for development discussion, IMHO. It is >> not archived properly, unstructured and hard to search. Ideally, >> development discussion and decisions should be documented in the docs >> or the ticket system, but a mailing list is the next best thing.
> You are so right about this. For starters, I'm not even *allowed* to go > to IRC at work. So from the about potentially 16-18h a day, I could only > stay on IRC for about half of them. But then there is the issue of > timezones, the fact that permanently following a chat in the hope of > something interesting or relevant happening is massively distracting (to > me at least), the interleaved discussions of others...
> I don't mind the occasional IRC conference. But even that I can't > guarantee to attend. Real Live and such.
> And where are the results of those discussions you guys have? Can I read > them? Can I comment on them? Can I *work* on them? No.
> So I'm feeling I'm cut out of the development efforts. The public > visibility of those is reduced, as no one can follow discussions and > decisions by searching through ML or TRAC. Which might give the > impression to others that the project isn't very much alive.
> For me this resulted in not doing anything anymore, except fixing maybe > concrete bugs I encounter when working with TG2.
> The whole HG vs. Mercurial issue I also don't see as benefitial - but I > can cope with it.
On Thu, Nov 5, 2009 at 2:39 AM, Chris Arndt <chris.ar...@web.de> wrote:
> On 5 Nov., 04:37, Jorge Vargas <jorge.var...@gmail.com> wrote:
>> On Wed, Nov 4, 2009 at 4:04 AM, Chris Arndt <chris.ar...@web.de> wrote:
>> > - Reclaim SVN repository?
>> > - Migrate Trac and SVN to new server
>> > - Separate tags/branches/trunk structure for TG1 and TG2
>> I believe it was agreed some time ago we'll migrate to mercurial, why
>> go back to svn?
> TG2 did the move. I don't suggest that TG2 move back to SVN, but I'am
> against moving TG1 into hg anytime soon.
I think this is one of those cases where this should be in trunk.
> To be honest, I was never happy with the way the decision of migrating
> TG2 to hg decision was made and I still don't see what advantages it
> has brought.
I'm sorry to heard that but everyone is very happy with it.
just look at
> On the contrary, there exists considerable confusion now
> where the official repo is (do the 2.0 docs even mention the hg
> repository?) and it is poorly maintained (e.g. missing tags for
> official releases).
The reason why the move isn't finished is because we are waiting on an
upgrade of the turbogers account to point hg.turbogears.org to it. Yet
again another topic not for the main list.
>> > - Revive turbogears-trunk and make distinction between users and
>> > development mailing list clear.
>> I do not think this need "reviving" simply a lot of discussion is
>> currently happening on IRC.
> IRC is not an optimal medium for development discussion, IMHO. It is
> not archived properly, unstructured and hard to search. Ideally,
> development discussion and decisions should be documented in the docs
> or the ticket system, but a mailing list is the next best thing.
It seems you all misinterpreted me on this, which probably means I
didn't explained myself correctly. I'm not saying we are going to
replace the ML with irc. I'm just saying a lot of discussion has
happen on IRC which reduced the traffic of the ML.
> - The 2.0.3 release is STILL not listed on PyPI.
yes, give me access to it and you will see it up thre in the next
couple of minutes.
> - There are more than 30 tickets pertaining to TG2 on the turbogears
> trac, which have not had a milestone assigned and it looks like they
> are not being attended to
> See http://trac.turbogears.org/query?status=!closed&group=version&milesto... > I mentioned this several times on the mailing list, but nothing
I'm sorry we are all busy people. I started going over your list the
first time you created it but I haven't had the time. I'l do my best
to go over it but remember we are all volunteers here.
>> IRC is not an optimal medium for development discussion, IMHO. It is
>> not archived properly, unstructured and hard to search. Ideally,
>> development discussion and decisions should be documented in the docs
>> or the ticket system, but a mailing list is the next best thing.
> You are so right about this. For starters, I'm not even *allowed* to go
> to IRC at work. So from the about potentially 16-18h a day, I could only
> stay on IRC for about half of them. But then there is the issue of
> timezones, the fact that permanently following a chat in the hope of
> something interesting or relevant happening is massively distracting (to
> me at least), the interleaved discussions of others...
> I don't mind the occasional IRC conference. But even that I can't
> guarantee to attend. Real Live and such.
> And where are the results of those discussions you guys have? Can I read
> them? Can I comment on them? Can I *work* on them? No.
I'm sorry all I said was that most of the support and bugfixes have
been moved there. All mayor changes had been discussed in the list.
I do agree with what you say and from my part I'm sorry we should
indeed use the ML more to report some bugs for everyone to see,
although other things are way better in a faster feedback channel. For
example the recent content-type bug will not be fixed if we didn't had
people on IRC discussing it.
> So I'm feeling I'm cut out of the development efforts. The public
> visibility of those is reduced, as no one can follow discussions and
> decisions by searching through ML or TRAC. Which might give the
> impression to others that the project isn't very much alive.
I don't agree with this. In the end progress equals code and the more
checkins you see the more active a project is. Yes ML and trac help
with the impression but a project that is getting tons of tickets is
not more active than a project that is getting tons of checkins.
> For me this resulted in not doing anything anymore, except fixing maybe
> concrete bugs I encounter when working with TG2.
> The whole HG vs. Mercurial issue I also don't see as benefitial - but I
> can cope with it.
On 17 Nov., 14:19, Jorge Vargas <jorge.var...@gmail.com> wrote:
> On Thu, Nov 5, 2009 at 2:39 AM, Chris Arndt <chris.ar...@web.de> wrote:
> > - The 2.0.3 release is STILL not listed on PyPI.
> yes, give me access to it and you will see it up thre in the next
> couple of minutes.
I didn't know that I am listed as a package maintainer for the
"TurboGears2" entry on PyPI, Florent must have added me while he was
adding me for the "TurboGears" entry. I'll add you as soon as I have
access to my PyPI login data. What is your PyPI account name?
> On Fri, Nov 6, 2009 at 3:01 AM, Diez B. Roggisch <de...@web.de> wrote:
> >> IRC is not an optimal medium for development discussion, IMHO. It is
> >> not archived properly, unstructured and hard to search. Ideally,
> >> development discussion and decisions should be documented in the docs
> >> or the ticket system, but a mailing list is the next best thing.
> > You are so right about this. For starters, I'm not even *allowed* to go
> > to IRC at work. So from the about potentially 16-18h a day, I could only
> > stay on IRC for about half of them. But then there is the issue of
> > timezones, the fact that permanently following a chat in the hope of
> > something interesting or relevant happening is massively distracting (to
> > me at least), the interleaved discussions of others...
> > I don't mind the occasional IRC conference. But even that I can't
> > guarantee to attend. Real Live and such.
> > And where are the results of those discussions you guys have? Can I read
> > them? Can I comment on them? Can I *work* on them? No.
> I'm sorry all I said was that most of the support and bugfixes have
> been moved there. All mayor changes had been discussed in the list.
Well, if people accept that IRC is the primary source of support - then mote it be. I hung out there the last couple of days in the evening, and nothing was really happening.
But to be honest: even for support, I'd prefer if people would give it on the ML.
Because there it is persistent, visible, and searchable, linkable. So IMHO those giving support there should consider moving that support over to the ML. Which I can't force anybody to do, but maybe the core devs and supporters can ponder this.
> I do agree with what you say and from my part I'm sorry we should
> indeed use the ML more to report some bugs for everyone to see,
> although other things are way better in a faster feedback channel. For
> example the recent content-type bug will not be fixed if we didn't had
> people on IRC discussing it.
These are two different things. Of course a fast channel of communication is benefitial in a concrete situation such as fixing a bug - I've done that numerous times with Florent over IM.
But for others to report and see if bugs are reported, IRC (or any other non-archived form of communcation) isn't the right thing. See above.
> > So I'm feeling I'm cut out of the development efforts. The public
> > visibility of those is reduced, as no one can follow discussions and
> > decisions by searching through ML or TRAC. Which might give the
> > impression to others that the project isn't very much alive.
> I don't agree with this. In the end progress equals code and the more
> checkins you see the more active a project is. Yes ML and trac help
> with the impression but a project that is getting tons of tickets is
> not more active than a project that is getting tons of checkins.
Where is that flurry of checkins happening? I don't *doubt* it - I just don't find it. Which might mean that I'm to stupid for the whole bitbucket/HG-thing, but when I look at
I see the last checkin being 4 months ago. If I'm supposed to look anywhere else, pray tell me. But please do *not* tell me that I've got to look at all forks. That they exist is of course perfectly fine - but frequent back-integration is crucial to prevent doubled or worse, conflicting work.
