On 09/18/2013 12:05 PM, Agustin Benito Bethencourt wrote:
Hi,
if you get bored of testing 13.1 Beta, do not hesitate in providing us feedback :-)
Hmm, what makes SUSE employees special? Are we more dense than other contributors or "those potentially interested in joining" that a document has to be created that is intended to "Explain the process to SUSE employees" ? SUSE employees that are already contributing should be involved in this discussion and provide feedback like everyone else, and those that are not, should not be singled out or receive special status from "those potentially interested in joining." If the language in the documentation suggests that there is a higher level of "citizenship" to be obtained by being a SUSE employee than we have wasted 5 years of effort in overcoming the perception that such a higher level of citizenship exists. It is nice that you decided to use EVTX, however, can you please point me to the thread on the factory mailing list where the pros and cons of this versus other processes was discussed? I must have missed the discussion as I do not recall the thread and taking a cursory look at the factory archives didn't make it immediately obvious which thread I should read. Thanks. What is WBS? Feedback should be given on a list, as is being done now. Having a private e-mail in the document encourages private feedback and thus the exclusion of the community, that's bad practice. The EVTX plan shows a roadmap and feature plan created by a Product Manager. As I pointed out in a previous reply to this thread, this is "directed development". Today the project and distribution grow organically, people implement the features they are interested in. If we want to change the model to directed development that will require a discussion in the developer community. The SUSE team is certainly free to follow a directed development model, however, without an open discussion I cannot see how the rest of the development community can be expected to buy into such a model. I for one am opposed to a directed development approach for the entire distribution. Further, the concept is flawed, as we have a large number of package maintainers that are not intimately involved with the upstream development project. Therefore, it is not possible for those maintainers to "Determine the new features". Whatever upstream produces, that's what we get. Even for projects where we are intimately involved, such as the kernel, pre-determining features is not possible. No one knows ahead of time what features will be in the kernel at what time, thus the exit condition of "Roadmap and Feature Planning" cannot be met. Unless we resign to making a plan based on things that are already released upstream (than we can determine the features), which implies that we will always ship "old" stuff. In case of 13.1 that would imply we'd be releasing with the 3.10 or even the 3.9 kernel (depending on timing of the planning process) instead of 3.11 and who wants a community distribution with an old kernel at release time? As far as package development and maintainership is concerned, a package maintainer needs to be able to decide whether her/his package goes to Factory or not, this is not the job/role of the devel project maintainer (T3.4). Lets look at an example. If I maintain package A in a devel project, but I do not want it in Factory than I should be able to have this arrangement. If the devel project maintainer decides that the package should be in Factory, than the devel project maintainer assigns additional work/responsibility to me, something I as a package maintainer will not be very fond off. Thus, the devel project maintainer that makes such decisions has to become co-maintainer of the package in question to take on the additional responsibility that comes along with having a package in Factory. With this step, i.e. becoming co-maintainer the package maintainer exercisers the decision about whether or not the package should be in Factory. Also x3.1 and T3.4 appear to be in contradiction. The entry for the "Review Process" matches T3.4, but does not match the exit condition X3.1 w.r.t. the role. It appears that in "Factory Integration" the tasks for feeding back changes from "The Factory Maintainer decides to fix an issue inside Factory" to the devel project are missing. Thanks for doing the work. However, not having had a discussion if we, as a whole, should have a directed development process it appears a bit pre-mature to have one documented. Of course as I mentioned above the SUSE team is always free to follow a directed development process for the work they do. We just have to sort out the implications/consequences of having part of the community follow a directed process while another part does not follow a directed process. How do we handle the cases where a community contributor not following the directed process submits a feature that is not in the directed plan. Will the feature(s) be considered and accepted, pretty much as it is today, or will they be rejected because it wasn't planned? Well a bit more than $0.02 worth. Later, Robert Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org