From: Kurtis H. <khe...@cs...> - 2011-11-01 22:26:14
|
In thinking about the old wikis, it seems that writing stuff under the guest account and not providing any authorship comments probably counts as "de facto" waiving of publishing rights. So I guess it's ok to move stuff over as we see fit. On Tue, Nov 1, 2011 at 12:05 PM, Kurtis Heimerl <khe...@cs...> wrote: > On Tue, Nov 1, 2011 at 2:48 AM, Alexander Chemeris > <ale...@gm...> wrote: >> On Tue, Nov 1, 2011 at 12:35, Kurtis Heimerl <khe...@cs...> wrote: >>> Inline! >>> >>> On Mon, Oct 31, 2011 at 11:45 PM, Alexander Chemeris >>> <ale...@gm...> wrote: >>>> 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? >>> >>> I'm working part time, just 10/week. >>> >>>> >>>> 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. >>> >>> I see that perspective, but I know a few projects who use the >>> repository as the primary way to download the code. FreeSwitch is the >>> easiest example. It does imply that the project is in flux, but only >>> in the way that a project with active developers is in flux. That's a >>> good situation to me, shows that there are interested parties and work >>> being done. If you want to push back heavily here, we can see how the >>> rest of the community feels. >> >> This may be ok if there are some other signs that (1) project is alive >> and (2) project is stable. E.g. timely news about new releases on the >> front page with release history. The first thing I always do is that I >> check release schedule of a project to check whether it's alive. I bet >> I'm not alone. >> >> If I see no releases, I check commit logs, but even if I see some >> changes, I consider them as "developers playing with the code". I.e. >> nothing serious. Just because if people can't deliver and willing to >> play only, it's better to avoid such people. >> >> I hope my idea is clear enough. It's ok to live without tarballs IF >> there will be other signs that project is stable and alive. > > I think we'll give it a try. If there's any big pushback from the > users or the community, I'll go back to periodic tarball releases. > >> >>>>> 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. >>> >>> I should probably clarify. I will not be testing each patch coming in. >>> However, if someone commits something that obviously wasn't tested >>> (i.e., breaks the build), they will get called out for it, and if they >>> continue to do that their commit rights will be revoked. The >>> repository is NOT the place for active development efforts. This may >>> be a religious issue. As far as the range culture clash, I think it >>> won't be a big deal. They will not be committing much code directly >>> into the repository, I will. >>> >>> In general, development branches should be committed locally using >>> git-svn. I'm going to explicitly recommend git-svn for any developers >>> for this reason. When they are mature enough for mainline (and tested) >>> we'll do the merge. >> >> This procedure is not yet completely clear for me, but looks ok at the >> first look. I'll wait for the more detailed description form you. >> >>>>> 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. >>>> >>> >>> This is absolutely something I need to do and have been given rights >>> to do so. I'm also going to document that people should contact me >>> directly for wiki access. I'll get on that tomorrow! Please harass me >>> constantly if I drop this ball. Making it easier for people to >>> document is obviously better for everyone involved. >> >> Thanks! >> >>> As far as the old wiki, I think there may be potential IP issues range >>> is scared of. Basically, they're pretty paranoid about getting sued >>> after that one time they got sued. I think it's best if we don't copy >>> stuff directly over from the old wiki. David can comment if he has a >>> different opinion. >> >> What exactly those IP issues are? >> Most of the text there is written by well known authors (including >> David himself) and it's straightforward to ask their permission to >> copy it. >> If this is not an issues, then I do not understand what is it? > > It's slightly worse than that I think. I can't find the license for > the old wiki, but let's assume it's CC at the worst. That, coupled > with the fact that most authors wrote stuff with the "guest" account, > means that we have no idea what the authorship and rights for > individual pages are. > > I'd love to be wrong here, as then I have to write a lot less wiki. > >> >> -- >> Regards, >> Alexander Chemeris. >> > |