Programmers: What are you currently working on?
Joe
I would like to start contributing to the development of Corsix TH by
implementing one of the features listed in Wiki's programming ideas
section, but I don't know which features are already being
implemented.
I think there should be a place where all the programmers can state
what they are working on. This would prevent the conflict, of two or
more programmers working separately on the same task.
I think there must be a better place to do this than a discussion
thread but this discussion thread could be used temporarily.
You could just make a brief post like the example below and edit the
post when the information in it needs to be updated:
I'm currently working on: A function which will cause an earth quake.
I began implementing this on: 20/2
I think this will be finished by: 1/3
Development Status: Finished
Joe
Stephen E. Baker
> Hi,
>
>
> I think there should be a place where all the programmers can state
> what they are working on. This would prevent the conflict, of two or
> more programmers working separately on the same task.
>
http://code.google.com/p/corsix-th/wiki/ProgrammingIdeas already has WIP
markers beside things people are working on. The only problem of
course is when developers go awol and don't update their status since
there are no timelines given.
I know for sure that Epidemics are being worked on.
William Gatens
John Pirie
> Hi,
>
> I would like to start contributing to the development of Corsix TH by
> implementing one of the features listed in Wiki's programming ideas
> section, but I don't know which features are already being
> implemented.
>
> I think there should be a place where all the programmers can state
> what they are working on. This would prevent the conflict, of two or
> more programmers working separately on the same task.
Yeah indeed, a better way to see what people are working on may be a
good addition. I would suggest something like the below.
At the moment it is the case that people are welcome to write patches
and submit them, at which point they are reviewed and added to the
repository by someone else who has access, and for any bugfixes a new
patch is created and sent in and so on. Unfortunately for larger patches
(such as the VIP patch), the code that I was writing was seen by only
me, and it was hard for other developers to tell what progress I was
making with this patch, or whether I had given up on it and was no
longer working on that feature. It also made it very difficult for two
contributers to work on the same code (they would need to create their
own copies of the repository which each other could push to, while
frequently pulling from the main repository).
The way I would suggest that we perhaps consider doing things is that
whenever someone wants to implement a feature, they e-mail the mailing
list and they are immediately given repository access and told to read
the set of programming guidelines that developers should follow, at
which point they can start committing code to the repository, and future
bugfixes will get into the repository faster which will allow for
further testing.
It would then be easy to see which features are being worked on by
simply looking at the svn logs, and using the datestamps see how long it
has been since a commit has been made, which will indicate whether that
developer has suddenly got busy and might want to hand off the job to
another developer to continue.
I think this might help stop scenarios of the kind that I'm in, where
two months ago I had earthquakes feature about 90% complete, but
suddenly got very busy and now I'm not sure what state the repository is
in and how easy it will be to merge things together. If I was able to
push this code to the repository at the time, my guess is someone else
could have picked this up and finished it within the same day and we
would have this feature working by now.
I also suspect such a design would help with multiple developers working
on one feature. As an example, it is my understanding that William is
currently working on epidemics which will eventually lead to the
programming of health inspectors, which are essentially VIPs but with a
few different features (multiple can visit, speed of movement no longer
constant, no longer looking at a list of rooms). It may be helpful to us
to be able to work on this section of the code at the same time, pulling
each others changes immediately to test how the code works together.
This sort of system is working well with some of the research projects
that I'm currently working on and it works pretty well for us. Naturally
if there are any problems with any particular person, we can just revert
the repository and remove their commit rights which is a simple process.
We use commit scripts to make sure the contributers reach a certain
standard (eg, they _must_ include a copyright statement), which I guess
would be an option for this project also (eg checking code indentation).
Just my 2 cents worth! ;-)
John
Joe
I'm embarrassed that I created this discussion now and I would like it
to be deleted.
On Feb 24, 3:24 pm, "Stephen E. Baker" <baker.stephe...@gmail.com>
wrote:
>
> > I think there should be a place where all the programmers can state
> > what they are working on. This would prevent the conflict, of two or
> > more programmers working separately on the same task.
>
Joe
I don't want this discussion to be deleted, now that 2 people have
taken the time to write 2 replies.
On Feb 24, 4:04 pm, Joe <j.sheppar...@gmail.com> wrote:
> I guess I should have thought about the meaning of the WIP acronym.
>
> I'm embarrassed that I created this discussion now and I would like it
> to be deleted.
>
> On Feb 24, 3:24 pm, "Stephen E. Baker" <baker.stephe...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > On 24/02/2012 10:06 AM, Joe wrote:> Hi,
>
> > > I think there should be a place where all the programmers can state
> > > what they are working on. This would prevent the conflict, of two or
> > > more programmers working separately on the same task.
>
Grimdoc
Nothing to be embarrassed about at all :)
Stephen E. Baker
I propose that if we take an approach like that feature branches are
used, then the people working on the feature could just be given
permission to work in that branch, and any breaking changes they
introduce won't affect the overall stability of the product. The
downside with feature branches is that someone will have to merge in
trunk changes every week or so.
Alternatives include switching to a distributed versioning system (e.g.
git), or using something like git-svn to manage your own changes and
collaborate, but ultimately send everything back to the svn repo.
Jørgen Tjernø
github: https://github.com/jorgenpt/corsix-th
I haven't checked it recently, but it still seems to work OK.
You can use it as a read-only copy if you dont want to futz with
git-svn. Great if you're authoring patches without commit permissions.
Kind regards,
Jørgen P. Tjernø.
(Sent using a touchscreen keyboard)
John Pirie
On 02/24/2012 04:19 PM, Stephen E. Baker wrote:
> How do you propose avoiding clobbering trunk with unfinished projects?
> I propose that if we take an approach like that feature branches are
> used, then the people working on the feature could just be given
> permission to work in that branch, and any breaking changes they
> introduce won't affect the overall stability of the product. The
> downside with feature branches is that someone will have to merge in
> trunk changes every week or so.
That seems like a sensible idea to me. My thoughts were that the code
would not execute unless accessed from the debug menu, so for example
for example for the VIP, the earthquakes, the epidemics and so on that
code wouldn't be executed on a timer (as it would be when the code was
stable), but such code was executed only when accessed through the debug
menu. As the code wouldn't be being executed, it shouldn't affect the
rest of the code (as long as it compiles, naturally).
That said, for some features this might be tricky so your idea of using
branches would perhaps be a better way to do this, then merging the
feature branches into the trunk could be done by some main admins once
the code is deemed to be of the right standard.
John
Edvin Linge
and at a certain standard (a subjective assessment of course) by letting
them submit a patch or two before giving direct access to the repository.
If anyone asks for direct permission I often grant it though, so ask on. :-)
I would suggest the branch approach for larger patches. Small bug fixes and
small enhancements can be added directly to the trunk while larger features,
refactoring or optimizations are first made in a branch. Then other
developers can try it out before the original creator can merge them
him-/herself.
The important thing is that the merges are made at some point... There is
for example a branch Corsix started on regarding the Action system. It never
got to the point of including it into the trunk, and now I wonder how much
time it would take to get it up to speed again.
At the moment the greatest "feature" still missing in my opinion is that
small objects such as radiators should occupy one side of a tile only.
/Edvin
Alex Bevilacqua
Lego3
(or me during the summer...)
I say that we start with using the programming ideas wiki page and try
to keep it updated, also with information who is doing it and when it
was started. If you want to edit it, just e-mail me and I'll add
permissions.
/Lego3