Re: [Gnu-arch-users] ARCH usage schema for automated updates live files after maintainer commits

[John Arbash Meinel]

Попков Александр wrote:

> John Arbash Meinel wrote:
...

> > > 6. After (before?) all changes (commits) to main arch archive system
> > > must run some test
> > > associated with particular project. If test fails - rollback or cancel
> > > commit.
...

> > Basically, you have an automated script (the pqm), which handles
> > committing to the main archive. Developers commit to a different archive
> > (possibly just their personal one), and then inform the pqm that there
> > is pending work to be merged into the mainline. (This can probably be
> > done in a post-commit hook if you want to make it easier on the >developers.)
>
> And if commit produce conflict(s) on merging to mainline archive, then
> 1) commit on developer archive are success;
> 2) commit on mainline (pqm's) archive are fail;
> 3) developer receive e-mail from pqm about fail in point 2.;
> 4) developer do `tla star-merge ...' for sync up with mainline project tree;
>   and manually handle all conflicts;
> 5) developer do commit again.
>
> I am understood right?
You understand correctly.

> > This pqm is then instructed to do a test merge, verify that the merge
> > passes the tests, before committing to the main archive. At this time,
> > the pqm can also handle all of the emails that you want to send. Or if
> > it fails, the pqm can email the developer letting them know what went >wrong.
>
> E-mails will be sending by pqm to addresses from `tla my-id' of developers, 
> true?
I assume that is the easiest thing to do. I'm not sure exactly how the
pqm is configured, but that makes the most sense.

> > > 7. After each commit to main arch archive system must send e-mail to
> > > maintainer;
> > > 8. Only maintainer must have rights for making new
> > > category/branch/version in main arch archive;
>
>
>
> > Again, the pqm provides a barrier between the developers and the main
> > archive, so if only the pqm and the maintainer have access, and the pqm
> > doesn't have any rules for creating a new category/branch/version, then
> > there shouldn't be any problems.
>
> And if maintainer want to create new version, his just
> 1) tell to developers for they commit changes;
> 1) make new version (tla tag) in mainline archive;
> 2) notify all developers about that;
> Developers need to `tla get mainline-archive/project--devo--new-version'
> and next changes they must do in new version tree.
>
> True?
Yes.

> > > 9. After maintainer make new version of particular project system must
> > > send e-mail to all project developers;
> > > (and developers go to update own local copies of changed project?);
>
>
>
> > Some of this can most easily be done by self-discipline of the
> > maintainer. It can also be done with a post-commit hook. I'm not sure if
> > there is a post-tag or post-branch hook, but you could work something
> > like that out.
>
> We think what new version's make - not often operation, and manual creating 
> email for notify developers - right choice for us.
Sounds good.

> > > 10. Updating project files on live server process must have two cases:
> > > 10a. Update files in "TEST" location, for manual testing on LIVE server.
> > > 10b. Update files in "HOT" (production) location on LIVE server.
>
>
>
> > Is this being done by the maintainer or by developers? Because in 5 you
> > stated that devs can't touch the live server.
>
> We think maintainer in own schema will differ from developers only in next 
> points:
> 1) Only maintainer will have access to pqm user account (and to mainline 
> archive);
> 2) Only maintainer will have responsibility about making new versions ;)
>
>
>
> > It really only amounts to having 2 locations "checked out". The
> > maintainer runs "tla update" in the test location, tests the system on
> > the live server, then can cd over to the production location and do
> > another "tla update".
>
> Thank!
>
>
>
> > Good luck. Hopefully people who are actively using a pqm will speak up.
> > As I think it really fits what you are wanting to do. If you don't want
> > to go through that work, we have also worked out some other alternatives.
>
> Pqm is fine for us!
>
>
>
> > The first key is do you trust your developers to not try and subvert the
> > system. If so, that simplifies a lot of things.
> > One of the problems with having tests run automatically, is that you are
> > allowing the developers to cause arbitrary code to be run on some other
> > machine. You probably can trust your developers, I just want to bring up
> > the fact that if you are running automatic tests, there is nothing to
> > stop the developers from submitting the "test" which runs an arbitrary
> > command.
>
> Yes, you right. We will trust own developers.
>
>
>
> > If you don't want the pqm, you can read about hook scripts here:
> > http://wiki.gnuarch.org/Using_20hooks
> >
> >
> > You can use JohannesBerg's method (near the end) which lets you run a
> > per-package hook script. By tying into the precommit hook, you can have
> > tests run, etc.
> > If you want to prevent creation of new cat/branch/version, you can make
> > all directories non-group writable (chmod go-w), except for the final
> > directory where the new revisions are created. You'll also want to check >out
> > http://wiki.gnuarch.org/Centralized_20Development
> > To see how to have multiple people committing to the same archive.
>
> Thanks for links. So pqm method is more likely for us:
> 1) No need to dance with umask and access rights;
> 2) Centralized pre-commit and post-commit hooks, which called _every_time_
>   mainline archive changed;
Yep. Again, it may require some tuning of the pqm, but most of the work
has been done for you already.

> --------------------------------------------------------------------------
> Robert Collins wrote about arch-pqm:
>
>
> > Its the same one, just a more recent version - adding support for acls
> > on a per branch basis, baz, various bugfixes, a replay command.
> > Http://people.ubuntu.com/~robertc/address@hidden/arch-pqm-->main--0
>
> Right link:
> http://people.ubuntu.com/~robertc/address@hidden/arch-pqm/arch-pqm--main/arch-pqm--main--0/
>
> Big thanks. Robert, is this you fork from official arch-pqm project?
>
> WBR, Alexander Popkov.
I believe this pqm supports baz, which is an alternative command line
tool for handling arch repositories. You might want to look into it, as
they are pretty aggressively working on making baz straightforward to
use. It doesn't have quite the "absolutely stable" sense that tla has,
but I use it most of the time and enjoy it. (baz status is much nicer
than tla changes && tla tree-link).

From what I've gathered, it's probably the most used pqm, and thus the
de facto official pqm. :)

John
=:->

signature.asc
Description: OpenPGP digital signature