[arch-dev-public] Repo Distinctions
So I've been listening to the discussion about what should and shouldn't be in extra so far, and I've come to the following conclusions: 1) Niche is subjective. 2) Even if it weren't, whether a package is "niche" or "mainstream" is not a good criterion for classifying it in one repo or another. 3) Some good criteria for classifying packages in one repo or another are: a) Desire to maintain a package long-term. b) Association with a particular group of people you trust. 4) There are many who actually do trust developers more than TUs. This is not intended as a judgement, rather as an observation. My feeling is that we should have under the developer umbrella a split of the existing [extra] into two repos: [main] - to be in the main repo, a package must be voted in by a majority of the developers; we commit to maintaining these packages over a long period of time, and announce 6-12 months in advance if we're going to remove them (and again, this removal requires a majority vote); there should never be any orphans in here, and we should be extremely stingy about putting packages in here in the first place [extra] - developers can maintain any packages in here they wish; if they decide to orphan them, they must announce that to the developers and TUs and see if anyone wants to take them on; if nobody wants them, they get demoted and orphaned in unsupported so that the community can still benefit from the work they once did This is just a proposal intended as a starting point for discussion. But I think some notion of a supported group of [main] packages that we collectively commit to maintaining will make us feel less bad about a more in-flux [extra]. Also, a clear process about what you do when you orphan a package helps get those packages picked up by those with time or inclination to deal with them. For those who would say: why not just use [community] as the [extra] you're proposing above? The answer: so you can tell which group of individuals is standing behind these packages-- the developers. With that information, you can then decide for yourself who to trust. - P
On Tue, Oct 16, 2007 at 06:35:47PM -0400, Paul Mattal wrote:
So I've been listening to the discussion about what should and shouldn't be in extra so far, and I've come to the following conclusions:
1) Niche is subjective.
2) Even if it weren't, whether a package is "niche" or "mainstream" is not a good criterion for classifying it in one repo or another.
3) Some good criteria for classifying packages in one repo or another are:
a) Desire to maintain a package long-term. b) Association with a particular group of people you trust.
4) There are many who actually do trust developers more than TUs. This is not intended as a judgement, rather as an observation.
My feeling is that we should have under the developer umbrella a split of the existing [extra] into two repos:
[main] - to be in the main repo, a package must be voted in by a majority of the developers; we commit to maintaining these packages over a long period of time, and announce 6-12 months in advance if we're going to remove them (and again, this removal requires a majority vote); there should never be any orphans in here, and we should be extremely stingy about putting packages in here in the first place
[extra] - developers can maintain any packages in here they wish; if they decide to orphan them, they must announce that to the developers and TUs and see if anyone wants to take them on; if nobody wants them, they get demoted and orphaned in unsupported so that the community can still benefit from the work they once did
This is just a proposal intended as a starting point for discussion. But I think some notion of a supported group of [main] packages that we collectively commit to maintaining will make us feel less bad about a more in-flux [extra]. Also, a clear process about what you do when you orphan a package helps get those packages picked up by those with time or inclination to deal with them.
For those who would say: why not just use [community] as the [extra] you're proposing above? The answer: so you can tell which group of individuals is standing behind these packages-- the developers. With that information, you can then decide for yourself who to trust.
Sounds like making a mountain out of a mole hill to me. What's wrong with something simple like... extra is for packages that aren't integral to the distro which the devs feel like maintaining, and community is for packages tus feel like maintaining, and unsupported is for things no one wants to maintain? -S
On Tue, 16 Oct 2007, Simo Leone wrote:
On Tue, Oct 16, 2007 at 06:35:47PM -0400, Paul Mattal wrote:
So I've been listening to the discussion about what should and shouldn't be in extra so far, and I've come to the following conclusions:
1) Niche is subjective.
2) Even if it weren't, whether a package is "niche" or "mainstream" is not a good criterion for classifying it in one repo or another.
3) Some good criteria for classifying packages in one repo or another are:
a) Desire to maintain a package long-term. b) Association with a particular group of people you trust.
4) There are many who actually do trust developers more than TUs. This is not intended as a judgement, rather as an observation.
My feeling is that we should have under the developer umbrella a split of the existing [extra] into two repos:
[main] - to be in the main repo, a package must be voted in by a majority of the developers; we commit to maintaining these packages over a long period of time, and announce 6-12 months in advance if we're going to remove them (and again, this removal requires a majority vote); there should never be any orphans in here, and we should be extremely stingy about putting packages in here in the first place
[extra] - developers can maintain any packages in here they wish; if they decide to orphan them, they must announce that to the developers and TUs and see if anyone wants to take them on; if nobody wants them, they get demoted and orphaned in unsupported so that the community can still benefit from the work they once did
This is just a proposal intended as a starting point for discussion. But I think some notion of a supported group of [main] packages that we collectively commit to maintaining will make us feel less bad about a more in-flux [extra]. Also, a clear process about what you do when you orphan a package helps get those packages picked up by those with time or inclination to deal with them.
For those who would say: why not just use [community] as the [extra] you're proposing above? The answer: so you can tell which group of individuals is standing behind these packages-- the developers. With that information, you can then decide for yourself who to trust.
Sounds like making a mountain out of a mole hill to me. What's wrong with something simple like... extra is for packages that aren't integral to the distro which the devs feel like maintaining, and community is for packages tus feel like maintaining, and unsupported is for things no one wants to maintain?
-S
I agree with Simo here. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On 10/16/07, Simo Leone <simo@archlinux.org> wrote:
Sounds like making a mountain out of a mole hill to me.
At first, I didn't think Simo was right. I thought this would go the way of a sane discussion. But in typical devland fashion, we decided to stab this issue to death with the knives of blather. Let me see if I can steer this cart away from the cliff a bit, but we might be going too fast to abort. Everyone makes these grand claims like "repoman will fix THAT" and "lets move TUs up and start 'firing' crappy packagers" and all these sorts of things. Don't get me wrong, they're perfectly valid suggestions and good ones. The problem is the timeline. This is always an issue. A lot of these suggestions will take a large chunk of work, and a lot of effort. I know how our dev team works. If we actually decide that these things are a good idea, there will be two people doing the work while everyone else keeps wondering why it's not done. So we simply can't do that. Fact. We need to move in baby steps. We WILL have a problem implementing these large sweeping suggestions, so here's the question I pose to all of you who have very strong opinions: What's the first step? I don't want to look at these giant "we can finish this in 3 months" solutions. What I want is a "here's a small step that helps solve it and works toward the larger solution". The other option, of course, is for someone to sit down, write some code, and "put your money where your mouth is", as they say.
Aaron Griffin wrote:
On 10/16/07, Simo Leone <simo@archlinux.org> wrote:
Sounds like making a mountain out of a mole hill to me.
At first, I didn't think Simo was right. I thought this would go the way of a sane discussion.
But in typical devland fashion, we decided to stab this issue to death with the knives of blather.
Let me see if I can steer this cart away from the cliff a bit, but we might be going too fast to abort.
Everyone makes these grand claims like "repoman will fix THAT" and "lets move TUs up and start 'firing' crappy packagers" and all these sorts of things. Don't get me wrong, they're perfectly valid suggestions and good ones.
The problem is the timeline. This is always an issue. A lot of these suggestions will take a large chunk of work, and a lot of effort.
I know how our dev team works. If we actually decide that these things are a good idea, there will be two people doing the work while everyone else keeps wondering why it's not done.
So we simply can't do that. Fact.
We need to move in baby steps. We WILL have a problem implementing these large sweeping suggestions, so here's the question I pose to all of you who have very strong opinions:
What's the first step?
Create [mantle]. Vote packages into it by 50%+ vote of dev team. See what happens and what is left in [extra]. Auction any orphans off to other devs and/or TUs to put in community. These would be the first few steps. - P
On 10/17/07, Paul Mattal <paul@mattal.com> wrote:
Create [mantle]. Vote packages into it by 50%+ vote of dev team. See what happens and what is left in [extra]. Auction any orphans off to other devs and/or TUs to put in community.
These would be the first few steps.
Great. This is what I was looking for 8) What other "next steps" do we have floating around? I have to admit, I got a bit lost reading this thread so I didn't distill a lot of the content. Side note though, the [core] and [mantle] thing is cool and all, but [crust] sounds a little goofy 8) It makes me think of pizza.
Aaron Griffin wrote:
On 10/17/07, Paul Mattal <paul@mattal.com> wrote:
Create [mantle]. Vote packages into it by 50%+ vote of dev team. See what happens and what is left in [extra]. Auction any orphans off to other devs and/or TUs to put in community.
These would be the first few steps.
I should also say I'm willing to DO these steps, create the repo, work with someone to figure out how best to transition users to having the extra tier, shepherd the whole adoption/redistribution/voting process. There's some items I don't think I have the gerolde access to do, so I'd have to be paired up with someone for that part, or given access.
Side note though, the [core] and [mantle] thing is cool and all, but [crust] sounds a little goofy 8) It makes me think of pizza.
At first, that was exactly my reaction. But taken as a set of 3, they complete the analogy nicely, and the name is at least more meaningful than extra, I think. - P
Wednesday 17 October 2007, Paul Mattal wrote: | > Side note though, the [core] and [mantle] thing is cool and all, | > but [crust] sounds a little goofy 8) It makes me think of pizza. | | At first, that was exactly my reaction. But taken as a set of 3, | they complete the analogy nicely, and the name is at least more | meaningful than extra, I think. blame me, sorry for this names :) ... i just extrapolated them from geology .. taking the fact that we have a core. see here: http://en.wikipedia.org/wiki/Crust_(geology) i'm also for keeping the proportion of official dev-maintained packages as they are distributed for our planet. mantle is much bigger than the core and the crust is really just superficial happenings. everything not crust is community or unsupported. i know that this would mean removing some pkgs from official dev-maintained repos but such a cleanup is needed because it was never done since beginning of arch. one important sidenote: creating the mantle and crust should happen before releasing another iso! - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Wed, 17 Oct 2007, Paul Mattal wrote:
Aaron Griffin wrote:
On 10/16/07, Simo Leone <simo@archlinux.org> wrote:
Sounds like making a mountain out of a mole hill to me.
At first, I didn't think Simo was right. I thought this would go the way of a sane discussion.
But in typical devland fashion, we decided to stab this issue to death with the knives of blather.
Let me see if I can steer this cart away from the cliff a bit, but we might be going too fast to abort.
Everyone makes these grand claims like "repoman will fix THAT" and "lets move TUs up and start 'firing' crappy packagers" and all these sorts of things. Don't get me wrong, they're perfectly valid suggestions and good ones.
The problem is the timeline. This is always an issue. A lot of these suggestions will take a large chunk of work, and a lot of effort.
I know how our dev team works. If we actually decide that these things are a good idea, there will be two people doing the work while everyone else keeps wondering why it's not done.
So we simply can't do that. Fact.
We need to move in baby steps. We WILL have a problem implementing these large sweeping suggestions, so here's the question I pose to all of you who have very strong opinions:
What's the first step?
Create [mantle]. Vote packages into it by 50%+ vote of dev team. See what happens and what is left in [extra]. Auction any orphans off to other devs and/or TUs to put in community.
These would be the first few steps.
- P
Shouldn't the first step be to identify clearly what current or potential problems are we trying to solve? Maybe that whole repo reorganisation is not needed after all. If the main issue here is a potential increase in the number of orphans after the current cleanup, I posted a simple solution in another thread that would work with the current repo setup with zero work involved. BTW, we should wait until the cleqanup/adoption is completed before doing any repo work. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Eric Belanger wrote:
Shouldn't the first step be to identify clearly what current or potential problems are we trying to solve? Maybe that whole repo reorganisation is not needed after all.
Here are some I'm trying to solve: 1) Unclarity about what our committment is to packages in various repos. We need some clear way for the dev team to commit to maintaining a package in the long term, and some way to easily identify and track packages identified thusly. 2) Gross numbers of orphans everywhere and no clear method to follow to proceed to eliminate them on an ongoing basis. (not saying your proposal doesn't address this.. but you asked for the problem list) 3) Reducing the inefficiencies in the tools that developers and community members have at their disposal currently to contribute their stellar efforts for the benefit of everyone. Specifically: a) Moving packages from one repo to another is hard. b) Placing packages in multiple repos is hard. c) Continued separate-track development on a package while in testing is hard. d) Tracking multiple binary repos for different architectures is hard. e) Maintenance of a package by more than one person is hard. This is just a start. All of these goals can be served or affected by the choices we make for repo design.
If the main issue here is a potential increase in the number of orphans after the current cleanup, I posted a simple solution in another thread that would work with the current repo setup with zero work involved.
This is one of the main issues, yes.
BTW, we should wait until the cleqanup/adoption is completed before doing any repo work.
That might make sense, depending on whether or not this would help or get in the way of the cleanup/adoption effort. - P
2007/10/17, Paul Mattal <paul@mattal.com>:
Eric Belanger wrote:
Shouldn't the first step be to identify clearly what current or potential problems are we trying to solve? Maybe that whole repo reorganisation is not needed after all.
Absolutely agree.
Here are some I'm trying to solve:
1) Unclarity about what our committment is to packages in various repos. We need some clear way for the dev team to commit to maintaining a package in the long term, and some way to easily identify and track packages identified thusly.
2) Gross numbers of orphans everywhere and no clear method to follow to proceed to eliminate them on an ongoing basis. (not saying your proposal doesn't address this.. but you asked for the problem list)
3) Reducing the inefficiencies in the tools that developers and community members have at their disposal currently to contribute their stellar efforts for the benefit of everyone. Specifically:
a) Moving packages from one repo to another is hard. b) Placing packages in multiple repos is hard. c) Continued separate-track development on a package while in testing is hard. d) Tracking multiple binary repos for different architectures is hard. e) Maintenance of a package by more than one person is hard.
This is just a start. All of these goals can be served or affected by the choices we make for repo design.
This is OK, but this: 2007/10/17, Paul Mattal <paul@mattal.com>:
Aaron Griffin wrote:
What's the first step?
Create [mantle]. Vote packages into it by 50%+ vote of dev team. See what happens and what is left in [extra]. Auction any orphans off to other devs and/or TUs to put in community.
These would be the first few steps.
is absolutely bad as a first step. I don't understand how this can be a good first step to archieve all you wrote above.
If the main issue here is a potential increase in the number of orphans after the current cleanup, I posted a simple solution in another thread that would work with the current repo setup with zero work involved.
This is one of the main issues, yes.
BTW, we should wait until the cleqanup/adoption is completed before doing any repo work.
That might make sense, depending on whether or not this would help or get in the way of the cleanup/adoption effort.
I agree with Eric here. IMO package cleanup shouldn't wait for the result of this discussion. -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
1) Unclarity about what our committment is to packages in various repos. We need some clear way for the dev team to commit to maintaining a package in the long term, and some way to easily identify and track packages identified thusly.
2) Gross numbers of orphans everywhere and no clear method to follow to proceed to eliminate them on an ongoing basis. (not saying your proposal doesn't address this.. but you asked for the problem list)
This is OK, but this:
2007/10/17, Paul Mattal <paul@mattal.com>:
Aaron Griffin wrote:
What's the first step? Create [mantle]. Vote packages into it by 50%+ vote of dev team. See what happens and what is left in [extra]. Auction any orphans off to other devs and/or TUs to put in community.
These would be the first few steps.
is absolutely bad as a first step. I don't understand how this can be a good first step to archieve all you wrote above.
These first steps are intended to achieve #1 and #2, by creating a repo in which devs clearly have committed to long-term care of the packages and by eliminating orphans and demonstrating how to keep them eliminated on an ongoing basis. - P
On 10/18/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/17, Paul Mattal <paul@mattal.com>:
Create [mantle]. Vote packages into it by 50%+ vote of dev team. See what happens and what is left in [extra]. Auction any orphans off to other devs and/or TUs to put in community.
These would be the first few steps.
is absolutely bad as a first step. I don't understand how this can be a good first step to archieve all you wrote above.
Could you explain HOW rather than just nay-saying it? For those of us that don't get what you're implying, can you explain how it doesn't help alleviate the issues listed?
On Wed, 17 Oct 2007, Paul Mattal wrote:
Eric Belanger wrote:
Shouldn't the first step be to identify clearly what current or potential problems are we trying to solve? Maybe that whole repo reorganisation is not needed after all.
Here are some I'm trying to solve:
1) Unclarity about what our committment is to packages in various repos. We need some clear way for the dev team to commit to maintaining a package in the long term, and some way to easily identify and track packages identified thusly.
I think that we already have a good idea about the importance of packages without the need to be in a specific repo. I'm also concerned about the guidelines that we will need to follow to determine if a package should go in mantle or crust. If they are too strict, we'll end up with only a few package in mantle. That won't help much as I just said earlier: no need to have X in a mantle repo to know that it'll stay in the distro. On the contrary, if they are too loose almost all packages will end up in mantle, as Damir suggested, with maybe 30 or so packages in crust. We could even end up with a practically empty crust repo at one point if its packages gets orphaned and removed. Is it worth all that inconvenience to our users and our work and time to just separate a few packages from the rest? I don't think so as no harm it done by keeping them with the rest and dealing with them when they'll become orphans. At last, if the guidelines are anywhere between strict and loose, we risk going into a bikeshed discussion with for result two repos with packages more or less randomly distributed between them.
2) Gross numbers of orphans everywhere and no clear method to follow to proceed to eliminate them on an ongoing basis. (not saying your proposal doesn't address this.. but you asked for the problem list)
The way I see it, after the current cleanup/adoption process, there will be no orphans left. The packages that we need to keep (dependencies, etc) will be adopted and/or assigned. the rest will be moved to unsupported. Future orphans can be delt on a case-by case basis with what I suggested. I'll repost it here in case it got lost in the numerous threads posted lately (it's open to discussion/modifications: When he orphans it he post to the ML so that we know about the issue and to perhaps speed up its readoption by another dev. If no dev wants to adopt it and if its movable to community (above reasons), we ask if a TU wants to adopt it. If so, we move the package in community. If no TU wants to keep it, we could keep it in extra, especially if it's up-to-date and in working condition. We might be able to maintain it as an orphan as a group effort if people check it regularly for update and fixes. I don't have any problem in having a few orphans. If the package becomes stale or a pain to update/maintain, we can ask again the TU and this time move it to unsupported if no one wants it. We could also do the same if the number of orphans becomes too large to handle.
3) Reducing the inefficiencies in the tools that developers and community members have at their disposal currently to contribute their stellar efforts for the benefit of everyone. Specifically:
a) Moving packages from one repo to another is hard. b) Placing packages in multiple repos is hard. c) Continued separate-track development on a package while in testing is hard. d) Tracking multiple binary repos for different architectures is hard. e) Maintenance of a package by more than one person is hard.
The above issues will be better solved by using other means than a split-up of extra, like switching to a new SCM as Jason pointed out in another thread.
This is just a start. All of these goals can be served or affected by the choices we make for repo design.
If the main issue here is a potential increase in the number of orphans after the current cleanup, I posted a simple solution in another thread that would work with the current repo setup with zero work involved.
This is one of the main issues, yes.
BTW, we should wait until the cleqanup/adoption is completed before doing any repo work.
That might make sense, depending on whether or not this would help or get in the way of the cleanup/adoption effort.
We should focus our effort on the cleanup/adoption to complete it once for all. It has been started months ago. The longer we keep these packages, the more effort/time we put in them for updates/fixes/rebuilds for .so bump. Time and effort that could be better spent. Plus they clutter the package interface.
- P
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Aaron Griffin wrote:
On 10/16/07, Simo Leone <simo@archlinux.org> wrote:
Sounds like making a mountain out of a mole hill to me.
At first, I didn't think Simo was right. I thought this would go the way of a sane discussion.
But in typical devland fashion, we decided to stab this issue to death with the knives of blather.
Let me see if I can steer this cart away from the cliff a bit, but we might be going too fast to abort.
Everyone makes these grand claims like "repoman will fix THAT" and "lets move TUs up and start 'firing' crappy packagers" and all these sorts of things. Don't get me wrong, they're perfectly valid suggestions and good ones.
The problem is the timeline. This is always an issue. A lot of these suggestions will take a large chunk of work, and a lot of effort.
I know how our dev team works. If we actually decide that these things are a good idea, there will be two people doing the work while everyone else keeps wondering why it's not done.
So we simply can't do that. Fact.
very true.
We need to move in baby steps. We WILL have a problem implementing these large sweeping suggestions, so here's the question I pose to all of you who have very strong opinions:
What's the first step?
Step 1 (for the BDFL) - (1 day): Let's create an 'Arch Linux Packaging Standards Group' or something to that effect. I suggest that Aaron our dear BDFL selects 3 ppl to make up this group. These persons should be the *best* (in Aaron's opinion - use other's opinions too? but Aaron should make the appointment, so we don't waste time deciding) Packagers on Archlinux Development Team. Step 2 (for the committee) - (1 weekend for version one. we'll roll with that for now): Draw up all the currently known metrics that namcap judges packages by and all the current warnings that makepkg issues. Jason can help the committee with this. (if they ask nicely :P) Step 3(for the committee - (1 weekend for version one)): Which of these MUST be passed before a package is acceptable. The rest should happen after these have been completed. Step 4 - (i can't put time here, but i'm serious about putting my money where my mouth is). coders work on this. I'm ready to put my money where my mouth is and get work done here: - modify namcap and makepkg to spit out metrics in a more obvious way to rhyme with the results of step 3 above. Step 5 - (a one month test period is okay to shake out the version one of the tools). Test these tools to death and begin to use these with our current infrastructure. Are the above steps granular enough? I'll want to stop here... if we get here... the journey is 50% completed. The next steps will involve the actual collapsing of [extra] and [community] into eachh other... but a tool needs to be in place before that happens. But if we can get from step 1 to 5... the hardest parts will be done. cheers, Essien PS: I won't have internet again till some time tmrw. can't reply :(
I don't want to look at these giant "we can finish this in 3 months" solutions. What I want is a "here's a small step that helps solve it and works toward the larger solution".
The other option, of course, is for someone to sit down, write some code, and "put your money where your mouth is", as they say.
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
On 10/16/07, Paul Mattal <paul@mattal.com> wrote:
So I've been listening to the discussion about what should and shouldn't be in extra so far, and I've come to the following conclusions:
1) Niche is subjective.
2) Even if it weren't, whether a package is "niche" or "mainstream" is not a good criterion for classifying it in one repo or another.
3) Some good criteria for classifying packages in one repo or another are:
a) Desire to maintain a package long-term. b) Association with a particular group of people you trust.
4) There are many who actually do trust developers more than TUs. This is not intended as a judgement, rather as an observation.
My feeling is that we should have under the developer umbrella a split of the existing [extra] into two repos:
[main] - to be in the main repo, a package must be voted in by a majority of the developers; we commit to maintaining these packages over a long period of time, and announce 6-12 months in advance if we're going to remove them (and again, this removal requires a majority vote); there should never be any orphans in here, and we should be extremely stingy about putting packages in here in the first place
[extra] - developers can maintain any packages in here they wish; if they decide to orphan them, they must announce that to the developers and TUs and see if anyone wants to take them on; if nobody wants them, they get demoted and orphaned in unsupported so that the community can still benefit from the work they once did
This is just a proposal intended as a starting point for discussion. But I think some notion of a supported group of [main] packages that we collectively commit to maintaining will make us feel less bad about a more in-flux [extra]. Also, a clear process about what you do when you orphan a package helps get those packages picked up by those with time or inclination to deal with them.
For those who would say: why not just use [community] as the [extra] you're proposing above? The answer: so you can tell which group of individuals is standing behind these packages-- the developers. With that information, you can then decide for yourself who to trust.
This is definitely an interesting proposal. See, what we have here is two clear camps that define [extra] different ways - packages developers maintain, or packages the distro needs. This isn't an attempt to compromise or combine those ideas, it's an attempt to embrace them as different ideas. I think this is great. The problem I see is that it's "more repos". It's more of a headache. I dunno. I know that sounds like a petty reason, but that's the reason this doesn't sit too well with me. In reality, I like this distinction, I just think we should try and use the repos we already have. Define [extra] the way you defined [main] and let developers maintain their own packages in [community]. But that's my opinion, and not too many people agree with me on that one.
Wednesday 17 October 2007, Aaron Griffin wrote: | This is definitely an interesting proposal. See, what we have here | is two clear camps that define [extra] different ways - packages | developers maintain, or packages the distro needs. they are not really that cleanly separated camps. sometimes the distro does not know what it needs but some devs do. devs are mostly men, mostly involved in IT business and mostly young people. do you know what pkgs are essential to a female scientist who does research in life sciences? if gimp is essential for the distro, then R or labplot is essential for the distro as well. :) | This isn't an attempt to compromise or combine those ideas, it's | an attempt to embrace them as different ideas. I think this is | great. i cannot agree more :) | In reality, I like this distinction, I just think we should try | and use the repos we already have. Define [extra] the way you | defined [main] and let developers maintain their own packages in | [community]. But that's my opinion, and not too many people agree | with me on that one. i don't. some pkgs need to be in a dev-official repo if not because of public relations reasons (ok, not only because of this reasons of course, but i think you know what i mean). - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Damir Perisa wrote:
Wednesday 17 October 2007, Aaron Griffin wrote: | This is definitely an interesting proposal. See, what we have here | is two clear camps that define [extra] different ways - packages | developers maintain, or packages the distro needs.
they are not really that cleanly separated camps.
In fact, the thing to note is that they aren't really camps or people taking sides.. it's just about the reality of free agents working in a free system scratching their own itches. We want to capitalize on all the itch-scratching going on so it can benefit us all! If a developer needs to maintain a package, and he can't do so in any repo we provide, he'll have to go do it in private.. and the community suffers from not being able to benefit as effectively from his creative energy. Instead, we should give him a repo where he can maintain any package he wants for as long as he wants, and require him to clean up after himself and hand the package off or demote it to unsupported when he's had enough of it. Right now, for instance, I maintain about 30 packages in a private repo for this very reason.. I was not ready to commit Arch long-term, short-term, or otherwise to have to deal with these packages. If we made it clear that long-term commitment was specifically not guaranteed by extra, and created a clear path for passing packages off to others when devs are no longer interested in maintaining them, it would really encourage more developers to share all the quality work they're doing. - P P.S. Note also that the orphaning problem will be helped immensely by multiple maintainers. If there are 3 developers registered as maintainers on a package, it is much less likely that all three will suddenly drop it in disinterest. Once we get this in place, we should encourage keeping a minimum of 2 maintainers for each package in [core].
2007/10/17, Paul Mattal <paul@mattal.com>:
Damir Perisa wrote:
Wednesday 17 October 2007, Aaron Griffin wrote: | This is definitely an interesting proposal. See, what we have here | is two clear camps that define [extra] different ways - packages | developers maintain, or packages the distro needs.
they are not really that cleanly separated camps.
In fact, the thing to note is that they aren't really camps or people taking sides.. it's just about the reality of free agents working in a free system scratching their own itches. We want to capitalize on all the itch-scratching going on so it can benefit us all! If a developer needs to maintain a package, and he can't do so in any repo we provide, he'll have to go do it in private.. and the community suffers from not being able to benefit as effectively from his creative energy.
Again - what's wrong with committing such packages in community? Who's prohibitting that dev from doing so except himself?
Instead, we should give him a repo where he can maintain any package he wants for as long as he wants, and require him to clean up after himself and hand the package off or demote it to unsupported when he's had enough of it.
What it gives to users? We'll end up in many repos as it was with TUR before AUR was created.
Right now, for instance, I maintain about 30 packages in a private repo for this very reason.. I was not ready to commit Arch long-term, short-term, or otherwise to have to deal with these packages.
Again - just put them in community repo (or unsupported if you like so). -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
2007/10/17, Paul Mattal <paul@mattal.com>:
Wednesday 17 October 2007, Aaron Griffin wrote: | This is definitely an interesting proposal. See, what we have here | is two clear camps that define [extra] different ways - packages | developers maintain, or packages the distro needs.
they are not really that cleanly separated camps. In fact, the thing to note is that they aren't really camps or people taking sides.. it's just about the reality of free agents working in a free system scratching their own itches. We want to capitalize on all
Damir Perisa wrote: the itch-scratching going on so it can benefit us all! If a developer needs to maintain a package, and he can't do so in any repo we provide, he'll have to go do it in private.. and the community suffers from not being able to benefit as effectively from his creative energy.
Again - what's wrong with committing such packages in community? Who's prohibitting that dev from doing so except himself?
The problem is that the level of trust placed in dev packages is, on the whole, higher, and when the TU group takes control of the package when it is placed in community, it's now the TU group that controls the package and makes the guarantees. And, currently, it is an additional burden that the dev must use two non-unified systems to manage his packages, and it is cumbersome to move packages between them. Furthermore, the devs when placing packages in community now need to subscribe to tur-users mailing list and read and abide by all the TU rules. It's two parallel sets of infrastructure which wastes the dev's time. Finally, when the dev leaves, it's now extra burden for the TUs to triage and redistribute/clean out his packages.
Instead, we should give him a repo where he can maintain any package he wants for as long as he wants, and require him to clean up after himself and hand the package off or demote it to unsupported when he's had enough of it.
What it gives to users? We'll end up in many repos as it was with TUR before AUR was created.
Not each dev his own repo, all the devs 1 repo ([crust] by Damir's naming scheme) where they don't have to worry about long-term committment. If tomorrow I decide I don't really want the hassle of this package anymore, I follow a protocol to orphan it, see if anyone else wants it, then I demote it to wherever it should go, in a certain time frame.
Right now, for instance, I maintain about 30 packages in a private repo for this very reason.. I was not ready to commit Arch long-term, short-term, or otherwise to have to deal with these packages.
Again - just put them in community repo (or unsupported if you like so).
I prefer not to turn them over to the TUs. They are in some cases important packages that I and others rely on and because they're so essential, I'm not willing to trust them to any but the devs. - P
Aaron Griffin wrote:
On 10/16/07, Paul Mattal <paul@mattal.com> wrote:
So I've been listening to the discussion about what should and shouldn't be in extra so far, and I've come to the following conclusions:
1) Niche is subjective.
2) Even if it weren't, whether a package is "niche" or "mainstream" is not a good criterion for classifying it in one repo or another.
3) Some good criteria for classifying packages in one repo or another are:
a) Desire to maintain a package long-term. b) Association with a particular group of people you trust.
4) There are many who actually do trust developers more than TUs. This is not intended as a judgement, rather as an observation.
My feeling is that we should have under the developer umbrella a split of the existing [extra] into two repos:
[main] - to be in the main repo, a package must be voted in by a majority of the developers; we commit to maintaining these packages over a long period of time, and announce 6-12 months in advance if we're going to remove them (and again, this removal requires a majority vote); there should never be any orphans in here, and we should be extremely stingy about putting packages in here in the first place
[extra] - developers can maintain any packages in here they wish; if they decide to orphan them, they must announce that to the developers and TUs and see if anyone wants to take them on; if nobody wants them, they get demoted and orphaned in unsupported so that the community can still benefit from the work they once did
This is just a proposal intended as a starting point for discussion. But I think some notion of a supported group of [main] packages that we collectively commit to maintaining will make us feel less bad about a more in-flux [extra]. Also, a clear process about what you do when you orphan a package helps get those packages picked up by those with time or inclination to deal with them.
For those who would say: why not just use [community] as the [extra] you're proposing above? The answer: so you can tell which group of individuals is standing behind these packages-- the developers. With that information, you can then decide for yourself who to trust.
This is definitely an interesting proposal. See, what we have here is two clear camps that define [extra] different ways - packages developers maintain, or packages the distro needs.
This isn't an attempt to compromise or combine those ideas, it's an attempt to embrace them as different ideas. I think this is great.
The problem I see is that it's "more repos". It's more of a headache. I dunno. I know that sounds like a petty reason, but that's the reason this doesn't sit too well with me.
In reality, I like this distinction, I just think we should try and use the repos we already have. Define [extra] the way you defined [main] and let developers maintain their own packages in [community]. But that's my opinion, and not too many people agree with me on that one.
This post and Damir's highlight to me the increased importance of the strict rules for orphaning packages above all. However, I think this only works well when the boundaries/commitments are clear and everyone has buy-in. It's a lot easier to say to a group of developers "guys, please pick up the orphaned packages from this developer who left in [mantle]" when those developers voted to support that package long-term in the first place. I know I'd be more inclined to make the effort to pick up those packages. To Aaron's point about too many repos, I would say: There's no good reason why you shouldn't be able to move packages easily from one repo to another with one commandline-- that's what repoman is trying to achieve. When repos are really that lightweight it stops being a big deal if you have one more and starts being beneficial to have a more detailed classification of your packages. Of course, if the argument is that devs should maintain packages in [community] because the distinction between devs and TUs isn't important, another solution would be to flatten things and have [core], [mantle] and [extra] and let TUs and devs maintain packages in [extra]. But I still think it's worth separating the devs and the TUs.. this is not to say we shouldn't poach regularly from the TU pool to devs, but the TU post is a great way to get yourself trained to be a good dev. Look at how many came through that way! - P
Wednesday 17 October 2007, Paul Mattal wrote: | However, I think this only works well when the | boundaries/commitments are clear and everyone has buy-in. It's a | lot easier to say to a group of developers "guys, please pick up | the orphaned packages from this developer who left in [mantle]" | when those developers voted to support that package long-term in | the first place. I know I'd be more inclined to make the effort to | pick up those packages. exactly :) | To Aaron's point about too many repos, I would say: There's no | good reason why you shouldn't be able to move packages easily from | one repo to another with one commandline-- that's what repoman is | trying to achieve. When repos are really that lightweight it stops | being a big deal if you have one more and starts being beneficial | to have a more detailed classification of your packages. the "difficult" step is to include a new repo that keeps essential pkgs. changing repo layout has direct effect to the ISO functionability or not (old isos do not know about core or mantle). therefore now is the time to such changes if we need to make them. a clean 2007.10 "Milestone" with the repos [core] - devs [mantle] - devs [extra] - devs [community] - TUs, (devs) [unstable] (opposing core,mantle,extra for devel versions) [testing] (opposing core,mantle,extra for pkgs under testing) would be a quite stable layout for the future. instead of letting TUs commiting to [extra], i would rather promote mature TUs who are good maintainers to official devs. in the hope that the quality does not go down ;) the following criteria i would propose for the packages in the repos [core]* - pkg essential to system [mantle]* - pkg is an essential dependency to other pkgs [extra]** - devs (uses it and) willing to maintain a pkg [community]*** - TUs (uses it and) willing to maintain a pkg [unstable]** - pkg is developemental branch of a project [testing] - testing condition *) orphan pkg maximal time 1 weeks **) orphan pkg maximal time 1 months ***) orphan pkg maximal time 3 months all this is just an idea... feel free to comment and change where you see fit :) sleep well... i'm gone to bed :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Tue, 16 Oct 2007, Paul Mattal wrote:
However, I think this only works well when the boundaries/commitments are clear and everyone has buy-in. It's a lot easier to say to a group of developers "guys, please pick up the orphaned packages from this developer who left in [mantle]" when those developers voted to support that package long-term in the first place. I know I'd be more inclined to make the effort to pick up those packages.
I'm not sure about that. We are having problems finding maintainers for the core packages, in fact, some of them are still orphan. I can't think why people would be more inclined to adopt packages in [mantle] when being in core is not sufficient to incite interest in potential maintainers. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Eric Belanger wrote:
On Tue, 16 Oct 2007, Paul Mattal wrote:
However, I think this only works well when the boundaries/commitments are clear and everyone has buy-in. It's a lot easier to say to a group of developers "guys, please pick up the orphaned packages from this developer who left in [mantle]" when those developers voted to support that package long-term in the first place. I know I'd be more inclined to make the effort to pick up those packages.
I'm not sure about that. We are having problems finding maintainers for the core packages, in fact, some of them are still orphan. I can't think why people would be more inclined to adopt packages in [mantle] when being in core is not sufficient to incite interest in potential maintainers.
I think it's buy-in. I think you'd be surprised at how few packages 50% of the developers would agree to have in [mantle].. or [core] for that matter. - P
2007/10/17, Paul Mattal <paul@mattal.com>:
To Aaron's point about too many repos, I would say: There's no good reason why you shouldn't be able to move packages easily from one repo to another with one commandline-- that's what repoman is trying to achieve. When repos are really that lightweight it stops being a big deal if you have one more and starts being beneficial to have a more detailed classification of your packages.
Repoman? Until it'll became a reality - it annoys me when it gets mentioned as a solution to anything. Sorry. :-/ What about all those users who will have to change their pacman.conf every time? The separation of extra gives no good results, zero, void, nil.
Of course, if the argument is that devs should maintain packages in [community] because the distinction between devs and TUs isn't important, another solution would be to flatten things and have [core], [mantle] and [extra] and let TUs and devs maintain packages in [extra].
Another thing would be to have community integrated in extra. This would also eliminate this issue that is annoying for users and TUs in current situation: 1) packages in community are built against core/extra: 2) testing is filled with db/openssl/gnome/anything-with-so-bump packages issue #1: users that use testing have to rebuild their community packages by themselves 3) packages get moved from testing to core/extra - at this time all needed packages are already rebuilt so nothing in core/extra gets broken issue #2: all community packages that depend on those moved packages are broken now. Users start complaining, TUs are in a rush for rebuilds. With either community-testing repo or community integrated into extra these issues disappear.
But I still think it's worth separating the devs and the TUs.. this is not to say we shouldn't poach regularly from the TU pool to devs, but the TU post is a great way to get yourself trained to be a good dev. Look at how many came through that way!
Separation of devs and TUs is not the same as separation of their packages into different repos just by factor of package ownership. Seriously, what's wrong with main/mantle packages staying in extra and moving unimportant to community? What's the difference between packages maintained by developers and _trusted_ users? Community packages are not system-critical anyway. -- Roman Kyrylych (Роман Кирилич)
sorry guys... i've been battling internet connection issues, so i have a lorry load of mails to catch up on. This issue is pretty close to my nuggin, and i've harped on it before so here goes my 2[insert favourite coin currency here] Roman Kyrylych wrote:
2007/10/17, Paul Mattal <paul@mattal.com>:
What about all those users who will have to change their pacman.conf every time?
The separation of extra gives no good results, zero, void, nil.
I agree. The only thing it creates is a hierarchical distinction b/w "very official packages" and "not so very very official packages" (oh! and it applies those same labels to the ppl _NOT_ allowed to maintain packages in the said repos.
Of course, if the argument is that devs should maintain packages in [community] because the distinction between devs and TUs isn't important, another solution would be to flatten things and have [core], [mantle] and [extra] and let TUs and devs maintain packages in [extra].
Another thing would be to have community integrated in extra.
This has always been my preferred solution. Heresy you may say, but just sit back and think of it. Some developers prefer packaging work and others prefer tool-chain kinda work. If we could clone those that prefer packaging work, would it increase the amount of high quality and maintained packages in [extra] ? (can i get a big "oh... yeah!") (mooo!) I think with current cloning techniques its possible to take our best [extra] packager and clone him/her. I swear I saw it on tv last week. The took this guy... and they put him in a class and he first documented what he did and worked through with others untill first the _imbibed_ what he was teaching them to the letter, then he let them loose. This cloning technique eventually raised some clones who where in a lot of ways better than the original specimen (yeah... it blew the researchers mind's too!) joking aside though. I think we just need to actually DOCUMENT a strict packaging standard (this exists already. no?), and then open up the flood gates to new upcoming would be _packagers_. No distinctions... just one high quality highly udated repository.
But I still think it's worth separating the devs and the TUs.. this is not to say we shouldn't poach regularly from the TU pool to devs, but the TU post is a great way to get yourself trained to be a good dev. Look at how many came through that way!
Instead of devs and TUs... i'd call them Developers and Packagers. Small distinction yes, but in the light of what i'm suggesting above... the net gain would be huge.
Separation of devs and TUs is not the same as separation of their packages into different repos just by factor of package ownership.
I would say... _all_ packagers can maintain in [extra] but only Packagers who are also Developers can maintain in [core]. After that... maintain your own private repo or something. You say what about AUR? I'll try to keep this post on topic, but i think AUR can actually become the interface for this new breed of Packagers. 'noda post... 'noda day.
Seriously, what's wrong with main/mantle packages staying in extra and moving unimportant to community?
who's to say what's unimportant? pretty subjective.
What's the difference between packages maintained by developers and _trusted_ users? Community packages are not system-critical anyway.
who is to say what is system critical on my system? Me of course... not any dev or tu or packager any where. All packages _are_ system critical, but the packages in [core] _define_ Archlinux. c'mon guys... are we afraid we'll actually raise packager better than us? The first step will be to extend this hand to the current TUs and let them be the first level clones (ouch!). A key point to keep in mind is that ANY (sorry for the raised voice) packager that slacks in maintainance of their packages WILL be revoked and if no taker is up for the maintainance of that package, the package will be moved out of the repositories with loud shouts on all mailing lists and news front page. cheers, Essien
Of course, if the argument is that devs should maintain packages in [community] because the distinction between devs and TUs isn't important, another solution would be to flatten things and have [core], [mantle] and [extra] and let TUs and devs maintain packages in [extra].
Another thing would be to have community integrated in extra.
This has always been my preferred solution. Heresy you may say, but just sit back and think of it. Some developers prefer packaging work and others prefer tool-chain kinda work. If we could clone those that prefer packaging work, would it increase the amount of high quality and maintained packages in [extra] ? (can i get a big "oh... yeah!") (mooo!)
+1 I agree.
joking aside though. I think we just need to actually DOCUMENT a strict packaging standard (this exists already. no?), and then open up the flood gates to new upcoming would be _packagers_. No distinctions... just one high quality highly udated repository.
Define strict packaging standard. I'm just trying to figure out how difficult this would be. I've tried writing packaging tutorials before... I got bored...
Separation of devs and TUs is not the same as separation of their packages into different repos just by factor of package ownership.
I would say... _all_ packagers can maintain in [extra] but only Packagers who are also Developers can maintain in [core]. After that... maintain your own private repo or something. You say what about AUR? I'll try to keep this post on topic, but i think AUR can actually become the interface for this new breed of Packagers. 'noda post... 'noda day.
Isn't this sort of like what you were working on? and what Paul was working on with repoman? Jason
Jason Chu wrote:
Of course, if the argument is that devs should maintain packages in [community] because the distinction between devs and TUs isn't important, another solution would be to flatten things and have [core], [mantle] and [extra] and let TUs and devs maintain packages in [extra]. Another thing would be to have community integrated in extra. This has always been my preferred solution. Heresy you may say, but just sit back and think of it. Some developers prefer packaging work and others prefer tool-chain kinda work. If we could clone those that prefer packaging work, would it increase the amount of high quality and maintained packages in [extra] ? (can i get a big "oh... yeah!") (mooo!)
+1 I agree.
joking aside though. I think we just need to actually DOCUMENT a strict packaging standard (this exists already. no?), and then open up the flood gates to new upcoming would be _packagers_. No distinctions... just one high quality highly udated repository.
Define strict packaging standard. I'm just trying to figure out how difficult this would be. I've tried writing packaging tutorials before... I got bored...
By strict... i mean that it can be _codified_ by a program like namcap. Ofcourse there would have to be levels of fuzziness, but we can only define the allowable level of fuzziness as we actually try the approach. What I propose is agreeing to something like say, before _any_ package can be accepted into an official repo, it should score like: 70% prebuild on namcap (no Errors, only 30% of warnings allowed) 90% build on makepkg (absolutely no Errors! wouldn't even build.. heh!) 70% postbuild on namcap (No errors. only 30% of warnings) The job the Cloning commitee (ahem!).. i mean Packaging Standards Group, will be to say what these metrics in namcap and makepkg should be and document that publicly. (An added benefit is that automated tools can be used to do this totally without human intervention - more movie watching time to devs!) This would effectively refactor the as yet unwritten *strict* Packaging spec document a Three liner: All submitted package should pass X% namcap prebuild verification (i.e. running namcap on raw PKGBUILD file) All summitted packages should build via makepkg with above X% ratting. All submitted packages should pass X% namcap postbuild verification (i.e. running namcap on the resulting pkg.tar.gz file. Ofcourse there would be the neccessary parts on how to get your verified package into the official repo. Let me not digress with this now though. I also get bored writing tutorials and docs, but spec'ing in code... now there's a thought! What do you think?
Separation of devs and TUs is not the same as separation of their packages into different repos just by factor of package ownership. I would say... _all_ packagers can maintain in [extra] but only Packagers who are also Developers can maintain in [core]. After that... maintain your own private repo or something. You say what about AUR? I'll try to keep this post on topic, but i think AUR can actually become the interface for this new breed of Packagers. 'noda post... 'noda day.
Isn't this sort of like what you were working on? and what Paul was working on with repoman?
Yeah... more like repoman with automated Continous Integration. The don't have to be one monolithic system, but they at least should spew data to and fro, and act like one Unified System. I've taken a slight chill break on RepoBot (what i was working on), since I'm trying to understand that problem space a bit more so i don't end up redoing what repoman or pacbuild are doing.
Jason
------------------------------------------------------------------------
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
Jason Chu wrote:
Of course, if the argument is that devs should maintain packages in [community] because the distinction between devs and TUs isn't important, another solution would be to flatten things and have [core], [mantle] and [extra] and let TUs and devs maintain packages in [extra]. Another thing would be to have community integrated in extra. This has always been my preferred solution. Heresy you may say, but just sit back and think of it. Some developers prefer packaging work and others prefer tool-chain kinda work. If we could clone those that prefer packaging work, would it increase the amount of high quality and maintained packages in [extra] ? (can i get a big "oh... yeah!") (mooo!)
+1 I agree.
If it's the simple solution we're looking for, I think this does do the trick. Maybe that simple solution is better. I actually have come to really like Damir's naming scheme. It's a really cool and distinctive analogy. If in general what I'm hearing is that there are too many repos and that's confusing, I would fully support a [core], [mantle], [crust] scheme. All if it is under one management system (for now, the dev dashboard system) and we invite TUs to go up on the dashboard and maintain packages in [crust]. We allow the TUs to decide by vote whether [community] has then become redundant or not, and keep our hands off of making that decision. Then the AUR is most essential for managing unsupported.
Separation of devs and TUs is not the same as separation of their packages into different repos just by factor of package ownership. I would say... _all_ packagers can maintain in [extra] but only Packagers who are also Developers can maintain in [core]. After that... maintain your own private repo or something. You say what about AUR? I'll try to keep this post on topic, but i think AUR can actually become the interface for this new breed of Packagers. 'noda post... 'noda day.
Isn't this sort of like what you were working on? and what Paul was working on with repoman?
I've been trying to tackle the part of the problem related to the unnecessary complexity in managing the repos, but not so much at the GUI level, but yes, it's solving the same problem with a different UI. I think AUR2 currently in development end up the "dashboard" of tomorrow, if it has the right features. AUR offers its key benefit in providing and managing unsupported. Its only particular virtue for managing [community] is that it does so without requiring a system account on gerolde.. and we should be able to get around that some other ways, which we've already discussed are possible. +1 for unifying management of actual repos under one management system and finding a way to do that without requiring system accounts That's what I've been working on! That and making it as flexible as possible (so everyone WILL want to use the same one) while still as KISS as possible, in the spirit of the good example already set by pacman. - P
Roman Kyrylych wrote:
2007/10/17, Paul Mattal <paul@mattal.com>:
To Aaron's point about too many repos, I would say: There's no good reason why you shouldn't be able to move packages easily from one repo to another with one commandline-- that's what repoman is trying to achieve. When repos are really that lightweight it stops being a big deal if you have one more and starts being beneficial to have a more detailed classification of your packages.
Repoman? Until it'll became a reality - it annoys me when it gets mentioned as a solution to anything. Sorry. :-/
I'm sorry that thinking forward towards a unified solution that reduces work for all of us annoys you. Consider it without the name, then. Currently, using only pacman and not all of our other encumbering scaffolding, the following is sufficient to move a package from one repo to another: move_package.sh: #!/bin/bash REPOHOME='/repos' OLDREPO="$REPOHOME/$2" NEWREPO="$REPOHOME/$3" repo-remove $OLDREPO/$2.db.tar.gz $1 mv $OLDREPO/$1*.pkg.tar.gz $NEWREPO repo-add $NEWREPO/$3.db.tar.gz $NEWREPO/$1*.pkg.tar.gz I can now move packages between repos with: $ move_package mypackage /path/to/{repo1,repo2} When things are closer to that easy in our system, our work will be substantially less, the number of repositories will not matter, and our development hours will be more productive.
What about all those users who will have to change their pacman.conf every time?
They change it once, if/when we decide to create the new repo. This is insubstantial work.
The separation of extra gives no good results, zero, void, nil.
It hasn't been done yet, how can you be so sure? I'm not certain it WILL give good results, but I think it's likely, and as Aaron has pointed out, these things aren't so hard to try and aren't irreversible. We've been trying the unified solution for many years now, why not try the separated solution?
Of course, if the argument is that devs should maintain packages in [community] because the distinction between devs and TUs isn't important, another solution would be to flatten things and have [core], [mantle] and [extra] and let TUs and devs maintain packages in [extra].
Another thing would be to have community integrated in extra. This would also eliminate this issue that is annoying for users and TUs in current situation: 1) packages in community are built against core/extra: 2) testing is filled with db/openssl/gnome/anything-with-so-bump packages issue #1: users that use testing have to rebuild their community packages by themselves 3) packages get moved from testing to core/extra - at this time all needed packages are already rebuilt so nothing in core/extra gets broken issue #2: all community packages that depend on those moved packages are broken now. Users start complaining, TUs are in a rush for rebuilds. With either community-testing repo or community integrated into extra these issues disappear.
I believe that once the devs choose a design for the official repos we should mirror that design all the way down the line. For example, I plan to deploy a similar [mantle] / [crust] structure at my company.
But I still think it's worth separating the devs and the TUs.. this is not to say we shouldn't poach regularly from the TU pool to devs, but the TU post is a great way to get yourself trained to be a good dev. Look at how many came through that way!
Separation of devs and TUs is not the same as separation of their packages into different repos just by factor of package ownership.
It is. Any TU can edit any package in community. Any dev can edit any package in extra. People edit my packages all the time. When it comes time to trust, that is what matters.
Seriously, what's wrong with main/mantle packages staying in extra and moving unimportant to community? What's the difference between packages maintained by developers and _trusted_ users? Community packages are not system-critical anyway.
I agree with you: I currently trust the devs and most of the community repo at about the same level. But I don't think that's ideal. There SHOULD be a difference. We can find MORE people we trust LESS and those people should be training themselves as TUs. In fact, I have always encouraged the AUR to accomplish MORE and worry LESS about quality.. that's it's niche! If the packages were the same quality as the dev packages, then those TUs should become devs and take their packages with them. - P
2007/10/17, Aaron Griffin <aaronmgriffin@gmail.com>:
In reality, I like this distinction, I just think we should try and use the repos we already have. Define [extra] the way you defined [main] and let developers maintain their own packages in [community]. But that's my opinion, and not too many people agree with me on that one.
I agree. -- Roman Kyrylych (Роман Кирилич)
Wednesday 17 October 2007, Paul Mattal wrote: | 3) Some good criteria for classifying packages in one repo or | another are: | | a) Desire to maintain a package long-term. | b) Association with a particular group of people you trust. well written! | 4) There are many who actually do trust developers more than TUs. | This is not intended as a judgement, rather as an observation. | | My feeling is that we should have under the developer umbrella a | split of the existing [extra] into two repos: | | [main] | [...] | | [extra] | [...] my first thought was: again another repo? my second thought was: again another repo! :) with the [current]->[core] transition, we actually dumped a huge lot of pkgs to [extra] that are more than extra. they are main nodes in dependencies and essential to lots of software around (to take a wild example: libpng). extra had already a broad spectrum of pkgs inside. some falling in the same category mentioned above, others less essential but filling an otherwise big hole in arch. lets take an example: science/openbabel is a "niche" package, that is probably only to some use to people who work with molecule data. but for these people, it is kind of a tool they need like you need vim or gcc on your computer. linux is not only for developers of linux... it is broader. it got broader becuase of the great idea behind it. :) libpng and openbabel are in extra. they are both needed to be maintained by devs. not because they are better than TUs, but because they are official and can be run after, if they miss something. they are not so easy to walk away and the pkg is maintained continuously. the proposed [main] category, or lets say [mantle] (to be around the core - thinking geologically) would include all the pkgs that moved from [current] to [extra] in the first place and in addition will take some of the pkgs from [extra] to it. to a certain ammount i like the distinction - it clarifies things and actually should have been done while doing the current->core business ;) on the other hand, its again breaking backwards compatibility and making another ISO required. the question i am asking with this: can we live with an [extra] that holds also the mantle pkgs that are actually more than extra? or are we going to split extra into two repos? i'm against moving pkgs from extra to community that are for a reason maintained by devs already, except there is reason not to keep them in extra. all the pkgs that seem like niche pkgs may require to be seen as official pkgs of a distro not to everybody but to a certain target group of users. there are some (from my point of view around 6% of pkgs) pkgs in extra that may be removed or moved to community simply because the only reason they are in extra are historical (since earlier there was no such thing as community repos). about orphans: i'm against allowing any official pkg to stay orphan for a log time. besides the bad image we gain with this non-commitment to some pkgs it also is a risk to miss important updates and miss fixing things that should be done and that lots of users depend uppon. ---- i'm however not for any overreaction here, since our web-interface is still missing the assignment of maintainence people for x86_64 as well as missing the multiple assignment of people to one single package. this lots of orphans will get reduced to a big ammount with making our web-interface more modern. then the next step would be to go through all (not yet removed orphans by repo cleanup) and multiple-assign them to people who either want to maintain them or have to, because they are dependences to pkgs they maintain (i like this idea - i assigned myself e.g. to imake since some of the pkgs i maintain depend on a working imake... to take an example). to repeat the question i'm asking here: can we live with an [extra] that holds also the mantle pkgs that are actually more than extra (that were in current)? or are we going to split extra into two repos? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Wednesday 17 October 2007, Damir Perisa wrote: | to a certain ammount i like the distinction - it clarifies things | and actually should have been done while doing the current->core | business ;) | on the other hand, its again breaking backwards compatibility and | making another ISO required. | | the question i am asking with this: can we live with an [extra] | that holds also the mantle pkgs that are actually more than extra? | or are we going to split extra into two repos? to give my answer to this question (but please read my first email and decide yourself before reading mine): .. scroll down .. .. .. have you made some propre thoughts? .. .. really? .. ok, here are mine: if you have to break backwards compatibility, break it good and hard. we already made all ISOs (except the last) unusable by removing current and making core. NOW is the time to split up extra in mantle and crust. if possible before the next iso gets released. lets set a milestone in arch and provide a fundament for the future. besides: extra is huge and a splitup would do only good to it. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
participants (8)
-
Aaron Griffin
-
Damir Perisa
-
Eric Belanger
-
Essien Ita Essien
-
Jason Chu
-
Paul Mattal
-
Roman Kyrylych
-
Simo Leone