Re: Porting tests to plone.app.testing and removal of legacy packages

Johannes Raggam <[email protected]>
Newsgroups gmane.comp.web.zope.plone.devel
Message-ID <[email protected]>
Please track these reverted packages. The pull request on that packages
is closed and if we forget to revert the revert, the changes are lost in
history.

I'd rather give people a bit more time, say 48hrs or try to fix the
breaking tests myself. Everyone should feel responsible to fix a failing
test.

Especially because on the Plone 5 AT job it's IMO not that urgent to
have a green build within a few hours.

Johannes



On Wed, 2015-01-28 at 13:35 +0100, Gil Forcada Codinachs wrote:
> Plone 5 AT tests are still broken... I just reverted p.a.folder and
> p.a.blob but there are still broken tests on P.DynamicViewFTI and
> P.PloneLanguageTool.
> 
> 
> Can anyone help with those?
> 
> 
> Cheers,
> 
> Gil
> 
> 
> 2015-01-28 11:15 GMT+01:00 Patrick Gerken <lists-Hgn/qBBDvdzwVR/[email protected]>:
>         On 28.01 10:06, Jens W. Klein wrote:
>         > On 2015-01-28 09:50, Ramon Navarro Bosch wrote:
>         > > I'm agree with Timo, we should try to be carefull. Our use
>         case is much
>         > > different to one repo projects where everybody works on
>         pull requests so
>         > > we need to try to follow the rules we agreed.
>         > >
>         > > Maybe we need to define a better process for testing plip
>         so we can
>         > > ensure that we have a jenkins job equal to real jenkins
>         job. On the
>         >
>         > +1000
>         > this plus a check if every checkout is uptodate with target
>         branch (most
>         > of the time master) of the packages.
>         
>         I'd like to point to this:
>         https://github.com/fschulze/mr.developer/commit/b76e77ffb8ccfd8a7accf329f465d589179b554c
>         
>         There is no release of mr.developer yet, so the bug that
>         changing
>         branches on update might hurt us still on jenkins.
>         Also, if some kind soul would implement an additional command
>         to allow
>         a quick check out of a PR, we would be quite far to let
>         jenkins merge
>         PRs semi automatic (By means of parametric builds to define
>         the PR to
>         test and then a shell script to merge the PR for the specific
>         package)
>         >
>         > Jens
>         >
>         > > Resource Registry PLIP the autoconfigured jenkins job was
>         equal to real
>         > > 5.0 so when it was green on jenkins plip job ( rebased to
>         master on all
>         > > branches ) we could merge without pain.
>         > >
>         > > R
>         > >
>         > > El Wed Jan 28 2015 at 08:55:56, Timo Stollenwerk
>         > > (<tisto-z4DKO/[email protected]
>         > > <mailto:tisto-z4DKO/[email protected]>>) va escriure:
>         > >
>         > >     Am 27.01.15 um 22:11 schrieb Jens W. Klein:
>         > >      > Well, tests on the branch were green. So why after
>         merge not on
>         > >     master?
>         > >
>         > >     Because obviously the branch was not 100% in sync with
>         the 5.0 branch.
>         > >     Our setup with checkouts and mr.developer is complex.
>         Things like this
>         > >     happen all the time. This is why it is so important to
>         do it step by
>         > >     step.
>         > >
>         > >      > If this all fails that hard we need a better
>         process. Merging is
>         > >     always
>         > >      > a huge PITA at the moment.
>         > >
>         > >     The problem is that you just merged lots of pull
>         requests at the same
>         > >     time without checking the Jenkins jobs. Sorry, but you
>         can't just
>         > >     completely ignore our process (e.g. the CI rules) and
>         then complain
>         > >     about it. If you would have sticked with the CI rules,
>         we wouldn't have
>         > >     a problem now.
>         > >
>         > >     For me this is highly frustrating, because I always
>         monitor the Jenkins
>         > >     status and try to fix thing if necessary. If I don't
>         revert commits
>         > >     right away people start committing on a broken build
>         making it
>         > >     impossible to figure out what went wrong. The more
>         commits on a broken
>         > >     build there are, the more complex things get. There is
>         a good chance
>         > >     that if you don't revert immediately, that we won't be
>         able to get a
>         > >     green build without serious effort.
>         > >
>         > >     Continuous Integration is a process not a tool. Our
>         tools might not be
>         > >     perfect, but if everybody would just stick to the CI
>         rules we would have
>         > >     a green build most of the time.
>         > >
>         > >     So, PLEASE REVERT ALL THE COMMIT YOU MADE YESTERDAY!
>         > >
>         > >     This is the only sane way to get a green build again.
>         You can't just
>         > >     break hundreds of tests and then leave it like this or
>         expect other
>         > >     people to clean up the mess.
>         > >
>         > >      > We can try now to fix the stuff on masters or we
>         take days until
>         > >     all is
>         > >      > merged piece by piece. Each test run takes ages.
>         That way we
>         > >     never get
>         > >      > plone 5 out of the door. Probability to break the
>         build from even
>         > >     green
>         > >      > branches is bigger than that it works. This a
>         incredibly turn-off.
>         > >
>         > >     I'm more than happy to merge the commits one by one
>         (something that I
>         > >     already started btw. I just stopped because there are
>         open issues),
>         > >     after you reverted your commits. If you don't like the
>         CI rules, please
>         > >     feel free to make a different proposal.
>         > >
>         > >     Though, I'm really tired of discussing the basics of
>         our software
>         > >     development process over and over again. Do we really
>         want back to the
>         > >     old development process where everybody just broke
>         whatever they wanted
>         > >     and David and a few others have to clean up the mess
>         before each
>         > >     release? This is what really slowed us down in my
>         opinion.
>         > >
>         > >     Personally I don't want to waste my time cleaning up
>         things that were
>         > >     trivial to fix by others if they would have sticked
>         with the CI rules.
>         > >     If this is the opinion of a minority, we might want to
>         find another CI
>         > >     team leader...
>         > >
>         > >     Timo
>         > >
>         > >
>          ------------------------------__------------------------------__------------------
>         > >     Dive into the World of Parallel Programming. The Go
>         Parallel Website,
>         > >     sponsored by Intel and developed in partnership with
>         Slashdot Media,
>         > >     is your
>         > >     hub for all things parallel software development, from
>         weekly thought
>         > >     leadership blogs to news, videos, case studies,
>         tutorials and more.
>         > >     Take a
>         > >     look and join the conversation now.
>         > >     http://goparallel.sourceforge.__net/
>         > >     <http://goparallel.sourceforge.net/>
>         > >     _________________________________________________
>         > >     Plone-developers mailing list
>         > >     Plone-developers@lists.__sourceforge.net
>         > >     <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>         > >
>          https://lists.sourceforge.net/__lists/listinfo/plone-__developers
>         > >
>          <https://lists.sourceforge.net/lists/listinfo/plone-developers>
>         > >
>         > >
>         > >
>         > >
>         ------------------------------------------------------------------------------
>         > > Dive into the World of Parallel Programming. The Go
>         Parallel Website,
>         > > sponsored by Intel and developed in partnership with
>         Slashdot Media, is your
>         > > hub for all things parallel software development, from
>         weekly thought
>         > > leadership blogs to news, videos, case studies, tutorials
>         and more. Take a
>         > > look and join the conversation now.
>         http://goparallel.sourceforge.net/
>         > >
>         > >
>         > >
>         > > _______________________________________________
>         > > Plone-developers mailing list
>         > > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>         > >
>         https://lists.sourceforge.net/lists/listinfo/plone-developers
>         > >
>         >
>         >
>         > --
>         > Klein & Partner KG, member of BlueDynamics Alliance
>         >
>         >
>         >
>         ------------------------------------------------------------------------------
>         > Dive into the World of Parallel Programming. The Go Parallel
>         Website,
>         > sponsored by Intel and developed in partnership with
>         Slashdot Media, is your
>         > hub for all things parallel software development, from
>         weekly thought
>         > leadership blogs to news, videos, case studies, tutorials
>         and more. Take a
>         > look and join the conversation now.
>         http://goparallel.sourceforge.net/
>         > _______________________________________________
>         > Plone-developers mailing list
>         > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>         >
>         https://lists.sourceforge.net/lists/listinfo/plone-developers
>         >
>         
>         
>         ------------------------------------------------------------------------------
>         Dive into the World of Parallel Programming. The Go Parallel
>         Website,
>         sponsored by Intel and developed in partnership with Slashdot
>         Media, is your
>         hub for all things parallel software development, from weekly
>         thought
>         leadership blogs to news, videos, case studies, tutorials and
>         more. Take a
>         look and join the conversation now.
>         http://goparallel.sourceforge.net/
>         _______________________________________________
>         Plone-developers mailing list
>         Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>         https://lists.sourceforge.net/lists/listinfo/plone-developers
>         
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________ Plone-developers mailing list Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers
signature.asc (application/pgp-signature, 181 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlTI5HgACgkQW4mNMQxDgAcHPQCfZE6ni4+yngJns5EFGF3jth2O
KMYAn3e1earr4ANvSNEz2tVJjIAA8Afh
=MrWR
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.