meeting minutes: openSUSE allhands meeting 2005-12-14
openSUSE allhands meeting 2005-12-14 disclaimer: The following document covers a meeting of the openSUSE team. It summarizes expectations, concerns, ideas and opportunities around the openSUSE project. It is a rough collection of bits and pieces, neither complete nor final. Please note that these meeting minutes do not reflect any official Novell statement or any binding roadmap or schedule. It is open for discussion and improvement and reflects solely the ideas and opinion of the individual participants. present: aj, holgi, hvogel, mlasars, freitag, cthiel, jw, skh, mls, fs, bg, mruewckert, sp, froh missing: michl, adrian, cschum Minutes: jw, sp TOPICS 1) Chances 2) Risks 3) Expectations 4) Discussion - (Hosting, Rear Cover, Communication, Provo, Force, Workload) 5) Next Steps Non-participants receiving AIs: adrian, michl, ro, mmj and ea. 1) Chances ========== Just like the list that was put to gether at the BST offsite meeting, this expresses our hopes for openSUSE. * Real involvement of the community * Mind share / market share * Access to new user groups * Awaken enthusisam for Open Source inside Novell (again) "paint Novell (more) green". * openSUSE could be a central repository for OSS. Not for hosting source, but as "DistForge". * openSUSE could become the driving force behind all Novell Linux products. * We define a new standard for collaborative packaging and distribution building. * become an open platform, suited for experimenal development * strengthen the "SUSE Linux" brand. * Create the world's very best Linux distribution - * and finally: - rule the World (any volunteers?) 2) Risks ======== * The openSUSE project fades away (both, inside and outside of Novell), or does gain momentum soon enough. * It is unclear, how the community can participate. * The wiki may prove to be an insufficient platform for communication. * We try to change everything except ourselves. (Ouch, this one went deep! Thanks Henne) * openSUSE causes fear, uncertainty and doubt at some places inside and outside Novell. * Hosting turns out to be more difficult than expected. (e.g. time delay between Nbg and Provo) * openSUSE may create so much diversity (in packages and distributions) that clarity gets lost. How do we address that? 3) Expectations =============== Some really realistic items. General Expectations -------------------- * Experience full rear cover from Novell. * Offer a platform for building any distribution. - including those with different packaging formats. * The openSUSE team must grow far beyond the core team that we have now. AJ envisions that all of Suse and Novell is doing openSUSE. Expectations for today ---------------------- An attempt to make an agenda while half way through the meeting. * define short term Action Items. What shall we do tomorrow? * Identify all current blocker issues. * Improve Communications - precisely how to change the current situation? * Resolve conflicting messages (Ask 10 people get 11 answers). Reduce uncertainties, raise confidence. 4 Discussion ============ Hosting ------- - mrueckert currently maintains from Nuernberg a wiki located in Provo. Time shifts and turnaround times within the company are challenging. - we generally suffer from the time shifts within Novell * translated wiki pages are still not ready. - We failed to understand many issues, feedback is lacking. We resort to guesswork: * Klaas clarifies that our rapid wishes for software upgrade collide with e.g. our security policies of the data center. - A new naming idea surfaced. We are not a 'SourceForge', but a 'BinaryForge' as we host (RPM) Binaries. -> 'DistForge'? Rear Cover ---------- We are unsure, how far this project will go. We fear that all openSUSE activities have certain limits, but these are diffuse. We have identified the following issues: - How to deal with sensitive, internal information and how to qualify what information shall be made public by an official press anouncement of Novell? - Most of us would be fully booked even without openSUSE. How much time can we spend which openSUSE? - openSUSE is positioned as a market enabler not as a profit line Stefan responds with these rules of thumb: * We have full commitment from Novell to provide the required resources, if we can sufficiently demonstrate that openSUSE is a success. This focusses mainly on hardware but also covers man power to a certain degree: 1) We are encouraged to get as many people inside Novell involved as we can. 2) New people can be hired as trainees, studend for diploma works. * We may disclose as much and as early as we feel safe ourselves. When in doubt, inform the upper management beforehand, but do not wait for any objections longer than a week. * "Don't ask for approval, ask for forgiveness" The idea is, not to thwart ourselves. * continuosly raise issues with the projects for management attention where needed (AI: aj, skh) We agree in case of doubt to not wait for any official blessings, but meanwhile work with Stefan's rules of thumb whereever reasonable. General communication issues (external) --------------------------------------- * The community cannot see what is checked in and when. - establish an opensuse-checkin mailinglist. (AI: mls, fs) Automatically forward dist-mails containing the recent cangelog entires there for all packages that appear on an openSUSE distribution. * migrate internal mailing lists to opensuse.org Candidates are: packagers, suse-network, devel-ftl, devel-gcc?, mobile? Non-candidates are: kernel and other mailing lists where security issues or servicepacks are discussed. (AI: hvogel visiting teamlead-meetings, mmj) * No more private status meetings. - open up as public IRC discussions, as excercised last monday. on a regular bi-weekly schedule. presumably 16h-17h MEST, or alternating time frames if required. Suggestion: collect agenda items in the wiki. AI: hvogel uses devel-ftl for the last time to announce the first meeting. - voting in such a meeting may be difficult. We must not raise expectations above the limits that novell can fulfill. - have internal coordination meetings only on demand (AI: adrian) * Make teams available interactivly. We should have one contact person per openSUSE team. Simply lingering around at IRC is not sufficient. We should offer instant messaging. AI skh: ask teams to update their wiki pages to include preferred means of contact (mailing list and/or IM/IRC nicks and networks) Encourage ----- Henne: We are in the postition that we can actively encourage and involve SUSE employees towards the openSUSE community. * sp votes for applying only mild force :-) * Klaas prefers to lure people by offering added value. Discussion results in the following order of precedence: First inform, then ask, then persuade, then actively help and support. Information should be forwarded via teamleads. Workload -------- Project managers book resources from the teamleads. SLES10, SL10.1 deadlines are all before FOSDEM. Freitag endangers the future of his FATE project, by involving his team too deeply into openSUSE. Adding random resources from all over Novell is probably insufficient. 5) Next Steps ============= Short-Term Action Items ----------------------- * Make a Christmas-Theme or just some greeting for the Wiki. (AI: Henne, put some nice snow into the graphics) * Migrate mailinglists as defined above (AI: hvogel) * Announce preferred interactive contact per team at each team's wiki page. Details above. (AI: skh) Medium-Term Action Items ------------------------ * Strive for Opensource Build Service (AI: skh, aj) * clean up product naming. - 'openSUSE' vs. 'Suse LINUX OSS' is not correctly distinguished in the community or in the press. (AI: michl, aj) - 'eval', 'retail', 'plus' are not well defined. (AI: michl, aj, fs, hvogel, skh) * consolidate openSUSE web forums. There are several external opensuse-forums, that are willing to merge. None of the external forums comes with a defined long term commitment. Novell shall run an openSUSE web forum as a beta-test now. This Novell-forum relies on commercial software, which was inadequate in previous releases. (AI: michl, cthiel) * FOSDEM Build Service Prototype (AI: freitag, ro) - Budgetplan FOSDEM (AI: sp) -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8
Couple comments: 1)This note: Novell shall run an openSUSE web forum as a beta-test now. This Novell-forum relies on commercial software, which was inadequate in previous releases. I do truly hope Novell/openSUSE team plan to choose an open source stack to host this forum. The code is free - all you need is a designer to add a template and a server to run it on. phpBB/LAMP or any of the Java forums on Websphere CE would do... 2) Why not rely on the community more to implement items if openSUSE team doesn't have the bandwidth: You have active, willing workers here that you're not leveraging. 3) As for internal/external communications: Open up, the true success/value only happens if your developers are interacting in the open and can interface with the community. It also makes ISVs and partners better off b/c they have access to open communications with Novell. 4) "Distforge" - this is open "source" - where will the source be hosted? You won't attract developers if there's no code... Host the code on sourceforge if it makes more sense - use your URL on sourceforge and leverage the existing infrastructure... Juergen Weigert wrote:
openSUSE allhands meeting 2005-12-14
disclaimer: The following document covers a meeting of the openSUSE team. It summarizes expectations, concerns, ideas and opportunities around the openSUSE project. It is a rough collection of bits and pieces, neither complete nor final. Please note that these meeting minutes do not reflect any official Novell statement or any binding roadmap or schedule. It is open for discussion and improvement and reflects solely the ideas and opinion of the individual participants.
present: aj, holgi, hvogel, mlasars, freitag, cthiel, jw, skh, mls, fs, bg, mruewckert, sp, froh missing: michl, adrian, cschum
Minutes: jw, sp
TOPICS
1) Chances 2) Risks 3) Expectations 4) Discussion - (Hosting, Rear Cover, Communication, Provo, Force, Workload) 5) Next Steps
Non-participants receiving AIs: adrian, michl, ro, mmj and ea.
1) Chances ========== Just like the list that was put to gether at the BST offsite meeting, this expresses our hopes for openSUSE.
* Real involvement of the community
* Mind share / market share
* Access to new user groups
* Awaken enthusisam for Open Source inside Novell (again) "paint Novell (more) green".
* openSUSE could be a central repository for OSS. Not for hosting source, but as "DistForge".
* openSUSE could become the driving force behind all Novell Linux products.
* We define a new standard for collaborative packaging and distribution building.
* become an open platform, suited for experimenal development
* strengthen the "SUSE Linux" brand.
* Create the world's very best Linux distribution -
* and finally: - rule the World (any volunteers?)
2) Risks ========
* The openSUSE project fades away (both, inside and outside of Novell), or does gain momentum soon enough.
* It is unclear, how the community can participate.
* The wiki may prove to be an insufficient platform for communication.
* We try to change everything except ourselves. (Ouch, this one went deep! Thanks Henne)
* openSUSE causes fear, uncertainty and doubt at some places inside and outside Novell.
* Hosting turns out to be more difficult than expected. (e.g. time delay between Nbg and Provo)
* openSUSE may create so much diversity (in packages and distributions) that clarity gets lost. How do we address that?
3) Expectations =============== Some really realistic items.
General Expectations --------------------
* Experience full rear cover from Novell.
* Offer a platform for building any distribution. - including those with different packaging formats.
* The openSUSE team must grow far beyond the core team that we have now. AJ envisions that all of Suse and Novell is doing openSUSE.
Expectations for today ---------------------- An attempt to make an agenda while half way through the meeting.
* define short term Action Items. What shall we do tomorrow?
* Identify all current blocker issues.
* Improve Communications - precisely how to change the current situation?
* Resolve conflicting messages (Ask 10 people get 11 answers). Reduce uncertainties, raise confidence.
4 Discussion ============
Hosting ------- - mrueckert currently maintains from Nuernberg a wiki located in Provo. Time shifts and turnaround times within the company are challenging.
- we generally suffer from the time shifts within Novell * translated wiki pages are still not ready.
- We failed to understand many issues, feedback is lacking. We resort to guesswork:
* Klaas clarifies that our rapid wishes for software upgrade collide with e.g. our security policies of the data center.
- A new naming idea surfaced. We are not a 'SourceForge', but a 'BinaryForge' as we host (RPM) Binaries. -> 'DistForge'?
Rear Cover ---------- We are unsure, how far this project will go. We fear that all openSUSE activities have certain limits, but these are diffuse. We have identified the following issues:
- How to deal with sensitive, internal information and how to qualify what information shall be made public by an official press anouncement of Novell?
- Most of us would be fully booked even without openSUSE. How much time can we spend which openSUSE?
- openSUSE is positioned as a market enabler not as a profit line
Stefan responds with these rules of thumb:
* We have full commitment from Novell to provide the required resources, if we can sufficiently demonstrate that openSUSE is a success. This focusses mainly on hardware but also covers man power to a certain degree: 1) We are encouraged to get as many people inside Novell involved as we can. 2) New people can be hired as trainees, studend for diploma works.
* We may disclose as much and as early as we feel safe ourselves. When in doubt, inform the upper management beforehand, but do not wait for any objections longer than a week.
* "Don't ask for approval, ask for forgiveness" The idea is, not to thwart ourselves.
* continuosly raise issues with the projects for management attention where needed (AI: aj, skh)
We agree in case of doubt to not wait for any official blessings, but meanwhile work with Stefan's rules of thumb whereever reasonable.
General communication issues (external) ---------------------------------------
* The community cannot see what is checked in and when. - establish an opensuse-checkin mailinglist. (AI: mls, fs) Automatically forward dist-mails containing the recent cangelog entires there for all packages that appear on an openSUSE distribution.
* migrate internal mailing lists to opensuse.org Candidates are: packagers, suse-network, devel-ftl, devel-gcc?, mobile? Non-candidates are: kernel and other mailing lists where security issues or servicepacks are discussed. (AI: hvogel visiting teamlead-meetings, mmj)
* No more private status meetings. - open up as public IRC discussions, as excercised last monday. on a regular bi-weekly schedule. presumably 16h-17h MEST, or alternating time frames if required. Suggestion: collect agenda items in the wiki. AI: hvogel uses devel-ftl for the last time to announce the first meeting. - voting in such a meeting may be difficult. We must not raise expectations above the limits that novell can fulfill. - have internal coordination meetings only on demand (AI: adrian)
* Make teams available interactivly. We should have one contact person per openSUSE team. Simply lingering around at IRC is not sufficient. We should offer instant messaging. AI skh: ask teams to update their wiki pages to include preferred means of contact (mailing list and/or IM/IRC nicks and networks)
Encourage ----- Henne: We are in the postition that we can actively encourage and involve SUSE employees towards the openSUSE community.
* sp votes for applying only mild force :-)
* Klaas prefers to lure people by offering added value.
Discussion results in the following order of precedence: First inform, then ask, then persuade, then actively help and support. Information should be forwarded via teamleads.
Workload -------- Project managers book resources from the teamleads. SLES10, SL10.1 deadlines are all before FOSDEM. Freitag endangers the future of his FATE project, by involving his team too deeply into openSUSE. Adding random resources from all over Novell is probably insufficient.
5) Next Steps =============
Short-Term Action Items -----------------------
* Make a Christmas-Theme or just some greeting for the Wiki. (AI: Henne, put some nice snow into the graphics)
* Migrate mailinglists as defined above (AI: hvogel)
* Announce preferred interactive contact per team at each team's wiki page. Details above. (AI: skh)
Medium-Term Action Items ------------------------
* Strive for Opensource Build Service (AI: skh, aj)
* clean up product naming. - 'openSUSE' vs. 'Suse LINUX OSS' is not correctly distinguished in the community or in the press. (AI: michl, aj)
- 'eval', 'retail', 'plus' are not well defined. (AI: michl, aj, fs, hvogel, skh)
* consolidate openSUSE web forums. There are several external opensuse-forums, that are willing to merge. None of the external forums comes with a defined long term commitment. Novell shall run an openSUSE web forum as a beta-test now. This Novell-forum relies on commercial software, which was inadequate in previous releases. (AI: michl, cthiel)
* FOSDEM Build Service Prototype (AI: freitag, ro) - Budgetplan FOSDEM (AI: sp)
On Fri, 16 Dec 2005, Michael K. Dolan Jr. wrote:
Couple comments:
1)This note:
Novell shall run an openSUSE web forum as a beta-test now. This Novell-forum relies on commercial software, which was inadequate in previous releases.
I totally agree with you -- but we will at least have to take a look at "new Novell webforums". We will not wait forever and need to set a deadline for the "new Novell webforums" to show up, because we haven't had the chance to get a view on the latests version yet. Realistically this deadline would be somewhen in mid January.
I do truly hope Novell/openSUSE team plan to choose an open source stack to host this forum. The code is free - all you need is a designer to add a template and a server to run it on. phpBB/LAMP or any of the Java forums on Websphere CE would do...
+ you need to add some code to connect to iChains, to enable existing Novell accounts to access the forum. In addition to that an alternative interface to the forum (like mail or news) would be desirable. Overall I guess it would take two to three man weeks to get a forum up and running.
2) Why not rely on the community more to implement items if openSUSE team doesn't have the bandwidth: You have active, willing workers here that you're not leveraging.
We are totally committed to collaborate with the community. This might not easy in the beginning. If you have any thoughts on how to succeed in this area, please let us know! What would be the item to start with?
3) As for internal/external communications: Open up, the true success/value only happens if your developers are interacting in the open and can interface with the community. It also makes ISVs and partners better off b/c they have access to open communications with Novell.
True.
4) "Distforge" - this is open "source" - where will the source be hosted? You won't attract developers if there's no code... Host the code on sourceforge if it makes more sense - use your URL on sourceforge and leverage the existing infrastructure...
Well, one of our objectives (we defined very early, when the openSUSE project wasn't even public) is not to duplicate any existing efforts (like SF.net in this very case), if it's not inevitable. The real value of the $build_service (or however it will be named in the end) is much more something in the sense of beeing a place to build and host binary packages (for various distributions) and the project laying stuff that has been described in the recently published build service whitepaper. Regards Christoph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Thiel wrote:
4) "Distforge" - this is open "source" - where will the source be hosted? You won't attract developers if there's no code... Host the code on sourceforge if it makes more sense - use your URL on sourceforge and leverage the existing infrastructure... Well, one of our objectives (we defined very early, when the openSUSE
On Fri, 16 Dec 2005, Michael K. Dolan Jr. wrote: ... project wasn't even public) is not to duplicate any existing efforts (like SF.net in this very case), if it's not inevitable. The real value of the $build_service (or however it will be named in the end) is much more something in the sense of beeing a place to build and host binary packages (for various distributions) and the project laying stuff that has been described in the recently published build service whitepaper.
And sourceforge won't accept hosting all those packages over there.
I asked them to host my repository as a SF project and they didn't accept.
And my repository is "only" 6 GB with around 700 packages/projects (actually a little over 4500 RPM
files).
We'll have *many* more packages on the build service's hosting infrastructure, actually order of
magnitudes more.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Fri, 16 Dec 2005, Pascal Bleser wrote:
4) "Distforge" - this is open "source" - where will the source be hosted? You won't attract developers if there's no code... Host the code on sourceforge if it makes more sense - use your URL on sourceforge and leverage the existing infrastructure... Well, one of our objectives (we defined very early, when the openSUSE project wasn't even public) is not to duplicate any existing efforts (like SF.net in this very case), if it's not inevitable. The real value of the $build_service (or however it will be named in the end) is much more something in the sense of beeing a place to build and host binary packages (for various distributions) and the project laying stuff that has been described in the recently published build service whitepaper.
And sourceforge won't accept hosting all those packages over there. I asked them to host my repository as a SF project and they didn't accept. And my repository is "only" 6 GB with around 700 packages/projects (actually a little over 4500 RPM files).
We'll have *many* more packages on the build service's hosting infrastructure, actually order of magnitudes more.
Right, that's a good point - this will of course be challenging ;) Regards Christoph
Hi, On Fri, 16 Dec 2005, Juergen Weigert wrote:
openSUSE allhands meeting 2005-12-14
[very selective comment, lots of stuff not quoted, not reflected]
1) Chances ==========
* openSUSE could be a central repository for OSS. Not for hosting source, but as "DistForge".
This would be a good motor of the community aspect. We need a "build host" architecture and a "hidden mirror source", nothing more. I guess almost every SUSE mirror will share his resources for the distribution.
* openSUSE could become the driving force behind all Novell Linux products.
It already is, as it is the successor/base of SUSE-Professional. And it would even be it without any new community partitipation because Novell/SUSE has always used the Professional series as the base for SLES, and staff is still the same. ;-))
* We define a new standard for collaborative packaging and distribution building.
Please do. Not much work if you invoke a committee out of the suse-user ("suser") packager from "your" apt community.
* become an open platform, suited for experimenal development
Already is. See ftp.gwdg.de/pub/linux/misc/suser-*/.
* strengthen the "SUSE Linux" brand.
Why not. Maybe you need to turn the chamaeleon (gecko) once more, 90 grades this time, with a silly grin and a rolling stones tongue coming out. ;-))
* Create the world's very best Linux distribution -
Yes. Don't forget that "world domination" has to be your goal, even for small steps in this direction (but I guess SUSE is already in front since a long time). So the universality of your concept is important: don't forget anything, don't neglect anything.
* and finally: - rule the World (any volunteers?)
Who not? But see above. Not brute force (money), but the better ideas please.
2) Risks ========
* The openSUSE project fades away (both, inside and outside of Novell), or does gain momentum soon enough.
In my guess, "openSUSE" is just an effort to integrate what has lived aside since a long time. Just listen to the suser-* packagers, and you will reach the goal blindly.
* It is unclear, how the community can participate.
Reporting, requesting, discussing, packaging.
* We try to change everything except ourselves. (Ouch, this one went deep! Thanks Henne)
Wow! A brain inside! Harakiri is a splendid celebration for the public. But only if you have more than 10 years of mental experience with it. ;-))
* openSUSE causes fear, uncertainty and doubt at some places inside and outside Novell.
This is a matter of "simplicity in communication" only. You need a very simple "migration model" for press releases: the "professional" team simply has "opened" towards the community, but still is able to do all the necessary work without any help. The next sentence should contain "feedback"...
* Hosting turns out to be more difficult than expected. (e.g. time delay between Nbg and Provo)
Please solve this internally. Userids with the right privileges at the remote location. At least this is easier than everything else.
* openSUSE may create so much diversity (in packages and distributions) that clarity gets lost. How do we address that?
Don't forget that the openSUSE community alredy is existing, for years. Just monitor apt4rpm-suse@lists.sourceforge.net and www.linux-club.de...
Hosting -------
- A new naming idea surfaced. We are not a 'SourceForge', but a 'BinaryForge' as we host (RPM) Binaries. -> 'DistForge'?
Forget all associations to existing environments. You are creating something new, and even if not totally new, you have to have the goal of "world domination".
Rear Cover ----------
Stefan responds with these rules of thumb:
* We may disclose as much and as early as we feel safe ourselves. When in doubt, inform the upper management beforehand, but do not wait for any objections longer than a week.
Very good. You need an OK from upstream, but once you have it: a very good policy.
5) Next Steps =============
Short-Term Action Items -----------------------
* Make a Christmas-Theme or just some greeting for the Wiki. (AI: Henne, put some nice snow into the graphics)
Very important, at least seen from the long-term strategy. ;->> Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eberhard Moenkeberg wrote:
On Fri, 16 Dec 2005, Juergen Weigert wrote: ...
* openSUSE could be a central repository for OSS. Not for hosting source, but as "DistForge". This would be a good motor of the community aspect. We need a "build host" architecture and a "hidden mirror source", nothing more.
Eberhard, what do you mean with "hidden mirror source" ? ...
* We define a new standard for collaborative packaging and distribution building. Please do. Not much work if you invoke a committee out of the suse-user ("suser") packager from "your" apt community.
I'd even like to put it like this: please involve us community packagers in this process, don't let us stay aside. We can give you feedback about the issues we're facing every day, what would help most, how to best organize and coordinate things, at least from our past and current experience.
* become an open platform, suited for experimenal development Already is. See ftp.gwdg.de/pub/linux/misc/suser-*/.
Yes and no. We (suser-*) were always bound to a "static" core distribution, from our point of view. We didn't have much possibilities to influence what was happening in there. This has changed now, or at least it has started to change. It (the "build service" ?) should become a truly open and collaborative platform for working together, both the SUSE staff and the packagers from the community. There's also another aspect: the customized distributions based on SUSE Linux OSS, such as SUPER, SLICK, ... That's highly experimental, and the outcomes and experience from those projects will be very interesting.
* strengthen the "SUSE Linux" brand. Why not. Maybe you need to turn the chamaeleon (gecko) once more, 90 grades this time, with a silly grin and a rolling stones tongue coming out. ;-))
You might not think so, but that also goes through wallpapers, web buttons, logos, merchandising (T-shirts and stuff), so people can show off what their favorite distro is. Don't believe me ? have a look at Debian ;) ...
* and finally: - rule the World (any volunteers?)
Count me in ;) ...
* The openSUSE project fades away (both, inside and outside of Novell), or does gain momentum soon enough. In my guess, "openSUSE" is just an effort to integrate what has lived aside since a long time. Just listen to the suser-* packagers, and you will reach the goal blindly.
Well not necessarely blindly, but I know we can provide a lot in terms of experience, ideas, suggestions and manpower. As I already wrote on the opensuse mailing-list some months ago (part of that lot of emails that got lost in some black hole between the SUSE 10.0 release rush and the SUSE staff taking holidays after that), in my opinion we should try to: a) coordinate the community/"suser" packagers, make it more of a joint effort instead of disparate repositories as of now (a few things have been made towards that direction, but not much, and definitely not enough) b) grow the packager community, help, review, teach
* It is unclear, how the community can participate. Reporting, requesting, discussing, packaging.
It's not totally clear how the community can participate as of now, as not enough has been "opened up" until now (but I know that you know, and that you're working on that). Nevertheless: - - testing, reporting bugs - - spreading the word - - making packages (*), testing those packages, provide feedback, communicate with upstream - - helping users: forums, IRC, mailing-lists (*) I mostly mean packages that are either not in the core distribution or the latest version, as what is mostly being done currently in "community packager" repositories
* We try to change everything except ourselves. (Ouch, this one went deep! Thanks Henne)
Volltreffer ;)
* openSUSE causes fear, uncertainty and doubt at some places inside and outside Novell.
This is a matter of "simplicity in communication" only. You need a very simple "migration model" for press releases: the "professional" team simply has "opened" towards the community, but still is able to do all the necessary work without any help. The next sentence should contain "feedback"... ...
* openSUSE may create so much diversity (in packages and distributions) that clarity gets lost. How do we address that? Don't forget that the openSUSE community alredy is existing, for years. Just monitor apt4rpm-suse@lists.sourceforge.net and www.linux-club.de...
+1
Hosting ------- - A new naming idea surfaced. We are not a 'SourceForge', but a 'BinaryForge' as we host (RPM) Binaries. -> 'DistForge'? Forget all associations to existing environments. You are creating something new, and even if not totally new, you have to have the goal of "world domination".
DistForge sounds nice ;)
High priority item: bugzilla for packages, including community stuff
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Hi, On Sat, 17 Dec 2005, Pascal Bleser wrote: [putting some space between the quotes and yours would make it MUCH MORE readable. At some points you do, at some you forget.]
Eberhard Moenkeberg wrote:
On Fri, 16 Dec 2005, Juergen Weigert wrote:
...
* openSUSE could be a central repository for OSS. Not for hosting source, but as "DistForge".
This would be a good motor of the community aspect. We need a "build host" architecture and a "hidden mirror source", nothing more.
Eberhard, what do you mean with "hidden mirror source" ?
SUSE did never have sufficient infrastructure and/or bandwidth to say "we finally have done it, now just take it". You know what "slashdotting" means... So OpenSUSE would benefit from a solid mirror hierarchy. I just have stated "it is already present". If the OpenSUSE project feels encouraged to use the SUSE distribution mirror hierarchy. And if they would think they should not feel (but we all know they already ACT like feeling this way), they simply would have to invoke a separate mirror hierarchy. They would get it, and I would help too.
* We define a new standard for collaborative packaging and distribution building.
Please do. Not much work if you invoke a committee out of the suse-user ("suser") packager from "your" apt community.
I'd even like to put it like this: please involve us community packagers in this process, don't let us stay aside. We can give you feedback about the issues we're facing every day, what would help most, how to best organize and coordinate things, at least from our past and current experience.
Your best qualification is: you are delivering "additional quality" since years (YES, PLURAL!) Thanks to Richard for clearing this. ;-))
* become an open platform, suited for experimenal development
Already is. See ftp.gwdg.de/pub/linux/misc/suser-*/.
Yes and no. We (suser-*) were always bound to a "static" core distribution, from our point of view. We didn't have much possibilities to influence what was happening in there. This has changed now, or at least it has started to change.
Yes. ;-))
It (the "build service" ?) should become a truly open and collaborative platform for working together, both the SUSE staff and the packagers from the community.
Good hardware, plus userids. Very easy to do...
There's also another aspect: the customized distributions based on SUSE Linux OSS, such as SUPER, SLICK, ... That's highly experimental, and the outcomes and experience from those projects will be very interesting.
This is just the same "quality" as additional packages. Needing more disk space, but that should not be a matter. Installing customized distributions over the net has to get restricted to using mirrors (at least in the beginning, I guess) - so a strong directory scheme is needed. We already have /pub/opensuse/distribution/, so this is the place which would hold unique names between all mirrors. /pub/opensuse/distribution/SUPER/ /pub/opensuse/distribution/SLICK/ go on with this, opensuse core team, please. It would be a breakdown through an internal wall, I guess - so please put this idea "upstream" to the Utah center, please. I had tried before to host SUPER at ftp.gwdg.de, but there was a communication breakdown which still is lasting.
* strengthen the "SUSE Linux" brand.
Why not. Maybe you need to turn the chamaeleon (gecko) once more, 90 grades this time, with a silly grin and a rolling stones tongue coming out. ;-))
You might not think so, but that also goes through wallpapers, web buttons, logos, merchandising (T-shirts and stuff), so people can show off what their favorite distro is. Don't believe me ? have a look at Debian ;)
Yes, and a change is a nut, as we all know from the moment that the gecko turned from left to right. ;-))
* and finally: - rule the World (any volunteers?)
Count me in ;)
...
* The openSUSE project fades away (both, inside and outside of Novell), or does gain momentum soon enough.
In my guess, "openSUSE" is just an effort to integrate what has lived aside since a long time. Just listen to the suser-* packagers, and you will reach the goal blindly.
Well not necessarely blindly, but I know we can provide a lot in terms of experience, ideas, suggestions and manpower.
OK, OK. But don't forget that the openSUSE team currently is claiming tnat they want to invent/invoke such people as you already are since years. So we have to tell them "already here".
As I already wrote on the opensuse mailing-list some months ago (part of that lot of emails that got lost in some black hole between the SUSE 10.0 release rush and the SUSE staff taking holidays after that), in my opinion we should try to: a) coordinate the community/"suser" packagers, make it more of a joint effort instead of disparate repositories as of now (a few things have been made towards that direction, but not much, and definitely not enough) b) grow the packager community, help, review, teach
Well. My guess is: integration/communication is the spot. Everything wanted is alredy existing, we simply needthe "big integration".
* It is unclear, how the community can participate.
Reporting, requesting, discussing, packaging.
It's not totally clear how the community can participate as of now, as not enough has been "opened up" until now (but I know that you know, and that you're working on that). Nevertheless: - - testing, reporting bugs - - spreading the word - - making packages (*), testing those packages, provide feedback, communicate with upstream - - helping users: forums, IRC, mailing-lists
At least: every partitipant or volunteer is able to go on straight (via nis own ftp.gwdg.de:/pub/linux/suse/suser-* directory) and invited to hope that the openSUSE project will offer better opportunities. Let's delay this aspect and rate again after 6 months, just to get a better feeling if Novell is more claiming than acting. At least. my sponsoring request for ftp.gwdg.de (need a new server with at least 32 GB RAM because the SUSE releases exploded in size) ended in Nirwana (known as Eric Anderson), So please hear this, Eric, I will hope for your struggling for another 6 months. But maybe I have to discard my SUSE services earlier, in order to overcome at all.
(*) I mostly mean packages that are either not in the core distribution or the latest version, as what is mostly being done currently in "community packager" repositories
* We try to change everything except ourselves. (Ouch, this one went deep! Thanks Henne)
Volltreffer ;)
* openSUSE causes fear, uncertainty and doubt at some places inside and outside Novell.
This is a matter of "simplicity in communication" only. You need a very simple "migration model" for press releases: the "professional" team simply has "opened" towards the community, but still is able to do all the necessary work without any help. The next sentence should contain "feedback"... ...
* openSUSE may create so much diversity (in packages and distributions) that clarity gets lost. How do we address that? Don't forget that the openSUSE community alredy is existing, for years. Just monitor apt4rpm-suse@lists.sourceforge.net and www.linux-club.de...
+1
Hosting ------- - A new naming idea surfaced. We are not a 'SourceForge', but a 'BinaryForge' as we host (RPM) Binaries. -> 'DistForge'?
Forget all associations to existing environments. You are creating something new, and even if not totally new, you have to have the goal of "world domination".
DistForge sounds nice ;)
But is poorly leaning on existing 50% Solutions.
High priority item: bugzilla for packages, including community stuff
But you can already enter your bugs into bugzilla. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Sat, 17 Dec 2005, Eberhard Moenkeberg wrote:
This would be a good motor of the community aspect. We need a "build host" architecture and a "hidden mirror source", nothing more.
Eberhard, what do you mean with "hidden mirror source" ?
SUSE did never have sufficient infrastructure and/or bandwidth to say "we finally have done it, now just take it". You know what "slashdotting" means...
Better timing + clear-sighted communication would have helped sometimes ;)
So OpenSUSE would benefit from a solid mirror hierarchy.
I just have stated "it is already present". If the OpenSUSE project feels encouraged to use the SUSE distribution mirror hierarchy. And if they would think they should not feel (but we all know they already ACT like feeling this way), they simply would have to invoke a separate mirror hierarchy. They would get it, and I would help too.
Having a mature mirror infrastructure in place is very important to the overall success of the openSUSE project - we will need to address this issue preferably soon. This should also include discussing new / innovative technologies (like drpmsync+tools, jigdo, bittorrent, etc.) beyond rsync to keep the mirrors in-sync with a minimal delay. Realistically we should postpone this topic to early January, when people get back from vacation after the holidays.
* The openSUSE project fades away (both, inside and outside of Novell), or does gain momentum soon enough.
In my guess, "openSUSE" is just an effort to integrate what has lived aside since a long time. Just listen to the suser-* packagers, and you will reach the goal blindly.
Well not necessarely blindly, but I know we can provide a lot in terms of experience, ideas, suggestions and manpower.
OK, OK. But don't forget that the openSUSE team currently is claiming tnat they want to invent/invoke such people as you already are since years. So we have to tell them "already here".
No worries - you guys have already attracted our attention ;)
As I already wrote on the opensuse mailing-list some months ago (part of that lot of emails that got lost in some black hole between the SUSE 10.0 release rush and the SUSE staff taking holidays after that), in my opinion we should try to: a) coordinate the community/"suser" packagers, make it more of a joint effort instead of disparate repositories as of now (a few things have been made towards that direction, but not much, and definitely not enough) b) grow the packager community, help, review, teach
Well. My guess is: integration/communication is the spot. Everything wanted is alredy existing, we simply needthe "big integration".
... the $build_service will ultimately facilitate that integration. ATM I have the impression that our whole build service vision hasn't spread that much yet. Everyone, the documents that are on http://www.opensuse.org/Build_Service_Team deliver quite some inside on this topic. If you have comments / questions on those documents, please feel free to refer to this mailing list. Always remember: There's no such thing as a dumb question!
* It is unclear, how the community can participate.
Reporting, requesting, discussing, packaging.
It's not totally clear how the community can participate as of now, as not enough has been "opened up" until now (but I know that you know, and that you're working on that). Nevertheless: - - testing, reporting bugs - - spreading the word - - making packages (*), testing those packages, provide feedback, communicate with upstream - - helping users: forums, IRC, mailing-lists
At least: every partitipant or volunteer is able to go on straight (via nis own ftp.gwdg.de:/pub/linux/suse/suser-* directory) and invited to hope that the openSUSE project will offer better opportunities.
Let's delay this aspect and rate again after 6 months, just to get a better feeling if Novell is more claiming than acting.
You may rest assured Eberhard that we are seriously committed to arrive what we have been talking about for a few month now!
High priority item: bugzilla for packages, including community stuff
But you can already enter your bugs into bugzilla.
... but as of now bugzilla.novell.com is only used to track bugs for packages that are maintained by Novell / SUSE. Having a central place to track bugs for all packages that are available for SUSE Linux would be preferable IMHO. Regards Christoph
Hello, Am Sonntag, 18. Dezember 2005 23:33 schrieb Christoph Thiel:
On Sat, 17 Dec 2005, Eberhard Moenkeberg wrote: [...]
High priority item: bugzilla for packages, including community stuff
But you can already enter your bugs into bugzilla.
... but as of now bugzilla.novell.com is only used to track bugs for packages that are maintained by Novell / SUSE. Having a central place to track bugs for all packages that are available for SUSE Linux would be preferable IMHO.
I fully agree, but I see one problem: How do you avoid that the SUSE developers will have to handle all bugs in communitiy packages? It might be easy to tell for packages that are not in the core distribution (you still may have to re-assign bugs), but if someone creates a modified Apache/KDE/whatelse package, things will become more difficult. I also have an idea how this could be solved: Use the packager field in the RPMs - it now contains http://www.suse.de/feedback for all suse packages [1]. What about putting a direct bugzilla link into the packager field? Someone who wants to file a bugreport should be able to call rpm -qi ;-) Example URL for packager field: https://bugzilla.novell.com?enter_bug.cgi?product=SUSE%20Linux%2010.0&package=apache2&version=2.0.50-150&packager=cboltz "product", "package" and "version" should be quite obvious and, even if not always necessary, can show the packagers package and version even if the user enters a "bad" bug report. "packager" could just be the Novell login name of the packager - and of course the default assignee for the bug. What do you think about this idea? BTW: I guess it would be a bad idea to have a separate bugzilla for packages from $build_service - I can imagine that several bugs in modified packages also exist in the original package. Having everything in one bugzilla means that a packager can CC the bug to the SUSE maintainer etc. which would be more difficult with a separate bugzilla. Regards, Christian Boltz [1] suse.de/feedback is often seen as "black hole", but that's another story ;-) -- Wenn diese Liste über Mailman betrieben würde, dann würden wir den ganzen Tag nichts anderes machen als eine Menschenkette zum nächsten Computerladen aufrechtzuerhalten um RAM in einem konstanten fluss in lists.suse.com einzubauen ;) [Henne Vogelsang in suse-linux]
On Mon, 19 Dec 2005, Christian Boltz wrote:
On Sat, 17 Dec 2005, Eberhard Moenkeberg wrote: [...]
High priority item: bugzilla for packages, including community stuff
But you can already enter your bugs into bugzilla.
... but as of now bugzilla.novell.com is only used to track bugs for packages that are maintained by Novell / SUSE. Having a central place to track bugs for all packages that are available for SUSE Linux would be preferable IMHO.
I fully agree, but I see one problem: How do you avoid that the SUSE developers will have to handle all bugs in communitiy packages?
It might be easy to tell for packages that are not in the core distribution (you still may have to re-assign bugs), but if someone creates a modified Apache/KDE/whatelse package, things will become more difficult.
True. On option would be to take a hidden header tag into account: rpm -q --qf "%{DISTURL}\n" bash ATM this is an way to find out if the package was built by the build service and to which repo it belongs.
I also have an idea how this could be solved: Use the packager field in the RPMs - it now contains http://www.suse.de/feedback for all suse packages [1].
If you look at the latests SUSE packages, you won't find suse.de/feedback anylonger. We already changed this like to "http://bugs.opensuse.org/" ;)
What about putting a direct bugzilla link into the packager field? Someone who wants to file a bugreport should be able to call rpm -qi ;-)
Example URL for packager field: https://bugzilla.novell.com?enter_bug.cgi?product=SUSE%20Linux%2010.0&package=apache2&version=2.0.50-150&packager=cboltz
"product", "package" and "version" should be quite obvious and, even if not always necessary, can show the packagers package and version even if the user enters a "bad" bug report.
"packager" could just be the Novell login name of the packager - and of course the default assignee for the bug.
What do you think about this idea?
Sure, this could be an option.
BTW: I guess it would be a bad idea to have a separate bugzilla for packages from $build_service - I can imagine that several bugs in modified packages also exist in the original package. Having everything in one bugzilla means that a packager can CC the bug to the SUSE maintainer etc. which would be more difficult with a separate bugzilla.
I'm pretty confident that this won't happen ;) Regards Christoph
Yo Team What an email so fully loaded with 100% good and agreeable info!
* Awaken enthusisam for Open Source inside Novell (again) "paint Novell (more) green".
I like Red ;) Honestly
* openSUSE could be a central repository for OSS. Not for hosting source, but as "DistForge".
* openSUSE could become the driving force behind all Novell Linux
Don't create another brand/name. Stick with openSuSeforge or OSS forge. Do not create confusion with a new naming like distro forge as tempting as it might be, since it is a good name distroforge! We are doing a specific distro here? I thought so. products.
100% I agree!
* We define a new standard for collaborative packaging and distribution building.
* become an open platform, suited for experimenal development
* strengthen the "SUSE Linux" brand.
* Create the world's very best Linux distribution -
You are already doing this, tell more people it is de facto the best Enterprise Class Distro/Software house.
* and finally: - rule the World (any volunteers?)
Will try my best at the Linuxconf.au to represent us.
2) Risks ========
* The openSUSE project fades away (both, inside and outside of
Novell),
or does gain momentum soon enough.
* It is unclear, how the community can participate.
* The wiki may prove to be an insufficient platform for communication.
* We try to change everything except ourselves. (Ouch, this one went deep! Thanks Henne)
* openSUSE causes fear, uncertainty and doubt at some places inside and outside Novell.
* Hosting turns out to be more difficult than expected. (e.g. time delay between Nbg and Provo)
Hosting needs to be decentralized. Distrowatch has hosts in various countries and redirects to those mirrors. Spread the load!
* openSUSE may create so much diversity (in packages and distributions) that clarity gets lost. How do we address that?
Only if we let it happen. All experiments with the toolkit are openSUSE projects. If we can replace every reason there is for having so many distro's out there by running SUSE based flavors under the green Banner!
3) Expectations =============== Some really realistic items.
General Expectations --------------------
* Experience full rear cover from Novell.
* Offer a platform for building any distribution. - including those with different packaging formats.
* The openSUSE team must grow far beyond the core team that we have
now.
AJ envisions that all of Suse and Novell is doing openSUSE.
SNIP!
Yes yes yes yes :D ... Totally agreed Wow .... why oh why has beaming not been invented yet? Would love to have been at the meeting. Andreas
participants (7)
-
Andreas Girardet -
Christian Boltz -
Christoph Thiel -
Eberhard Moenkeberg -
Juergen Weigert -
Michael K. Dolan Jr. -
Pascal Bleser