Sounds good, then Massimo it is :) I can setup a proposed branching
structure with a clone of the latest code line (where hopefully folks
will jump in and throw rocks at it so it modified if needed to better
resolve initial issue). I can also look into into the Google-2-
mercurial API and see where
I'll take a patch to improve admin with the suggested changes.
Massimo
p.s. Call me Massimo. My students usually do so too.
On Aug 29, 12:48 am, mart wrote:
> Good idea! Would be awsome! Probably a bug tracking system should be
> still need to be added though, for a few reasons (just my opinion
Good idea! Would be awsome! Probably a bug tracking system should be
still need to be added though, for a few reasons (just my opinion
though). If we go back to the root issue of the thread (or rather what
turned out to be the defining issue to resolve), 2 separate things
seem have been deemed as "
That way
1) Encourage users more into web2py group
2) Users can just jump into conversation and work onto bug fixes too.
3) If thers google api which allows user to login and post directly to
google group , users can submit bug/questions directly there via
admin.
On 8/28/10, Phyo Arkar wrote:
>
sorry i mean
Put subject Tagged [web2py] [bug] at the top of the list?
On 8/28/10, Phyo Arkar wrote:
> regarding bug-tracking , i have a very simple idea.
>
> how about , before we develop the bug-tracking system , at app admin ,
> add a side box , just like
> web2py Recent Tweets box , add
> we
regarding bug-tracking , i have a very simple idea.
how about , before we develop the bug-tracking system , at app admin ,
add a side box , just like
web2py Recent Tweets box , add
web2py Google Group box ?
Is there Google Group api which can get all the list of subjects? and
put subject tagged [
I'm thinking a few possibilities...
we can, as a possible option, give folks the opportunity to either
register there install of web2py with additional user registration
option (depending of your philosophy wrt that) - which could also
serve as tracking mechanism to encourage people to keep up wit
This is reasonable but how to check?
On Aug 26, 6:18 pm, mart wrote:
> Interesting point... How about bugs can only be "truly submitted" if
> user is registered in web2py user group? Can we up authentication
> detail for users (if required)... True that it could be scary that
> folks start loggi
Interesting point... How about bugs can only be "truly submitted" if
user is registered in web2py user group? Can we up authentication
detail for users (if required)... True that it could be scary that
folks start logging bugs left and right... If part of user group,
would this only generate same a
some thoughts...
Firstly it is important that tickets reach their fate (closed, wont
fix, cant fix, not a bug, whatever ) soon, otherwise
it would be worst than people writing for bugs already fixed. You can
see many projects that have 3 year old tickets...
This means that some individuals should
good plan! Do you have people dedicated to test purposes for the
monitoring help? Were you thinking on a something like a 2 tier
filtering system? first level bug validation (is this really a new
bug?) as automated filtering & second: trusted testers/dev folks who
can best help in filtering and pas
I am in favor of both proposals
1) user google code more
2) having a bug tracking application
but
- I would like some help in monitoring this list and opening bugs on
google code when a new bug is suggested on the list. This is because I
do not want to have to explain to new users how to open goo
LOL :) I still vote for you ;) But meanwhile... had a little fun with
google code and created a project (which i will soon obliterate - its
my attemps at making a wewb2py app which is most likely broken ;)).
But regardless... I had the worst time using 'hg' ... feels a little
like "no sense of cont
I was thinking why not Mart?! ;-)
There is no need to rush. I would wait for more feedback and Massimo
ideas on this, in the midtime we can use googlecode better,
while *eventually* starting a web2py centric bugtracker...
2010/8/25 mart :
> What a great thing! Now we just need to define requirem
What a great thing! Now we just need to define requirements... Someone
should lead this to avoid problems... (N cooks in one kitchen where N
should = 1) Michele is it? :)
Mart :)
On Aug 25, 1:52 pm, Michele Comitini
wrote:
> *plugin_wiki* could be used as a basis for this eventual bugtraker?
>
*plugin_wiki* could be used as a basis for this eventual bugtraker?
2010/8/25 mart :
> yes, in any bug tracking system, "work on bug" data is provided by
> assigned dev user (status/fix description/fix available in build X/
> etc.).
>
> Mart :)
>
>
> On Aug 25, 1:23 pm, Alexandre Andrade
> wrote
yes, in any bug tracking system, "work on bug" data is provided by
assigned dev user (status/fix description/fix available in build X/
etc.).
Mart :)
On Aug 25, 1:23 pm, Alexandre Andrade
wrote:
> Since we can se the web2py tickets as bugs (of our apps), its be nice to
> incorporate a managemen
Since we can se the web2py tickets as bugs (of our apps), its be nice to
incorporate a management of this tickets, not only registering them.
2010/8/25 mart
> bug tracking app is available on web2py.com? I think opening a bug
> should be the first that happens possible to add validation co
bug tracking app is available on web2py.com? I think opening a bug
should be the first that happens possible to add validation code
within the bug tracking as a first layer filter (is this /or hast this
ever been a bug ?) or... perhaps an easy way for users for query the
db.bug_history (perhaps
Point 2) is nice for all of us because you (Massimo) are very quick,
but how much does take off of your web2py time?
Would not be better to open the ticket before testing and eventually
close it as "works for me"?
This way someone among the developers could take care of the ticket
and test it, if
Good morning!
You must be so busy! But from what you are saying the process is
pretty much straight forward and you already have a good delivery
system (downloads on web2py.com). If we expand a little on that, we
may be able to settle a few issues quickly enough.
1. Michele's idea is perfect here
we do use googlecode for not. Here is the current (imperfect) process:
1) people post a question about a possible bug
2) somebody checks that it is a bug, usually me
3) if the bug does not get fixed in 24h, the original poster opens a
googlecode ticket
4) when the bug is fixed the ticket is closed
Yeah, thanks for the tip :) Above was really a question of
disagreement with that workingDirectory -> branch thing, simply
because IMHO, branches should be planned and managed following set
criteria and purpose (again that's just me). Of course, there are many
possible avenues, and it is possible I
Actually I would like to ask if bug tracking is used on web2py?
Code is available from either (btw Massimo how do you keep those 2 in
sync? just too curious :-) ):
a) googlecode (with hg)
b) launchpad (with bzr)
both have some sort of bugtracking ticket system I do not know which
one is best (or
On Aug 24, 2010, at 11:29 AM, mart wrote:
> Well, this is all interesting :) After reading Michele's email, I just
> had to spend hours looking at Mercurial (& the like) as deeply as the
> day would let me (I'm on PTO, so I can do this). I thought I had a
> good idea about "distributed" version co
Well, this is all interesting :) After reading Michele's email, I just
had to spend hours looking at Mercurial (& the like) as deeply as the
day would let me (I'm on PTO, so I can do this). I thought I had a
good idea about "distributed" version control system but, as it turns
out, a few surprises
Hello Paul,
I´d be happy helping putting up a Linux box for web2py. I use CentOS as
my distribution, but if needed it should not be a big problem setting it
up on Ubuntu either.
Kenneth
Hi all,
Sounds like there's a little momentum in this :-)
Here's what I can contribute to the party:
Hi all,
Sounds like there's a little momentum in this :-)
Here's what I can contribute to the party:
1. Part of the test management tool I am writing is a 'case
management' facility. It is basic, but it supports multiple case
types. Cases can be issues/incidents/defects, to do/actions, and
notif
Hi all,
I do develomplent with many different things, different languages
architectures and looking for tools for managing software projects is
a must for me
;-)
I think the "problem" here is that web2py has started to receive the
deserved attention by the user and developer community.
Prof. Mas
Hi Again,
So, spending the day with my 3 girls certainly does provide
perspective on requirements and how well attached we can be to them
sometimes ;). That in mind, I certainly do understand your personal
requirements on keeping what you know and what works for you (I
respect old fashion ;) ). We
This is sounding like fun! My experience is mostly with Adobe (10
years) working with cross-continent & distributed dev efforts. So,
getting the chance to work with the great folks from web2py on a
"contribution model" (for the lack of a better term) sounds real
exciting to me! :)
thanks,
Mart :)
sounds good :) i will think about a few things and get to you later
today
thanks
Mart :)
On Aug 22, 12:12 pm, mdipierro wrote:
> I propose the people most competent and interested in this subject
> form a team to work on it.
> Call for help, setup a mailing list and an IRC channel. I will be
> h
I propose the people most competent and interested in this subject
form a team to work on it.
Call for help, setup a mailing list and an IRC channel. I will be
happy to use/incorporate a testing suite.
Massimo
On Aug 22, 10:57 am, Paul Gerrard wrote:
> Hi All,
>
> Like Mart - I'd better declare
Hi All,
Like Mart - I'd better declare an interest and some knowledge in this
area.
My company is Gerrard Consulting (www.gerrardconsulting.com) I'm very
active in the UK and European testing community and have written a
couple of books, done lots of conference work, host the UK Test
Management F
Dear Mart,
Your help is very much appreciated. In particular because I am not
very knowledgeable about this aspect.
I am old fashion and for me the less I use mercurial the better. For
example I keep one single branch of web2py. I simply apply patches,
test them, and either revert or commit. This
Good evening all,
I hope no one takes offense by me jumping in, but I couldn't help
myself as the thread's subject got my attention (release management is
what I do). If you'll allow me, I'm just curious as to the narure of
your current branching strategy wrt the subject of the thread? In my
exper
>
> I think whatever solution we find, Massimo needs to be relieved and
> not aggravated with more tasks :D
>
Yeah thats true , but all the bug hunting , stress and stability testes
should be focused by us(community)
On Sun, Aug 22, 2010 at 1:45 AM, Michele Comitini <
michele.comit...@gmail.com>
What about defining some milestones where new features are assigned?
Once a milestone completes freeze and branch on that branch bug
squeezing is done and tags for stable releases.
Meanwhile the trunk starts traveling to the next milestone.
I think whatever solution we find, Massimo needs to be re
So thats mean during 1.84.1 - 1.95.1 new features which will need a patch to
web2py-core will be freezed and those wont need to touch web2py-core will be
put into experimental?
On Sat, Aug 21, 2010 at 11:44 PM, mdipierro wrote:
> How about we start testing with 1.84.1... and release 1.95.1 and t
How about we start testing with 1.84.1... and release 1.95.1 and the
end of the testing period?
On Aug 21, 12:00 pm, Phyo Arkar wrote:
> > I think so, as long as the terms are clear. In particular, it should be
> > clear how the experimental features would move to stable (perhaps just a
> > time
>
> I think so, as long as the terms are clear. In particular, it should be
> clear how the experimental features would move to stable (perhaps just a
> time limit on the stress test, or some more specific condition).
>
how about this?
Lets say , during 4 weeks of bug-squishing period , all exper
On Aug 20, 2010, at 2:40 PM, mdipierro wrote:
> I see a lot of value in
>
> - bug-squishing-contest ,
> - Stress test, Test everything , try to crash web2py etc.
> - fix bugs, fix performance issues , improve performance
> - code cleanup , documentation.
>
> we can set deadlines for that. This m
So we could do this for 1.84, the next release. If sombody is about to
submit a major patch let me know and we will wait for that.
On Aug 21, 4:55 am, Phyo Arkar wrote:
> thats good.
>
> also what i saw at ipython mailing list , when they go into feature freeze ,
> they call for all contributors
thats good.
also what i saw at ipython mailing list , when they go into feature freeze ,
they call for all contributors / plugin contributors for bug-squishing and
stabillity fixes .Contributors of New features are asked if their works
confident to included the stuff into main stable release.
On
yes and no.
For example Michele just send me a new gluon/contrib/login_methods/
oauth10_account.py which provides OAuth 1.0 authentication. It did not
affect anything else in web2py and I see no reason from freezing
adding features like this.
Mariano is working on a PDF library for web2py. Same ar
45 matches
Mail list logo
