Laca, Thanks for the proposal. I think it would be great if people were to get more involved with bringing new programs into OpenSolaris, and your proposal sounds solid to me. +1
That said, there are a few internal processes that we normally have to go through in order to add new modules to Solaris. Some of these, I think, would have general value also to OpenSolaris. Perhaps we could expect some help with this from people in the community who agree to be module maintainers. I think the most useful process is the Open Source Review, where the module is given a look over by SunLegal to ensure that the licensing is compatible with the rest of OpenSolaris, etc. Questions include: - Do you intend to modify (through bug fixes, enhancements or otherwise) the open source technology? Briefly describe. "Apply bug fixes" is a standard minimal response. - Briefly describe the functionality provided by the open source technology? - Is the open source technology an implementation of an industry standard? Note that code that supports any proprietary software or hardware should be mentioned. For example, device support or support of a particular format, or a codec. - Without doing any research, are you aware of any patent or copyright lawsuits or claims relating to the open source technology? - What is the license? Provide the full text. - What is the abstraction layer between the code and the rest of the system? How is the code segregated from the rest of the system? For example, it is inappropriate to link non-GPL code into a GPL program. Explain any such issues. - Pointers to any documentation, websites, project home pages that should be used to reference the project. That doesn't seem like a burdensome amount of work to expect someone to do if they wish to be an OpenSolaris module maintainer. Perhaps we could set aside a spot on the OpenSolaris Wiki to store this information so it can be referenced and easy to put together. Helping with this work would be of great assistance to getting any modules into Nevada. Another process that is useful is the ARC (Architecture Review Committee) process, where we document and review module interfaces. To meet these requirements, I think what module maintainers could be expected to do is to be involved with ensuring that any module documentation (such as manpages or gtk-docs) is reviewed, accurate, and in good shape. This is more work for libraries which tend to expose many interfaces, and less work for applications which often do not. However, I'd say that the main way that module maintainers should be involved with their projects Brian > Some of us in the desktop team are looking into taking some > of the spec-files-extra packages and making them available > for OpenSolaris. I'd like to invite the people working on > SFE to work with us on these packages. > What we need to do is: > - make sure the spec file builds > - it's the latest available stable version > - works reasonably well > > Ideally, we need an owner for each package, who will look > after it: keeps it up-to-date, interfaces with the upstream > community (reports bugs and/or submits fixes). This > effectively means becoming the opensolaris maintainer of the > package. > > We will also need help with testing and filing bugs -- this > is far less commitment than maintaining a package. I suggest > we use the new opensolaris.org bugzilla for tracking bugs. > > I'll post an initial list of packages that are under > consideration shortly. To be officially part of opensolaris/ > indiana, all this needs to be done under the opensolaris > umbrella. We can do this in the JDS project or revive the > pkgbase project and use its svn repository. In any case, > people involved in this will need an opensolaris.org account > (if they don't have one yet). More details about svn access > will come later. This repository will have to be more > controlled than SFE but still easy to contribute to. > Again, I think the JDS/pkgbase approach of light-weight > code reviews should work just fine. The Desktop Release > Engineering team can do regular builds and the Desktop > QA team will do some testing. > > Currently the process for integrating into indiana is not > completely clear and not at all straight forward, unfortunately. > Since Sun is involved in producing the binaries, we need to > complete a lot of paperwork (legal reviews, etc) so things > take longer than we hope. We are working on making the process > smoother. The good news (for non-Sun people ;) is that this is > something Sun employees will have to look after, so you don't > need to worry about it. > > We will also need to complete ARC review. Again, this is > something that the JDS team will look after, but help is > appreciated (identifying imported and exported interfaces, etc.) > > As always, comments welcome. > > Laca > > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org
