On Thu, Mar 11, 2010 at 9:42 PM, Allan McRae <allan@archlinux.org> wrote:
On 12/03/10 11:37, Eric Bélanger wrote:
On Thu, Mar 11, 2010 at 6:21 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Thu, Mar 11, 2010 at 5:15 PM, Eric Bélanger<snowmaniscool@gmail.com> wrote:
On Thu, Mar 11, 2010 at 6:07 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Thu, Mar 11, 2010 at 5:00 PM, Eric Bélanger<snowmaniscool@gmail.com> wrote:
On Thu, Mar 11, 2010 at 5:13 PM, Daniel J Griffiths (Ghost1227) <ghost1227@archlinux.us> wrote: > > On 03/11/10 at 04:06pm, Dan McGee wrote: >> >> On Thu, Mar 11, 2010 at 4:03 PM, Ghost1227<ghost1227@archlinux.us> >> wrote: >>> >>> --- >> >> Why do none of your patches have commit messages outside of the >> subject? Why are these getting removed? What is the new command? >> How, >> 6 months from now, am I going to make sense of this commit? >> >> Sorry for sounding like I'm coming down with a hammer on your >> patches >> here, but I think this things are truly important. >> >> -Dan > > Not a problem, the commit messages (with the exception of the first) > are taken directly from the commit messages on Aaron's dbscripts > branch. > The testing2* scripts are being removed because the db-move script > can now handle multiple packages in any repo natively. > -- >
What would be the new command to move packages out of testing?
db-move has always been the workhorse here. db-move just did the extra steps of allowing multiple packages specified AND figuring out the target repo.
This patch covers the first case, but not the later
Personnally, I would prefer keeping the testing2* scripts. They are more convenient (especially with tab completion) than using db-move directly with all its arguments.
Do you have any sane way to simplify or combine all the testing2* scripts? There's a LOT of them
I can think about 2 methods right now:
1) We use the same method as with commitpkg, i.e. a single script with a bunch of symlinks. The script check how it has been called and set the target repo and arch accordingly.
2) We currently have 3 testing2extra* script (one for each arch). We could merge them all into a single smarter testing2extra script that would handle all arches. As we usually move both arches out of testing at the same time, that will be more efficient and will reduce by a factor of 3 the number of testing2* scripts. For cases where we only want to move one of the arch out of testing, we will need to use the db-move script directly.
I think there is no need for any testing2* script apart from testing2x. Has anybody ever used the other scripts directly apart from moving a new package? db-move should take care of that rare case.
Allan
I believe I only used testing2x once because the other scripts didn't had support for something (any arch?). As for the other testing2* scripts, I use them all the time probably because of habit. I checked testing2x again and it might be a suitable replacement but it is missing 2 things: - community repo support. Shoud be easy to implement. Just check on what host the script is run and checkout the appropriate svn repo. The sourceballs patches I submitted added some community repo support to the config file which might be helpfull here. - 'any' arch support. Unless we want to implement my idea #2, looks trivial. I think we only need to add a symlink and to update the case statement at beginning.