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