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. Massimo is doing his best to keep with the growing volume of
request. The question is: "design of new features is slowed by
bugfixing?"
Well I red from Massimo 2 alerts similar to the following (Massimo
feel free to correct me if I am wrong!!):
1. "Please remind me of patches to be applied"
2. "I need to keep track of messages, so no IRC"
Due to web2py success things will get worse, then I would suggest to
start focusing on 2 main points to see if we can find some
ideas/solutions.
1) version control
I perfectly understand Massimo position: dealing with mercurial
(git,bzr) is a pain! Anyhow we must help Massimo
delegate some dirty work to others, since we need Massimo to do the
important stuff.
I think that somehow Massimo's web2py problems resemble those that
Linus' Linux faced at the end of '90s. I just
remind that Linus to end the thing had written the git system!
Please take time to read this
chapter:http://hgbook.red-bean.com/read/collaborating-with-other-people.html
and
this:http://hgbook.red-bean.com/read/collaborating-with-other-people.html#...
The model for Linux development IMHO is too much at this time, but
some ideas should be taken into consideration.
2) issue tracking
We *must* setup a ticket system. Discussion on groups,IRC will
eventually lead to a new ticket, but *only* tickets must be
taken into account for bugfixing. Code snippets, error log, must be
tracked there.
ciao,
mic
2010/8/23 mart<msenecal...@gmail.com>:
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 can work with that, while hopefully
bringing something efficient, scalable and most certainly flexible,
while remaining respectful of what is important to Mr Di Pierro who
brought us all here.
Although I haven't spent too much time with Mercurial, most concepts
don't change, and implementation well... that's all it is really. I
had look @ your src repository and I find it is very telling of how
you do things and what is important. As I understand, the goal is to
meet 2 separate requirements that inevitably impact one another with
current structure. The desired outcome: no freeze of the code line
while allowing for planned testing iterations to move forward (while
enabling Mr Di Pierro to maintain those elements of the current model
which are important to him). I think it's entirely doable and please
don't hesitate to stop me if I get carried away... I would like to
start, if there are no objections, by getting a high level
understanding of current practices. So, I'll throw a few questions out
there. (I will try t keep the number of questions short – although it
may not appear that way). Perhaps, this could be taken to another area
to minimize the ruckus?
I like the idea of getting a group together and collaborate on
developing a proposal. As the more input we have, the better we can
serve this type of development model (the concept of contributors) in
the web2py dev world in particular. I see that Mr Di Pierro commits
all changes to the single branch (default).
Here's are a few questions with that:
Where do developers check-in or commit their changes while in
development?
Where does the src going to dev come from and at what frequency does
it get synced with the reference code line (if at all) ?
Is the reference code line stable (no changes) or is it in constant
flux?
Since Massimo, is doing the commits, I assume that everybody keeps a
sandbox copy of the src? Is there a mechanism in place which makes
sure that everyone is working off the same starting point? If not, how
are merge conflicts handled presently?
Does the code get reviewed before making its way to Massimo who will
be committing the changes (or not committing)?
As the “release guy”, my first and most important consumer of builds
is QA - the testers usually get first dibs on my time ;) - as they
are the ones blessing builds and enabling them to move to the next
levels. I tend to want to have them in mind when writing automation
and making sure they can interface as smoothly as possible to my
automation with there own.
When going to Test, what get's handed off (src or build)?
Is there any regular automated/manual testing? Or is it the case where
bigger testing efforts are done later in the release cycle?
how are builds identified with those test results?
Good release strategies do help, so here are just a few questions on
that subject:
Have you a defined plan for release strategies? (i.e. moving forward
between releases from 1.83.x to1.84.x, .... to 1.90.x etc.) - or are
releases treated as milestones?
milestone strategies within those releases?
how do you keep track of previous releases?
So, depending on the extent of adherence to release practices we want
to look at, there are many elements worthy of attention. I am ready
and willing to spend time in helping web2py plan and implement release
methodology (if that is desired) in line with your growth expectation
(which I can only imagine it being very high). What I can do to start
is setup a structure on Google (although i have noe clue yet what the
procedures are yet to get that going... a simple sign up?) and play
with a few ideas. So, where do we go from here, meaning how do we get
a group of interested people to join in?
I am open for discussion with anyone interested.
Thanks,
Mart :)
On Aug 22, 1:11 pm, mart<msenecal...@gmail.com> wrote:
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 :)
On Aug 22, 12:12 pm, mdipierro<mdipie...@cs.depaul.edu> 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
happy to use/incorporate a testing suite.
Massimo
On Aug 22, 10:57 am, Paul Gerrard<p...@gerrardconsulting.com> wrote:
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 Forum (uktmf.com) etc. etc. I am using Web2py to create a
test management tool that we will use to support our testing services.
(It's mainly for test design and record keeping in large software
projects, rather than test execution). So I am very interested in a
rock-solid Web2py as my company will depend on it :O)
Right now, I'm full-on writing code and testing as we launch in mid-
September. But I will be creating a performance/stress test for our
app as we'll be making a free subset of the functionality available on
our servers.Obviously scalability is a concenr for us. I'll probably
use The Grinder (http://grinder.sourceforge.net/) to stage these
tests, but that won't be for 5-7 weeks I think.
I'd be very interested in collaborating to create some form of test
automation regime for the Web2py infrastructure and applications using
either available tools or maybe writing our own framework. (I'm
looking to build an interface from my tool to things like Fit/Fitnesse
(or replace them) and Selenium as I focus very much on acceptance
testing). This might be the subject of another thread, perhaps.
Sorry for the length of this, but I thought I should declare my hand
and support for a 'stabilisation period'.
Paul.
On Aug 22, 2:25 pm, mdipierro<mdipie...@cs.depaul.edu> wrote:
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 model has worked well
for me and I would not like to change it.
I too am uneasy with the idea of freezing but not with the idea of a
testing period. How do you suggest we proceed?
Massimo
On Aug 22, 4:30 am, mart<msenecal...@gmail.com> wrote:
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
experience, freezing a code line is rarely beneficial, least of all to
the release going forward. So, was wondering if finding the correct
branching strategy (as well as defining an appropriately well matching
high level root folder structure in your source CSM) would help in
sorting out such things as separating out and
...
read more »- Hide quoted text -
- Show quoted text -
