[aur-general] storming in for no reason with crazy ideas

[Eric Bélanger]

On Tue, 23 Dec 2008, Allan McRae wrote:

> Aaron Griffin wrote:
> > On Mon, Dec 22, 2008 at 10:15 PM, Allan McRae <allan at archlinux.org> wrote:
> >
> >> Aaron Griffin wrote:
> >>
> >>> I've been thinking of this as well. It would require some design
> >>> effort from the server side though, but wouldn't be too hard. Do we
> >>> need full shell accounts for these users?
> >>>
> >>> yes: Can be done in a minimal amount of time with very little changes
> >>> to the dbscripts. Management headache with regard to TUs vote new
> >>> people in periodically.
> >>>
> >>>
> >> yes: People can stage their rebuilds.
> >>

yes: For people who maintain packages in both core/extra and community,
everything would be centralized.  I guess the community section of bug
tracker would also be merged with the regular ArchLinux one. For
this reason,  it's a big +1 from me (note I'm not a TU anymore).


> >>
> >>> no: Would require a restricted sftp process, or some daemon for file
> >>> upload. Less management hassle, more code writing.
> >>>
> >>>
> >> no: keeps updating packages the same as now (upload and forget).  No manual
> >> db-script running.
> >>
> >>
> >> For TUs who want to know how the main repo update procedure works, see
> >> http://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager .  The
> >> main difference to current [community] updating is that packages are
> >> uploaded to a staging area which requires you to run and extra script to
> >> actually push them to the repos.
> >>
> >> If we are going to have a testing repo for community (which I think is
> >> overdue and this change would make easy to implement), I think TUs will need
> >> full shell access in order to move the packages from the testing repo to the
> >> main one.


Not really. I guess the main use of the community-testing repo would be
when revbuild are done. In this case, the dev who moves the rebuild from
testing to core/extra could move the rebuilds out of community-testing at
the same time.



> >>
> >
> > Quick aside: Do we need ANOTHER testing repo for community, or could
> > we use the same one?
> >
>
> Decision pending...  I have alway thought the switch to SVN would easily
> allow a testing repo for community.  But that was when I was thinking
> that community repo would still be entirely separate.  If the repos are
> going to be all in the same place, there is little point creating
> another repo.
>
> Allan
>

I think it all boils down to what would be the easiest/best solution in
terms of permissions handling.  If we don't give them access to the
server, then a separate community-testing that would be updated with a
daemon like community might be better.  We also want the TU to only be
able to put only community package in testing, modify them in testing if needed
and then move them back to community. If they have access to the server to
run the db scripts and we can set proper permissions on the testing repo
then we could just have one testing repo.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.