Menu
▾
▴
naviserver-devel
|
From: Jeff R. <dv...@di...> - 2012-10-09 18:10:53
|
Hi all, I've exchanged correspondence with a number of people here but I'd like to extend a formal introduction - well, as formal as mailing lists get. I suspect most of the people on this list also read the aolserver list and have seen the recent interest in re-merging aolserver and naviserver development and community. I'm happy to be a part of this effort. I've only kept up with developments in naviserver intermittently, so I'm just now starting to learn and explore the differences. From what I can tell a lot of what I'd like to see in aolserver has already been done in naviserver. I have worked with aolserver for a while, mostly as a user and occasional patch-submitter / bugfixer, but only recently as an active developer. Other than what I've been doing, AOLserver has been seeing very little development. This, along with other unrelated considerations has led me to adopt some sloppy practices, notably a tendency to commit working but incomplete (i.e., poor style, documentation) changes earlier and clean up on later commits. While this has worked ok for me in the past, naviserver is a different, more active community and development style. I've already made a few missteps and been advised of commit guidelines, but I'm still learning what the preferred development style is (and also getting used to the quirks of mercurial). So then - what is the preferred style? Propose changes on the development list and then make changes to the main branch, make changes on a dev branch and merge after discussion, or create a private forked repository and merge changes in as patches/pull requests, or something else entirely. I'm happy to follow whatever the convention is, tho I certainly prefer to avoid additional administrative overhead and making changes in multiple places. I'm looking forward to working with everyone. -J |
|
From: Zoran V. <zv...@ar...> - 2012-10-09 18:49:42
|
On 09.10.2012, at 20:10, Jeff Rogers wrote: Hi Jeff! > Propose > changes on the development list and then make changes to the main This is how we have worked so far. This mostly covers bug fixes. Whole-sale changes are little bit different... but they happen seldom. In that case, a branch consisting of all the changes is prefered. In any case, we must see the changes *clearly* and everybody should be able to inspect and judge if this is potentially breaking something or heading in the "wrong" direction. What is "wrong" is difficult to tell... But people usually get the picture soon. Coding style is clear from the code and it follows the AOLserver and Tcl conventions mostly. We are very concerned about the stability. Some people here (including myself) use this code in commercial products which are mission-critial for many companies arround the world. Lots of effort and time has been invested in debugging, fixing races and memory leaks in the current Naviserver code. This does not mean we don't want any changes. On the contrary! But just that one has to be a little bit extra careful. I assume you know all this but it is good to repeat this every once in a while :-) Cheers, Zoran |
|
From: Stephen D. <sd...@gm...> - 2012-10-09 21:03:23
|
On Tue, Oct 9, 2012 at 7:49 PM, Zoran Vasiljevic <zv...@ar...> wrote: > > On 09.10.2012, at 20:10, Jeff Rogers wrote: > > Hi Jeff! > >> Propose >> changes on the development list and then make changes to the main > > This is how we have worked so far. This mostly covers bug fixes. > Whole-sale changes are little bit different... but they happen > seldom. In that case, a branch consisting of all the changes is > prefered. Conceptually yes, but don't actually use a mercurial branch for temporary development. You can't delete branches. On your local computer just clone an existing checkout into a new directory, it'll use hard links so it's fast and efficient. If you want to publish it for feedback then click the 'fork' button on the naviserver project at bitbucket and create a new repo under your own account: push your changes directly to it. If it's a small change, just post it here. Anyway, if you think of vc as backup and approval then it sounds like a drag, but it's really more like your editor - it helps you code. You often don't know what you're going to end up with when you start so you use your editor and hg to manipulate the code. - You start to add a feature but half way through you realise if you refactored some existing functions it would make the addition easier. - So, pop-off what you've done so far, refactor the code, push your pending changes back. - Then you notice a bug in some existing code. Pop off both changes, fix the bug, push them back on again. Now when you share the code there's 3 separate changes and they tell a story: here's a simple bug fix, here's a refactoring which should not change existing behaviour, and here's a new feature. The easier it is to read the more people are likely to read it and the more feedback you'll get, which is invaluable. In addition, everyone who touches the code end up with a mental model of how it works, so when the code changes the model needs to be synced up again. It's not scalable to have each person slog through a big old dump of code that took the original changer 6 hours to grok. You need to present it like a story so it makes sense. Check out the lkml to see how the ninjas do it. |
|
From: Gustaf N. <ne...@wu...> - 2012-10-10 06:57:46
|
On 09.10.12 23:02, Stephen Deasey wrote: > On Tue, Oct 9, 2012 at 7:49 PM, Zoran Vasiljevic <zv...@ar...> wrote: > >>> Propose >>> changes on the development list and then make changes to the main >> This is how we have worked so far. This mostly covers bug fixes. >> Whole-sale changes are little bit different... but they happen >> seldom. In that case, a branch consisting of all the changes is >> prefered. > Conceptually yes, but don't actually use a mercurial branch for > temporary development. You can't delete branches. > > On your local computer just clone an existing checkout into a new > directory, it'll use hard links so it's fast and efficient. If you > want to publish it for feedback then click the 'fork' button on the > naviserver project at bitbucket and create a new repo under your own > account: push your changes directly to it. If it's a small change, > just post it here. For larger changes (not just cleanup or fixes) feature branches are the best way. That works nicely and perfectly in our (git) developents, and keeps a change set focused to a topic (it's telling a story, as stephen said) while still being able to improve the change set. We have not used feature branches with hg/naviserver so far, but it seems certainly to be a good idea to start with this Bitbucket advertises the work via via pull requests prominently in its new web-design https://bitbucket.org/naviserver/naviserver/pull-requests Pull requests work with branches and forks https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests but it seems the approach with forks is better, since conceptually branches (mercurial calls it named branches) are in mercurial thought to be long-living: http://stackoverflow.com/questions/6357012/in-mercurial-how-do-i-merge-remove-a-feature-branch-so-i-can-commit -gustaf neumann |
|
From: Gustaf N. <ne...@wu...> - 2012-10-10 07:47:28
|
Dear all,
As our audience gets larger, i think it is important to
reiterate,
what is a common understanding in the naviserver community
(at least how i see it). While the basic attitude in the
aolserver community is backward looking (be as conservative
as possible, never change anything user-visible, even if this is
complete useless) the attitude of the naviserver community
is rather forward looking (clean up interface, improve the
way how
to handle problems, be competitive with other server
environments,
be among the best in terms of scalability, etc).
The need of doing things differently in some real-world
applications was the driver of the split of naviserver from
aolserver.
Forward-looking does certainly not mean that we do not want
to keep compatibility (we have all large code bases using
naviserver) but i would certainly hate to see e.g. the
useless $conn argument to be re-introduced in naviserver
just because some 10+ year old code expects it.
The general rule of change should be
major-versions-are-allowed-to-break-backward-compatibility
and
minor-versions-should-keep-backward-compatbility
where we are talking about intra-naviserver compatibility.
Not every change in the server has the same urgency
for every participant. For example Zoran has a very different
usage pattern for the server than we have, so several changes
important for us are effectively useless for him. But still,
there
is a nice long-going cooperation between the main stakeholders,
and the tradition of (although informal) code-reviews
works very well.
-gustaf neumann
|
|
From: Jeff R. <dv...@di...> - 2012-10-10 17:23:04
|
Gustaf Neumann wrote: > Forward-looking does certainly not mean that we do not want > to keep compatibility (we have all large code bases using > naviserver) but i would certainly hate to see e.g. the > useless $conn argument to be re-introduced in naviserver > just because some 10+ year old code expects it. > > The general rule of change should be > major-versions-are-allowed-to-break-backward-compatibility > and > minor-versions-should-keep-backward-compatbility > where we are talking about intra-naviserver compatibility. This is pretty standard and sensible for a project supported by volunteers. However, what I'd like to see - when reasonable - is an option for backwards compatibility, either by setting a config flag or loading a compatibility module, as nsshare appears to be shaping up into. Adding in a version of ns_register_filter that passes aolserver-style args would not be a stretch. This I think could give the best of both worlds - improvements in functionality without alienation of user base. -J |
|
From: Zoran V. <zv...@ar...> - 2012-10-10 19:03:14
|
On 10.10.2012, at 19:22, Jeff Rogers wrote: > This is pretty standard and sensible for a project supported by volunteers. > > However, what I'd like to see - when reasonable - is an option for > backwards compatibility, either by setting a config flag or loading a > compatibility module, as nsshare appears to be shaping up into. Adding > in a version of ns_register_filter that passes aolserver-style args > would not be a stretch. > > This I think could give the best of both worlds - improvements in > functionality without alienation of user base. > Sure. The key point is "where reasonable" :-) I guess this will always be a trade-off and thus generaly require some (more) discussion. But this is normal and we all are used to it. Cheers, Zoran |
Thanks for helping keep SourceForge clean.
X