Hi All !
There are lots of packages in the build-service, but I still consider those as "third-party", because they aren't part of openSUSE Factory tree, therefore they won't become part of openSUSE 11.1 release.
I would like to take the job of integrating *stable* packages from the community's Build Service home projects, and taking them to Factory.
Unstable packages will remain as-is (third-party).
I will begin with my own package: "banner" :)
Now: May I get commit access ?
Am Montag 28 Juli 2008 09:43:34 schrieb Alexey Eremenko:
Hi All !
There are lots of packages in the build-service, but I still consider those as "third-party", because they aren't part of openSUSE Factory tree, therefore they won't become part of openSUSE 11.1 release.
I would like to take the job of integrating *stable* packages from the community's Build Service home projects, and taking them to Factory.
Unstable packages will remain as-is (third-party).
I will begin with my own package: "banner" :)
Now: May I get commit access ?
No ;)
The thing is that only a very small group has write access to Factory and they need to review the submissions for security reasons.
To be able to scale with this setup, we have the maintainers in the "devel projects" which are responsible for the packages and do a first review of submitted changes. So when you like to update a package, you need to submit to these places. Or ask for write access there.
There was no real discussion yet how to handle new packages btw ...
bye adrian
Now: May I get commit access ?
No ;)
Well, a bit sad :(
The thing is that only a very small group has write access to Factory and they need to review the submissions for security reasons.
To be able to scale with this setup, we have the maintainers in the "devel projects" which are responsible for the packages and do a first review of submitted changes. So when you like to update a package, you need to submit to these places. Or ask for write access there.
There was no real discussion yet how to handle new packages btw ...
Seriously, I understand the need for maintaining integrity for openSUSE.
Actually I think that a good idea would be to build a "multi-level" introduction of packages into factory, like: 1. community "home" projects on Build Service - experimental packages go here. 2. Pre-Factory tree project (place where evaluations will take place on both quality, stability and license, ...) This repository will contain the "candidate" packages, that are aimed at future inclusion into factory. 3. Factory itself - Novell employees will take packages, from "pre-factory" tree. Packages, that are qualified will be put into factory.
After all, moving openSUSE distro construction to openly-viewed build service, is made exactly for purpose of external contributions...
Write commits to pre-factory tree should be made upon request for community members.
Layered approach is a good way to make things moving...
Am Montag 28 Juli 2008 11:29:00 schrieb Alexey Eremenko: ...
The thing is that only a very small group has write access to Factory and they need to review the submissions for security reasons.
To be able to scale with this setup, we have the maintainers in the "devel projects" which are responsible for the packages and do a first review of submitted changes. So when you like to update a package, you need to submit to these places. Or ask for write access there.
There was no real discussion yet how to handle new packages btw ...
Seriously, I understand the need for maintaining integrity for openSUSE.
Actually I think that a good idea would be to build a "multi-level" introduction of packages into factory,
Actually, this is what we have.
like:
- community "home" projects on Build Service - experimental packages go
here.
basically any project inside and outside of home: has this level.
- Pre-Factory tree project (place where evaluations will take place
on both quality, stability and license, ...) This repository will contain the "candidate" packages, that are aimed at future inclusion into factory.
These are the "devel projects" I spoke before. run
osc meta pkg openSUSE:Factory $SOME_PACKAGE
to see, which project is used for this package.
- Factory itself - Novell employees will take packages, from
"pre-factory" tree. Packages, that are qualified will be put into factory.
Everybody, independend of Novell Employee or not, can submit packages. However, a small group, the autobuild team is reviewing the submission and accepts or declines it (with a reason). But these submissions should come from a "devel project" to be sure that the experts for these packages have seen and accepted the change.
After all, moving openSUSE distro construction to openly-viewed build service, is made exactly for purpose of external contributions...
Write commits to pre-factory tree should be made upon request for community members.
Layered approach is a good way to make things moving...
I think we have this kind of system already. And we do not make a difference between Novell Employee or not btw. Novell Employees have also not direct write access to Factory and need the review and acceptance from the autobuild group as well.
On Mon, Jul 28, 2008 at 12:48 PM, Adrian Schröter adrian@suse.de wrote:
- Pre-Factory tree project (place where evaluations will take place
on both quality, stability and license, ...) This repository will contain the "candidate" packages, that are aimed at future inclusion into factory.
These are the "devel projects" I spoke before. run
osc meta pkg openSUSE:Factory $SOME_PACKAGE
to see, which project is used for this package.
But here you write about packages that already exists as part of the distro, right?
I'm talking about new packages.
Where do I place new packages, that I believe that are stable enough to become candidates for factory inclusion?
On Mon, 28 Jul 2008, Alexey Eremenko wrote:
Now: May I get commit access ?
No ;)
Well, a bit sad :(
No. It's a good thing, that I can rely on the Factory variant. I do want to trust the distribution to a certain degree. And the trust level for Factory inclusion should be much higher than for openSUSE.
Seriously, I understand the need for maintaining integrity for openSUSE.
Actually I think that a good idea would be to build a "multi-level" introduction of packages into factory, like:
- community "home" projects on Build Service - experimental packages go here.
- Pre-Factory tree project (place where evaluations will take place
on both quality, stability and license, ...) This repository will contain the "candidate" packages, that are aimed at future inclusion into factory. 3. Factory itself - Novell employees will take packages, from "pre-factory" tree. Packages, that are qualified will be put into factory.
After all, moving openSUSE distro construction to openly-viewed build service, is made exactly for purpose of external contributions...
Write commits to pre-factory tree should be made upon request for community members.
Layered approach is a good way to make things moving...
Well, why don't you take the path we currently have:
a) Build your stuff in home.
b) If it is stable search for a toplevel project, where you can get it moved into and apply for inclusion of your package into that top-level directory.
c) If that worked reliable for some time, ask the Novell people (e.g. one providing packages in the same field of software) to think about Factory inclusion.
If the statistics are back and working fine, then c) can also be done automatically based on download counts.
Ciao
Adrian Schröter escribió: Or ask for write access there.
There was no real discussion yet how to handle new packages btw ...
I think we should estabilish something like the Fedora package review guidelines.
http://fedoraproject.org/wiki/Package_Review_Process
On Tue, Jul 29, 2008 at 3:19 AM, Cristian Rodríguez crrodriguez@suse.de wrote:
Adrian Schröter escribió: Or ask for write access there.
There was no real discussion yet how to handle new packages btw ...
I think we should estabilish something like the Fedora package review guidelines.
Well, yes, it makes sense. How do we proceed from here?
Cristian Rodríguez wrote:
Adrian Schröter escribió: Or ask for write access there.
There was no real discussion yet how to handle new packages btw ...
I think we should estabilish something like the Fedora package review guidelines.
Fedora's Package Review Guidelines are a nice checklist for measuring quality of packages, however, in our case, the most important question IMHO should be: "Does this package *need* to be part of the core distribution?". For many packages a home in the buildservice repositories is actually the better option: * Buildservice packages can be updated after distro release quite easily (and without wasting space in you repositories) * Can be provided for released distributions * For the end-user, using buildservice packages is IMO as easy as using distribution packages.
just my two cents, Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Jul 29, 2008 at 1:15 PM, Michal Marek mmarek@suse.cz wrote:
Cristian Rodríguez wrote:
Adrian Schröter escribió: Or ask for write access there.
There was no real discussion yet how to handle new packages btw ...
I think we should estabilish something like the Fedora package review guidelines.
Fedora's Package Review Guidelines are a nice checklist for measuring quality of packages, however, in our case, the most important question IMHO should be: "Does this package *need* to be part of the core distribution?". For many packages a home in the buildservice repositories is actually the better option:
- Buildservice packages can be updated after distro release quite easily
(and without wasting space in you repositories)
- Can be provided for released distributions
- For the end-user, using buildservice packages is IMO as easy as using
distribution packages.
There are plenty of small useful packages on the net. And yes, I believe that they need to become part of the core distro. Especially for offliners among us, that download whole repository and use it locally.
And looking at 100 different repositories (Build Service Home projects) is not the same thing as looking into 1 main repository. I prefer to have 1 place to look for packages.
Hello,
Alexey Eremenko írta:
There are plenty of small useful packages on the net. And yes, I believe that they need to become part of the core distro. Especially for offliners among us, that download whole repository and use it locally.
And looking at 100 different repositories (Build Service Home projects) is not the same thing as looking into 1 main repository. I prefer to have 1 place to look for packages.
Full ACK here. Also if something gets into the core distro, then it is tested to work with the rest of the distro. Right now even popular repositories are mutually exclusive. Devel versions could still maintained in the BS. Bye, CzP
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Full ACK here. Also if something gets into the core distro, then it is tested to work with the rest of the distro. Right now even popular repositories are mutually exclusive. Devel versions could still maintained in the BS. Bye,
Not to mention inter-dependencies. If I make a new package that has a dependency on core distro then all is fine, but if my packages have a dependency on third-party packages, and his packages in turn has dependency on some other repository we are returning back into dependency hell.
Good example: -iperf and iperfQt - IP performance test. -iperf is not my package, but I need to copy it into my home project because I developing iperfQt which is a Qt GUI for iperf, which is not core package. I don't want to have a dependency on some one else's home project. Thankfully Qt is :)
Alexey Eremenko wrote:
Not to mention inter-dependencies.
...
Good example: -iperf and iperfQt - IP performance test. -iperf is not my package, but I need to copy it into my home project because I developing iperfQt which is a Qt GUI for iperf, which is not core package. I don't want to have a dependency on some one else's home project.
Then you should talk to each other and put the packages into a common repository. That common repository doesn't necessarily need to be the openSUSE 11.1 DVD, but for instance the benchmark project (*) if it's maintainers like your packages.
(*) https://build.opensuse.org/project/show?project=benchmark
Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, 29 Jul 2008, Michal Marek wrote:
- For the end-user, using buildservice packages is IMO as easy as using
distribution packages.
Not. it is not. But openSUSE 11.0 is going good steps into the right direction. Some Buildservice search and repository integration in the yast package search would be a final step.
For example the package search in yast could have the option to also search the buildservice and allow (easier than now) to register a new project as data source.
Ciao
Dirk Stöcker wrote:
On Tue, 29 Jul 2008, Michal Marek wrote:
- For the end-user, using buildservice packages is IMO as easy as using
distribution packages.
Not. it is not. But openSUSE 11.0 is going good steps into the right direction. Some Buildservice search and repository integration in the yast package search would be a final step.
For example the package search in yast could have the option to also search the buildservice and allow (easier than now) to register a new project as data source.
Right, that statement of mine was a bit exaggerated.
Michal (who sometimes uses software.o.o/search instead of the yast package manager to install packages ;-)). --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Now, what about offliners, that keep everything locally ?
Having too many repositories makes things difficult.
On Tuesday 29 July 2008 16:07:35 Alexey Eremenko wrote:
Now, what about offliners, that keep everything locally ?
Off-liners are decreasing every day.
In the future there will be no off-liners. It costs me 6 Euro per month to have DSL flatrate 24H per day.
On 2008-07-29 14:07:35 +0000, Alexey Eremenko wrote:
Now, what about offliners, that keep everything locally ?
Having too many repositories makes things difficult.
Having one big repository would make things difficult too. I don't want to imagine how much disk space would be needed...
Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Jul 29, 2008 at 2:18 PM, Marcus Hüwe suse-tux@gmx.de wrote:
On 2008-07-29 14:07:35 +0000, Alexey Eremenko wrote:
Now, what about offliners, that keep everything locally ?
Having too many repositories makes things difficult.
Having one big repository would make things difficult too. I don't want to imagine how much disk space would be needed...
Well, we may start integrating small utilities, that are sub <1MB. Then for bigger utilities, we will integrate only if it is justified. (i.e. important piece of software)
On Tue, Jul 29, 2008 at 2:28 PM, Alexey Eremenko al4321@gmail.com wrote:
On Tue, Jul 29, 2008 at 2:18 PM, Marcus Hüwe suse-tux@gmx.de wrote:
On 2008-07-29 14:07:35 +0000, Alexey Eremenko wrote:
Now, what about offliners, that keep everything locally ?
Having too many repositories makes things difficult.
Having one big repository would make things difficult too. I don't want to imagine how much disk space would be needed...
Actually about disk space: Debian 4.0 takes 13 GB of space per 1 architecture (i386+noarch) for 18000 packages. openSUSE 10.3 takes 8 GB of space per 1 arch for 6000 packages.
Which means: openSUSE already has all the big packages, what is lacking are utilities and "helper" packages. Adding many useful utilities (many of whom are CLI) won't make the core distro even 2x bigger than we are now.
If we count the fact that we are not going to add 10000+ utilities overnight, rather it will be a long process lasting several years, then I see no problem at all, since both hard disks becoming big, 50mbps VDSL becoming reality and blu-ray discs of course....
Le mardi 29 juillet 2008, à 15:48 +0200, Dirk Stöcker a écrit :
On Tue, 29 Jul 2008, Michal Marek wrote:
- For the end-user, using buildservice packages is IMO as easy as using
distribution packages.
Not. it is not. But openSUSE 11.0 is going good steps into the right direction. Some Buildservice search and repository integration in the yast package search would be a final step.
For example the package search in yast could have the option to also search the buildservice and allow (easier than now) to register a new project as data source.
(sorry for replying late, got some mail issues)
I do believe that it would be a step forward to have the core official repository and a second repository where "everything else" lives, if only to avoid conflicts. Right now, many people have the same packages in various repositories. Even just using packman creates some issues, so adding a few other repositories can only create a worse situation.
What would be bad about having an openSUSE:Community repository where we can put everything that is not in the core repository (after some review, of course)?
Don't get me wrong: it's good to be able to create repositories on the build service, but I see this more like the places where we can work on the package to do some cool new stuff...
(oh, and I really think it'd be best to have only one repository, but I can understand why we don't want this)
Vincent
On Fri, 1 Aug 2008, Vincent Untz wrote:
What would be bad about having an openSUSE:Community repository where we can put everything that is not in the core repository (after some review, of course)?
Go back in the archives of this list (probably a year or more) and search for the Packman effect (for sure Packman is mentioned in the thread). There was a lengthy discussion, why such a large repository would create more problems, than it solves. Also this thread showed some of the resulting problems.
Ciao
buildservice@lists.opensuse.org
-
Adrian Schröter -
Alexey Eremenko -
Amilcar do Carmo Lucas -
Cristian Rodríguez -
Dirk Stöcker -
Marcus Hüwe -
Michal Marek -
Peter Czanik -
Vincent Untz