From: Alexander C. <ale...@gm...> - 2011-11-01 06:45:33
|
Hi Kurtis, Glad to see you clearly setting goals. Are you changing your workplace entirely or you plan to work part time here, part time there? Also few comments inline: On Tue, Nov 1, 2011 at 08:06, Kurtis Heimerl <khe...@cs...> wrote: > With that explained, I want to go into some specifics of my short-term plans: > > First, I'm going to discontinue most of the tarball releases. The > public release should be retrieved primarily through direct access to > the repository. This will keep me (and the other developers) honest, > as well as provide every user the best, most current release. Tarballs > will still be available for major releases, but that will mostly be > for archival purposes and not for most users. Tarball releases are very convenient if you're a newcomer and just want to get a first impression of the project. It's always easier to get a tarball then checkout a repo. Just don't put broken code into release tarballs (hello to broken P2.6 tarball). This is an established practice in open-source world I feel suspicious if I don't see tarballs with stable code releases. For me it's a red flag that project is in flux and I'd better not use it. > Secondly, this means the repository will no longer be used for active > development. Instead, only mature, TESTED patches will make it into > the repository. This is a shift from the internals of Range > development, and I hope I can keep it up. The repository is currently > in a very confused state, and the first big milestone is getting the > main repository into a better state. I believe it's a wrong model. Repository exist exactly for that purpose - to provide the most recent set of patches. The worst thing you could do is to introduce delay in merging changes into public release, because you need to test them. Testing may take a loooong time and this will introduce the same problems we had before. This it while community sometimes can test those patches of itself. Then, "non destructive patches only" is a great policy, but if Range developers are not used to it, you can't change it instantly. It's easier to circumvent it by smart use of branches. Just as an example -- if you want to keep trunk building and relatevely stable, you could introduce "rangenetworks" branch and merge changes to it first. When they mature you can merge them into the trunk. This is a normal flow of development, where you have a stable branch and a developers branch. E.g. look at GnuRadio with it's "next" branch. There are other choices, like explicitly marking trunk as "may be broken at any time" and having a separate "stable" branch. Just make it clear to everyone by defining a clear branching policy. > Thirdly, we need to have a similar model for the documentation. I've > been actively documenting a P2.8 install on the new wiki (second > ongoing milestone!). P2.8 needs to be easier to use; Range's > modifications, needed for their large-scale production, have made it > hard for small-scale operators and new users to make sense of the > system. I'll be adding scripts to simplify this process. I'd also like > to document ongoing projects that are using OpenBTS throughout the > world. That will require giving many users wiki access. I'll be doing > that. Using this occasion -- Ivan and I are still waiting for our accounts. And my question to David about moving information from the old wiki to its new place is still not answered. -- Regards, Alexander Chemeris. |